Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

PIVOTAL LABS
Valentine's Day (2/14/11) Standup: Git Rebasing and NodeJS package manager issue

Overview

  • “Could someone quickly explain the pros and cons of using git rebase over git merge?

  • “Has anyone had a problem with NodeJS not seeing libraries installed with its package manager npm?”

Answers

“Could someone quickly explain the pros and cons of using git rebase over git merge?

A few points pivots brought up:

  • Rebase gives you a pretty line of history without the merge commits. Merging causes the history to grow horizontally as you add pairs to the team.
  • Doing forensics (e.g. git bisect) on changes made by others can be a very manual process without rebasing.
  • Merges have the upside of showing what really happens. In a conceptual sense, you really are working in parallel tracks and stitching the tracks together.
  • Rebasing is good because you’re rewriting history to clean things up. You can fix mistakes in prior commits or commits messages.
  • But then again, who really cares? Is the extra effort needed to learn and apply the complexities of a rebase workflow worth the gain?
  • Also, RubyMine has a rebase feature but it’s caused problems for some pivots. Be very careful when you’re letting a tool like RubyMine make big changes like a rebase to your repo.

More info about git rebasing: http://book.git-scm.com/4_rebasing.html

“Has anyone had a problem with NodeJS not seeing libraries installed with its package manager npm?”

Another pivot had encountered this issue before and suggested adding the NODE_PATH variable to the user’s bash environment:

export NODE_PATH=”/usr/local/lib/node”

This solved the issue. Of course, your own node location may be different. The pivot experiencing this issue installed node from Homebrew.

Comments
  1. As a rule of thumb, don’t rebase.

    Rebasing essentially re-applies your changes to the HEAD. This can be useful for certain situations, like providing a patch to a big upstream project (like rails) without having extra merge commits.

    The danger comes into play when you begin to re-write your previous history that you’ve already pushed. This can lead to all sorts of bad things, like commits getting re-applied.

  2. Joseph Palermo says:

    My main problem with rabasing:

    If I screw up a conflict when I’m doing a merge it is no problem. I can inspect my original commits, and the merge, and see what I did wrong.

    If I screw up a conflict when I’m doing a rebase my original history is gone, I only have the broken state of the world, and it’s possible I have no idea what I did originally.

  3. Elia says:

    We use`git pull –rebase` in our (small) environment and works pretty well. It’s also somehow simpler to understand for newcomers and makes the commit history more readable.

    Also I often use `git rebase –interactive –autosquash origin/master` to make my commits more readable for my teammates (and myself).

    The only downside we sometimes encounter is that multiple commits changing a file that’s changed also on master require nearly identical resolutions to be applied as many times.

  4. Tim Connor says:

    Palermo: reflog. That is, of course, sub-optimal, but you do have to try really hard to actually lose something outright.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *