Transfer a whole branch of commits onto a new base commit, and learn why that rewrites history.
In Level 14 we mix things up a bit. As you have probably gathered, in Git there are often several ways to do something. Back in Level 8 you used git merge to combine branches, and you saw the result depends on whether the branches had diverged (a merge commit) or not (a fast-forward).
But just wait, my little sapling. There is more. A totally separate command can rearrange branches: git rebase.
Fundamentally, rebasing changes the base commit of a branch. A base commit is the starting point where two branches split off from one another. So re-base literally means moving all of a branch's commits onto a new base commit. Get it? RE-BASE.
In scrapbook terms, it is like transferring all the pages in one section to the front of a different section. But before you can change the base of a branch, you need a branch to change.
Create it:
git branch featureYou created a branch called feature. Three green markers now stand on the same page. dev is still the active branch, so before switching to the new one, you will make one more commit on dev.
It is STILL your birthday, apparently. You update the print statement in birthday.py to:
print("It's STILL mah birfday!")
Stage it and commit it, as usual.
To the mat.
git add birthday.pyCommit on dev:
git commit -m "Still my birthday"HEAD and the dev marker moved forward to the new page, because dev was the active branch. main and feature stayed behind on the old page.
Switch to the new branch:
git switch featureHEAD moved back to sit on the feature marker on the prior page. feature is checked out; it is the active branch now. Your files roll back to that page too, so the STILL-birthday edit is not on your table. It is safe on dev.
Now create two new files to hold the code for the new feature. In feature.py:
print("This is a cool new feature!")
And in feature.html:
<title>A cool new feature</title>
Normally you could stage and commit both at once. For the sake of this exercise, stage and commit each file separately, so there are two pages to move.
Just the Python file for now.
git add feature.pyOne page on feature.
git commit -m "Add feature.py"And now the HTML file.
git add feature.htmlSecond page:
git commit -m "Add feature.html"Awesome stuff. That is one heck of a feature. Note how the two commits on feature have diverged from dev: two pages on feature that dev does not have, and one page on dev that feature does not have.
Let's pretend the feature is complete. Your next task is to integrate the two new feature pages into dev, so you can share the feature with your team.
As you learned in Level 8, you could use git merge for this. But what if you want to avoid that good-for-nothing, UGLY merge commit? This is where git rebase comes in. It brings your two feature pages onto a new base commit: the tip of dev. In scrapbook terms, it moves all the pages of the feature section to the front of the dev section.
git rebase <new-base>
You are on feature. Which command transfers its two pages onto the tip of dev with no merge commit?
Here is the catch, and it is not all acorns and berries. Rebasing REWRITES those commits onto a new base. You told Git: change the parent of the first feature page to the tip of dev. News flash: a commit's ID depends on the ID of its parent. So the first feature page got a new ID. That page is the parent of the second, so the second got a new ID too. And so on, until every page in the section has been rewritten.
The old pages are still in the binder for a while, faded, unreachable. The identities of the rebased commits were quite literally recalculated to move them.
So why is this bad? It depends. If the commits you rebased have not been shared by pushing them to a remote, meaning they are still LOCAL, there is usually no problem with rewriting them. But if you already pushed them, their IDs are in other people's repositories. Rebase now, and sending them to the remote again gets... complicated to reconcile.
Rule of thumb for commands that rewrite history: only use them on LOCAL commits that have not been pushed, unless you really know what you are doing.
One more option worth knowing: git rebase -i <commit> runs an interactive rebase, which lets you tell Git what to do with each commit: keep it, modify it, combine it with others, or delete it. Advanced, very powerful, and worth looking into once you have mastered the basics.
The graph appears here when the first command runs. The simulations are drawn by git-sim from a real repository.
The scrapbook picture appears as the story is told.
Level 14 complete
🎉 New rank unlocked
git rebase <new-base> transfers a branch's commits onto a new base commit. It is most often used to cleanly move commits from a local feature branch onto a branch you plan to share, keeping a linear history without merge commits. The downside is that it rewrites commit IDs, so only rebase local commits you have not pushed. See you in Level 15.
Get new levels and walkthroughs
New lessons and command walkthroughs, plus a Git trick or two. Your progress stays saved in this browser either way.
Free: the Git essentials cheat sheet
The 16 Git commands you'll use most, each with a picture of what it does to your repo, drawn by git-sim, on one printable sheet. Or pick your own 16. We'll email it to you, along with new levels and walkthroughs.