I actually had in the original draft a warning about how to apply these practices in the context of the project you are working on. In hindsight it might have been good to leave that in. I think these comments sum it up though.

On a side note your point on the correct use of merging is well taken. I didn’t want to go into all the detail of fastforward vs. recursive merges in the article. Our problem with merging on “non-shipped” code is that on our team non-fastforward merges were happening far too often. The history was cluttered with merge commits to the point where it was extremely annoying and needless noise IMO (for a tree that hasn’t shipped yet).

It all comes down to your first point of code that is “behind closed doors”. That’s the key for rewriting.

B1*—B2———\
/ \
A1—A2—A3*—A4—A5

This preserves the ordering of commits and merges, and reflects the fact that changes B1 and B2 were designed, committed and tested on top of commit A1. And means that ‘git-bisect’ works as designed if we later need to track down bugs introduced in these commits.

If developer B wants to use the ’squashing’ trick to combine his patches into one commit, before he’s ever made them public, that might make sense. But if ‘A’ is upstream, or even an intermediate ’subsystem’ tree, and suddenly decides that he’s going to break his tree and collapse commits ‘A1′ and ‘A2′ together so that it goes…

A0—A2′—A3′—

… when other developers were _using_ that tree as a base for further development, then that is really nasty.

“Rebasing is fine for maintaining *your* own patch set, i.e. it is an alternative to using quilt. But it is absolutely not acceptable for *anything* else.” — Linus Torvalds.

“Just say *no* to rebasing” — Linus Torvalds.

“In particular, people who rebase other peoples trees should just be shot.” — Linus Torvalds.

A few other nice ones — “git-format-patch” and “git-send-email” are clearly outstanding tools for people who want to submit code to projects and are worth a mention. Ultimately though, you can get a long long long way with just the basics. For those that want to learn more, see the tutorial here:

http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Mercurial is also another similar distributed system, but having had it clobber my remote repositories on more than one occasion, I much prefer git.

I often liken it to an Italian sports car — it’s a high performance SCM and much better than your Ford Taurus (SVN), but it does take some time to learn how to drive it properly. And it is probably easier for a newb to get wrapped around a tree. But wouldn’t you rather have the sports car?