Git pull vs git pull --rebase

Question

In reference to this well-written answer: https://stackoverflow.com/a/4675513/1139436

If you actually feel the need for something to be a branch for whatever reason...

What is being referred to here, by "branch"? In our workflow, we branch off the master to make bugfixes, new features, etc, then, push those changes to gerrit for review, which, once approved, (I assume, I did not set it up) merges them into master. Are these the branches that were being referred to, or is the comment referring to something larger (projects diverging, etc)?

Back to our workflow... Once the changes are submitted, we git checkout master, git pull* and git branch -D bugfix_branch. I marked pull with a * since, that has often led to merge commits in my local master. I started using git pull --rebase and no longer see those merge commits, but I admit, I don't understand at all what is happening under the hood.

Why am I seeing merge commits and, do I want them? Am I better to --rebase and avoid them? Noone seems to have an answer either way, so long as it "just works".

Answer 1

Ultimately, the decisions about whether to use a merge oriented work-flow, a rebase oriented work-flow, or some hybrid—i.e., use both, choosing which one based on judgment—is a matter of opinion and, well, judgement.¹ There are good arguments on both sides. Here are two outside opinion pages, one by Ken Sheedlo in favor of rebase and one that lists arguments on both sides, plus the Atlassian tutorial page on merging vs rebasing.

The thing to realize about rebase is that it copies (some) commits. If you understand the Git model of representing commits as a graph,² the example in Ken Sheedlo's pro-rebase argument shows you exactly what this means: the original commits B and C in:

  B--C   <-- feat
 /
A--D--E   <-- master

are figuratively abandoned to the wolves, in favor of the shiny new replacements B' and C':

  B--C   [abandoned]
 /
A--D--E   <-- master
       \
        B'-C'  <-- feat

Having replaced the dull icky old B-C chain with the shiny new B'-C' chain of commits, the new feature branch can now be seamlessly incorporated into master, with or without a merge commit. Using the merge commit—running git merge --no-ff feat while on master—gives you this graph:

A--D--E------F   <-- master
       \    /
        B'-C'  <-- feat

which helps a historian come along in the future (once the name feat is erased, which is safe since F remembers C' as well as E) and see that the commit pair, B'-C', is what implemented the feature. Whether this has value, vs the simpler-looking:

A--D--E--B'-C'  <-- master

is a separate question. But the fact that the true original commits were B--C is lost either way, due to the rebase. If that fact is important for some reason, then you did lose something by rebasing.

That, in its nutshell, is the anti-rebase argument: you might lose some important bit of history. The pro-rebase argument is that these bits of history are not merely unimportant, they actively interfere with understanding. Much of computer programming is about abstraction, and abstraction is the art of removing unnecessary detail.³ This gives you a good "big picture" view. Once you understand where you are now and where you want to go, then you can plot out the gritty details of how you got here and how you can get there. If you're lost in the weeds of details and have no idea where you are and where you are going, you will at most get lucky with some sort of Brownian motion.

---

¹This is also true about whether to spell judgment with the extra "e": http://grammarist.com/spelling/judgment-judgement/, https://www.dictionary.com/e/judgement-vs-judgment/

²If you don't, work through the pages at Think Like (a) Git.

³This is true of mathematics as well. Graph theory itself arose from removing unnecessary detail: Euler's realization that all that mattered were the bridges-and-land-masses. (See link in footnote 2.)