Rebasing

What rebase does

Merging combines two branches with a merge commit. Rebasing does something different: it takes the commits on your branch and replays them, one by one, on top of another branch, as if you’d started your work from there ¹.

me@linuxbox:~/garden$ git log --oneline --graph --all
* 304505a (main) Add garlic
| * 61c9ab4 (HEAD -> compost) Add compost schedule
| * ca5bca4 Plan the compost bin
|/
*   51d3821 Merge branch 'spacing'
me@linuxbox:~/garden$ git rebase main
Successfully rebased and updated refs/heads/compost.
me@linuxbox:~/garden$ git log --oneline --graph --all
* 09e3458 (HEAD -> compost) Add compost schedule
* ce75ff3 Plan the compost bin
* 304505a (main) Add garlic
*   51d3821 Merge branch 'spacing'

The history is now a straight line, and merging compost into main is a simple fast-forward. The end result, the files, is the same as a merge; the history is cleaner ¹.

Look at the IDs: ca5bca4 became ce75ff3, and 61c9ab4 became 09e3458. A commit’s ID is a checksum of everything in it, including its parent. Rebasing gives each commit a new parent, so rebasing doesn’t move commits; it makes new ones and abandons the old ones ¹.

The golden rule

That’s why rebasing comes with one rule, Pro Git’s single-line warning ¹: never rebase commits that other people already have and may have built on.

If you rebase commits someone else already has, their copies and yours now hold different commits for the same work, and sorting that out is painful ¹. So:

• Rebase your own local work, before you share it, to tidy it up or bring it up to date with main.
• Merge once work is shared.

For this course’s projects, which are yours alone, rebase freely. On shared branches, don’t.

Rebase conflicts

Replaying commits can hit the same conflicts a merge can, but one commit at a time. Git stops at the commit that conflicts ²:

1. Fix the file, as in the last lesson, and git add it.
2. git rebase --continue to carry on with the next commit.
3. Or git rebase --abort to put everything back as it was before the rebase.

Tidying commits: interactive rebase

git rebase -i opens a list of your recent commits in your editor and lets you rewrite them before sharing ^{1 2}:

me@linuxbox:~/garden$ git rebase -i main

pick ce75ff3 Plan the compost bin
pick 09e3458 Add compost schedule
pick 7a1b2c3 Fix typo in compost plan

Change the word at the start of a line to say what to do with that commit, then save and close:

Reorder lines to reorder commits. The classic use: three messy commits (“WIP,” “fix,” “fix again”) become one clean one before you share the branch. The same golden rule applies, since every rewritten commit gets a new ID.

Merge or rebase?

Both are fine, and teams choose their own convention ¹:

• Merge keeps the true history: when things happened, in parallel.
• Rebase gives a tidy, linear history that’s easier to read.

A common habit: rebase your private branch on main to bring it up to date and clean it up, then merge it into main.

Your turn

So

Rebasing replays your commits on top of another branch, giving a straight history; each replayed commit is new, with a new ID. So rebase only work nobody else has: tidy and update your own branches, squash messy commits with git rebase -i, and merge once work is shared. In a conflict, fix, git add, git rebase --continue, or --abort.