In the original commit before rebase everything seemed to be working; but someone changed something else in the code you were relying on without creating a direct conflict, and now all your rebased commits crash and burn. What's worse, you discover it much later, when original commits are long gone, and instead of one merge commit being the easy traceable breaking point, you now don't even quite remember which exact commits were rebased and have to check EVERYTHING.
Or, and with merge commit you could've easily just check it right there with simple tests before committing — no such convenient option for rebase.
The thing is, it's a leaky abstraction. Rebase workflow tries to present things simpler then they really are, and you end up paying a price for it.
If you have a failure, having a straight-line history makes it easier to do a bisect with your failing test and find the point of failure.
Unrelated to your issue with git rebase, but addressing another common complaint, git rerere allows git to remember and reuse previous conflict resolution so you don't get into resolution hell.
But thanks for git rerere! I've never heard about it.
Having a merge marker showing where the commits came from and the branch name is incredibly useful, but that's not a black mark against rebase -- only your organisation's lack of diligence to following a set of rules.
If you use something like Github's pull request system it will always create a merge commit when you merge a pull request; as it should be.
One thing you can do whilst rebasing to ensure the rebasing doesn't break against the master branch you're rebasing against is calling out to a shell command -- rebase will let you do this -- to run your unit tests between each rebase commit.
Nice shell tip!
Are there any other useful ways to use git for a small team outside of pull and rebase? One thing that's bugged me is undoing (possibly partially) previous pushed commits while keeping everything past.
git rebase -i HEAD~5
You can also use the same command to squash multiple commits into one. This is useful when you write a commit, then have several commits gradually adding temporary debugging statements and unit tests, then more commits to fix any problems uncovered, then more commits to remove extensive print statements and other temporary debugging code.
Assuming you get the code working, most of these commits will be totally irrelevant to future development efforts. With the "squash" feature of git rebase -i, you can condense all these commits into a single commit containing only working code and unit tests, springing fully formed in a single commit, like Athena from the head of Zeus.
The git rebase -i command will also let you re-word or edit commits; the utility of those functions should be obvious.
(1) http://gitready.com/intermediate/2009/01/31/intro-to-rebase....
(2) http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm...
(3) http://gitready.com/advanced/2009/03/20/reorder-commits-with... <~ talks about "interactive mode" with the -i option
Not sure why the author says that is weird - I can't think of an alternative if people are truly collaborating or pairing on a feature.
Master can be used as a chat room (substitute english with code) and leave branches for very specific cases when that doesn't work. That's basically doing continuous integration. If you prefer, you can think of it as if you are still having branches with one commit each ;).
The important thing for CI is being sure that each commit is either hidden (through a feature toggle maybe?) or it doesn't break anything.
It's not that complicated - rebase applies your commits to another branch as if they were patches. Interactive rebase gives you the option of re-ordering/removing/editing those patches before they're applied.