Don't be afraid of Rebasing

In the last years I had several discussions if rebasing is a good thing or not. But in these discussion there has been always a misunderstanding what rebasing is and how to use it properly. Over these years I heard that rebasing is dangerous, that it hides something from certain teams or that it is just simply to complicated.

This article will cover what rebasing actually is and most important:

Rebasing is no dark magic

What is Rebasing

The definition of Rebasing is very simple: Rebasing moves several commits on top of a new base commit.

So we take a branch, and put it somewhere else.

Rebasing is not more, but can have various steps in between, like dropping commits, changing commit messages or change the order of the commits. But in the end it comes back, that the history of branch will be altered.

Rebasing is a tool for people to want their branches clean and make the follow-up processes like a code review much simpler.

Everybody has done some commits they want to revert, but without appearing in the commit history of the branch. This could be just a dumb code comment, a hardcoded password or just some nasty code.

Another reason is that you want to keep your branch up-to-date, so you won't run in so many Merge Conflicts at the end of your development phase, without merging the main^ branch consistently into your feature branch.

Or you just want to have neat history. Every commit is in the perfect order and in the right place. Pure perfection. Then Rebase is also for you, you little perfectionist.

Luckily there is Git Rebasing to cover our backs.

How to Rebase

Rebasing is relatively simple. Most IDEs like PHPStorm have also a feature which lets you rebase

But in my opinion, Git must be taught and learned on the console. So I'll show you how to rebase on the console.

 $ git checkout dinosaurs

We are changing to our dinosaurs branch

 $ git rebase -i master

With the command above we start the Rebasing of our dinosaur branch onto our master branch in an interactive mode -i . Interactive just means you can moderate the commits of your branch as you wish.

Rebasing is relatively simple. Most IDEs like PHPStorm have also a feature which lets you rebase

pick ce507d6 Adding dinosaurs because they are cool.
pick b055034 Adding mora roars because they are scary

# Rebase von 0075491..b055034 auf 0075491 (2 Kommandos)
#
# Befehle:
# p, pick <Commit> = Commit verwenden
# r, reword <Commit> = Commit verwenden, aber Commit-Beschreibung bearbeiten
# e, edit <Commit> = Commit verwenden, aber zum Nachbessern anhalten
# s, squash <Commit> = Commit verwenden, aber mit vorherigem Commit vereinen
# f, fixup <Commit> = wie "squash", aber diese Commit-Beschreibung verwerfen
# x, exec <Commit> = Befehl (Rest der Zeile) mittels Shell ausführen
# b, break = hier anhalten (Rebase später mit 'git rebase --continue' fortsetzen)
# d, drop <Commit> = Commit entfernen
# l, label <Label> = aktuellen HEAD mit Label versehen
# t, reset <Label> = HEAD zu einem Label umsetzen
# m, merge [-C <Commit> | -c <Commit>] <Label> [# <eineZeile>]
# .       Merge-Commit mit der originalen Merge-Commit-Beschreibung erstellen
# .       (oder die eine Zeile, wenn keine originale Merge-Commit-Beschreibung
# .       spezifiziert ist). Benutzen Sie -c <Commit> zum Bearbeiten der
# .       Commit-Beschreibung.
#
# Diese Zeilen können umsortiert werden; Sie werden von oben nach unten
# ausgeführt.
#
# Wenn Sie hier eine Zeile entfernen, wird DIESER COMMIT VERLOREN GEHEN.
#
# Wenn Sie jedoch alles löschen, wird der Rebase abgebrochen.
#
# Leere Commits sind auskommentiert.

You could just save this state and the rebase on top the master would work. But I want you to have a look at the options that are available during a rebase.

If you change the order of the commits here, you actually change the order on the branch. So be careful, because this could lead to some merge conflicts if you don't know what to do, which can be really hard to resolve. But if each commit has separate files in it, there nothing to hold you back to put these commits in the correct order.

As you can see at the bottom you have a lot of commands that you can replace with pick at the top. You can drop commits, so they won't ever appear in the git history or squash two or more commits into one. Just try some and get used to them, these commands will help you to have really nice and nifty commit history.

When to avoid Rebasing?

The most important thing: Don't used Rebasing on shared branches!

What are shared branches?

A shared branch is a branch that more than one developer is using. So if you work with another developer on the same branch, never rebase it! Some teams don't use feature branches to get their code in, but development branches which will be merged after a period of time into the main-branch.

The main reason to avoid rebasing is that a rebase, changes the entire history of commits.

If you do change things in the past, you have to keep all the branches of the other machines up-to-date. And how would you do it? Git Pull or Git Fetch wouldn't work.

You'll have to tell the people.

You have to tell them that the history of this branch is not longer the same, is not correct anymore and that the branch has to be overwritten.

That is why most people avoid rebasing on shared branches. But if you use feature-branch approach for the daily-development work, you'll be absolutely fine. Because a feature branch is only used by one developer only.

I f*ed up my rebasing, what now?

Of course you can mess you rebasing up. But you don't have to worry much, because nearly everything is revertible in git.

We can use git reflog to look up what happened on your machine.

$ git reflog
ab5de35 (HEAD -> my-new-feature) HEAD@{0}: rebase -i (finish): returning to refs/heads/my-new-feature
ab5de35 (HEAD -> my-new-feature) HEAD@{1}: rebase -i (pick): Adding mora roars because they are scary
06244ee HEAD@{2}: rebase -i (pick): Adding dinosaurs because the are cool.
0075491 (master) HEAD@{3}: rebase -i (start): checkout master
b055034 HEAD@{4}: commit: Adding mora roars because they are scary
ce507d6 HEAD@{5}: commit: Adding dinosaurs because the are cool.
4ff4cdd HEAD@{6}: checkout: moving from master to my-new-feature
0075491 (master) HEAD@{7}: commit: Add a crocodile
dadf6f9 HEAD@{8}: commit: Adding Index file
4ff4cdd HEAD@{9}: checkout: moving from my-new-feature to master
4ff4cdd HEAD@{10}: checkout: moving from master to my-new-feature
4ff4cdd HEAD@{11}: commit (initial): Adding test file

You can reset your current HEAD to a previous version. Like HEAD@{4} before we started the rebasing.

Should you rebase?

In my opinion everybody should learn how to rebase and know what rebasing does. It can help you, as a developer, to create the commit story you want to tell.

If you had a fear what rebasing does, you should tackle that fear, because rebasing can be a powerful tool in your toolbox.

It is always better to know what a tool can do, instead of being afraid to use it.