notes-computer-development-gitMergeRebase

The short of it is: if you are the lowest hierarchical level in a tree of development branches (i.e. a single person's working branch), then always rebase when you pull from higher levels of the hierarchy. If, however, you are not the lowest level (you are someone else's upstream), then merge.

Details and discussion

• rebase when pulling from master
• merge when going up in hierarchy
  • http://gitguru.com/2009/02/03/rebase-v-merge-in-git/ -- this also suggests to rebase when going down in hierarchy, but the below suggests otherwise
• don't rebase anything that others have pulled
  • http://lwn.net/Articles/291304/
  • "Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history." -- man git rebase
  • http://changelog.complete.org/archives/586-rebase-considered-harmful
• if you have a hierarchy with team integration branches in the middle, those branches should NOT be rebased! because the whole point of those branches is so that everyone on the team is pulling from them.
  • ""You are supposed to clean up your history before you make it public": Yes (with caveats), but this only addresses patch atomicity. It does not address synchronization, which is the real problem. "it makes it easier for others because you have designed your patches for the head of the upstream repository": And so has every one else. And when patches which conflict with yours get merged first, your patch no longer applies. What to do? As it scales up you need middle men. They are a synchronization point for folks working on the same area of code. It has to be public or synchronization can't happen. But what if you find a bug in this amalgamation? Rebase? It's not yet gone upstream, it's still being worked on. Do you push a patch upstream which you know to be bad, along with a patch which fixes it, or do you rewrite history.T he point is it's a tough decision and people are making the wrong one. They're rebasing. And that fucks things in about half a dozen ways, as outlined by Linus." -- http://www.reddit.com/r/programming/comments/6ube0/synchronizing_development_rebase_vs_pullmerge_git/?sort=top
  • "I thought it was always pretty obvious that rebasing is only for the lowest levels of this heirarchy." -- http://www.reddit.com/r/programming/comments/6ube0/synchronizing_development_rebase_vs_pullmerge_git/?sort=top
  • ""why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer."http://kerneltrap.org/Linux/Git_Management