Git Internals and Workflows: Branching, Merging, and Rebasing

Part 6 of 17 · ~2 min

The One Rule That Prevents Most Git Disasters

Back to your choice: merge Nadia's work in, or rebase onto it.

Rebase is tempting. Your branch is four days old with a few messy commits, and a linear history would read better in review. Except for one thing you did on Tuesday afternoon and have already half forgotten:

git push -u origin feature/shift-swap

You pushed it so Theo could look at the API shape. Theo pulled it. Theo has your commits — 7c1f4ae, 2b9d013, 41e77c6 — sitting in his local repository right now, and he has started writing tests on top of them.

The rule that matters most: once a commit has left your machine and landed somewhere a teammate could have grabbed it, rebasing it is off the table.

The reason is the apostrophes from the last chapter. Rebasing replaces 7c1f4ae with 7c1f4ae' — a different object with a different hash. Theo's repository still has the original. When he next pulls, Git does not see "the same commit, moved." It sees two unrelated lines of development that happen to contain identical changes, and it tries to merge them. Theo gets conflicts on his own work, against a copy of your work he already had, and if he resolves them the wrong way your branch ends up containing every change twice.

Nothing in that sequence is recoverable by pressing a button. It is recoverable by Theo throwing away his local branch and starting over, which is a rude thing to do to somebody by accident.

The practical test takes five seconds:

git branch -r                  # has this branch been pushed at all?
git log origin/feature/shift-swap..feature/shift-swap   # commits I have that origin does not

If the remote already has those commits, rewriting them stops being a call you get to make alone — it lands on everyone who might have pulled from that branch. That does not make it forbidden — rebasing your own pushed feature branch is completely routine, and you will do exactly that on Thursday — it makes it a thing you say out loud first. "I'm about to rebase shift-swap, don't pull for ten minutes" is a normal sentence in a normal team.

The inverse is worth stating too, because the rule gets over-applied into a superstition that rebasing is dangerous. Rebase freely on anything that has never left your machine. Unpushed commits have no downstream. There is nobody to disagree with you about what happened. Rewriting them costs nothing and is often the kindest thing you can do to whoever reviews the result.

So: you and Theo agree he will not pull until you say so. And on Wednesday afternoon, whichever way you bring Nadia's work in, you hit the same wall.