Replaying Commits Somewhere Else

A rebase takes each of your commits in turn, computes the change it made, and applies that change on top of a different commit. The result is a new commit with the same message, the same author, the same change — and a different hash, because the parent is different and the hash covers the parent.

Step through those three panels and watch what happens to C and D. They do not slide along the line. They stay exactly where they were, unreferenced, while C' and D' appear somewhere else. Nothing points at the originals any more, so Git will eventually collect them.

$ git switch fix/login$ git rebase main# Successfully rebased and updated refs/heads/fix/login.

The output is a linear history with no merge commits. Reading it is easier; bisecting it is simpler; the log tells a clean story from top to bottom.

The story is not quite true. It reads as though you started your work from the latest main, finished it, and pushed. In fact you started three days earlier, from a different commit, and this arrangement was constructed afterwards.

Neither is correct in general. The useful compromise, and what many teams do, is: rebase your own branch while it is still yours to keep it tidy and up to date, then merge it into main so the landing is recorded.

This is the golden rule, and now the reason for it is obvious rather than mystical.

Rebasing gives every commit a new hash. If a colleague has already pulled the originals, their Git still has C and D. Yours now has C' and D'. The two histories contain the same code under different names, and Git cannot tell they are the same work.

* 8f2a1c4 (origin/fix/login) Handle the empty next param   <- yours, rebased* 3d9b7e0                     Fix the redirect                <- yours, rebased* 4b8e0d7 (HEAD -> fix/login) Handle the empty next param     <- theirs, original* 2c7a91f                     Fix the redirect                <- theirs, original* 1a5e8c3                     Set up the router

Every commit is now duplicated. If they merge, both copies end up in the history side by side, and anything they built on the originals is tangled up with your rewritten ones. Untangling this is unpleasant and it is always somebody else's afternoon, not yours.

git rebase -i is the same machinery pointed at your own recent commits, and it is how twelve commits called "wip" become three commits somebody can review.

$ git rebase -i HEAD~4        # the last four commits$ git rebase -i main          # every commit on this branch since main

pick 2c7a91f Fix the redirect when next is emptysquash 4b8e0d7 fix typoreword 7d1f6b4 wipdrop 9a1c4e8 add debug logging # Commands:# p, pick   = use commit as is# r, reword = use commit, but edit the message# s, squash = merge into the previous commit, combining the messages# f, fixup  = merge into the previous commit, discarding this message# e, edit   = stop here so you can amend the commit# d, drop   = remove the commit entirely## These lines are in OLDEST-FIRST order. Reordering them reorders history.

Change the word at the start of each line, save, close. Git replays the commits according to your instructions. If a step conflicts it pauses exactly as a merge does, and git rebase --continue carries on once you have resolved and added.

After rebasing a branch you have already pushed, a normal push is rejected — correctly, because your history no longer contains the commits the remote has. Publishing the rebase requires overwriting the remote branch.

$ git push --force-with-lease# Not: git push --force

--force overwrites the remote branch unconditionally. If a teammate pushed a commit to that branch in the last ten minutes, it is now gone, with no warning and no record on your machine that it existed.

--force-with-lease overwrites only if the remote is still exactly where you last saw it. If somebody has pushed since, the push is rejected and you find out before destroying anything.