Overview
“Could someone quickly explain the pros and cons of using
git rebaseovergit 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.
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.
February 14, 2011 at 6:52 pm
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.
February 14, 2011 at 8:48 pm
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.
February 15, 2011 at 5:24 am
Palermo: reflog. That is, of course, sub-optimal, but you do have to try really hard to actually lose something outright.
February 15, 2011 at 7:52 pm