Raw thoughts from Alex Dong

git pull vs. git rebase: it's about different engineering cultures

It’s not often for me to become interested in technology itself these days. But the discussion between git pull and git rebase has interested me a lot.  Not for its own technology details but more as a tool to either loose or strengthen an engineering culture.

git pull encourages a rather loose, relax and, in the long run, ad-hoc manner of team work.  This suits startup cultures quite well.   It’s fast to learn and easy for people who migrate from older version controls like subversions to learn.  Engineers works on his own little branch. He has no reason to integrate with other people’s code until the very end of one’s little project is finished.  The commit history ends up having messages that describes more about the code and less about the reason and thinking behind this list of patches.  For example, if you happen to follow the resque project, you’ll realize that a commit message like this is not really that helpful. 7 lines of changes.  One line comment without explaining why the ‘destroy’ is delayed.

git rebase encourages comparatively stricter engineering culture. One has to pay attention to not only his code, but also the commit histories.  Projects like linux kernel uses it to enforce a culture of  keep clean history. Linus even wrote up what a good commit would look like here.   I can see how this could be very helpful in a project where the code needs to be maintained 15 years later by totally different set of people.  A clean history, instead of a loose list of incremental functional changes, will provide more context in the long run.  As a sample, check out this patch by Linus for a firmware related patch. 4 lines of changes, 8 lines of comments on the commit.