This article is based on a LinkedIn comment I wrote in response to a comment mentioning the following two problems in relation to Git Rebase:
- “Team members have totally lost my commits during their botched rebase efforts.”
- “I hate the number of times I have to resolve the same conflicts between ‘rebase continue’.”
I’ve heared these complaints many times before, so here is my response:
These are (unfortunately still common) symptoms of solved problems, but I can empathize with this. I find the same in many teams, but I try to not leave it that way.
Avoiding rebase because of bad experiences1 with it in the past is like treating the symptoms. I prefer to treat the causes. Addressing the two mentioned problems directly:
If the same merge conflict occurs multiple times during rebasing (a complaint I’ve heard many times before), it hints at multiple problems in the team, in no particular order:
- not familiar enough with the tooling, specifically Git’s rerere feature, which is designed to address this
- lack of research into existing solutions for a very specific, simple and common problem
- long running branches, lack of continuous integration
- bad commit scope (a large number of unintegrated (!) commits causing similar conflicts)
- possibly design/architecture or collaboration problems (unrelated changes too often requiring changes in the same parts of the code; too much work in progress)
To address this, I recommend looking into practices like continuous integration (CI) and Intentional Commits, although I’m not saying it’s easy to do.
If team members can lose someone else’s commits, something deeper is going on:
- Lack of mentoring or training. Conceptually, one rebases one’s own commits onto the trunk, not the other way around, so losing someone else’s commits just by rebasing shouldn’t be possible. Losing someone else’s code changes may be possible if they resolve conflicts using “keep mine”. The same can happen with merge, and it shows a lack of understanding of merge conflict resolution rather than of rebase. If they drop the actual commits of another developer, it would mean that they rebase and force-push shared branches. Not only can that be prevented from the tooling side (protecting the trunk/main against force-pushes), it also shows either recklessness, or (giving the benefit of the doubt) a skill issue. I generally recommend pair programming and possibly training to address problems like this. Rebasing (and Git/version control in general) is not very complicated, but often developers who’ve never used/done it before are left alone to figure it out by themselves and then we complain if they don’t get it right from the start. These things can be taught.
- Avoiding rebase (in certain situations or in general due to personal preference) despite really understanding it is fine. In many cases, I see people avoiding it for the wrong reasons, often with justifications that show a lack of understanding, and this is what we address here. ↩︎
Raimund Krämer 