Git Interactive Rebase Is Amazing

Beginner's guide to Git Interactive Rebase

Posted by Chaitanya Shahare on Sat, Jun 8, 2024

If you are like me and just at the start of your coding journey, git rebase --interactive might be a scary command. I feared that if anything went wrong I would lose a lot of my code and have to do that work all over again.

But that was the point of using a version control system like git, to not worry about changing your code. Git is here to save our code not to destroy it.

That said Git Interactive Rebase is a powerful command, if not used right it can cause some problems you wish you didn’t have.

Although, most such problems can be fixed by git rebase --abort, frankly, it’s my favorite git-rebase command. XD

This blog post is not about what git rebase is, what are its use cases, etc. This article will focus on successfully using interactive rebase when you need to. I recently had to do it and it was my first time rebasing in such a large codebase, it was quite intimidating, so I’m writing this blog post. To help my future self and others in the same situation.

When to use interactive rebase

When you want to

  • change the order of commits
  • squash commits
  • delete (drop/remove) commits
  • edit files in commits
  • fixup
  • exec

but we are just going to cover

  • changing the order of commits
  • squashing commits

How to use interactive rebase

Let’s assume the following git history:

1st

let’s visualize this the git log --oneline --decorate --graph command

2nd

Here, 1.1, 1.2 are commits on the main branch and 2.1, 2.3, 2.2 are commits on the feature-2 branch.

Issues to fix

  1. Here the commit messages on the feature-2 branch are out of order 2.1, 2.2, 2.3 is the correct order of the commits.

  2. We want to squash 2.3 and 2.2 commits together with the commit message 2.2

Let’s fix the order of the commits

We can use the following command to rebase the last 3 commits interactively

git rebase --interactive HEAD~3

alternatively, use -i flag

git rebase -i HEAD~3

here, HEAD~3 means the last 3 commits.

The above command will open your default editor, usually vi by default with a file like in the image below.

3rd

Note: Here the commits are in chronological order from top to bottom (latest at the bottom). unlike the git log command where the commits are in descending order (latest first).

As described in this file we can edit the word to the left of the commit hashes, which is pick by default to other words like squash or reword to perform specific operations on a commit.

But we want to fix the order of the commits in this rebase.

We can swap the positions of the commits 2.2 & 2.3, that is swap line no. 2 & 3, which will look something like this,

4th

Now, save and quit the file, if you are in Vim press the following keys escape key, :wq then enter key.

You’ll get a message like the following,

5th

Now our git history looks like the following diagram

6th

7th

Now our first issue is resolved using git interactive rebase! 🥳

Let’s Squash Commits

We can use the same command as before to start another interactive rebase on the last 3 commits

git rebase -i HEAD~3

We again get a similar file with the commits in the following order

4th

now we want to squash 2.3 into 2.2, for this we will edit the word before the commit 2.3 from pick to s or squash

8th

Save and quit the file.

Git will open another file similar to the following

9th

You have to decide which commit message to keep the first or the second. For this demo, we will keep the commit message 2.2. So we can either delete the 2.2 or add a # before it to ignore that message, like so

10th

Save and quit the file.

Now our git history looks like the following diagram

11th

12th

You’ve successfully squashed a commit using git interactive rebase! 🥳

Conclusion

Git Interactive Rebase is a helpful tool that should be in the pocket of every software engineer. It gives us a way to edit the git history. Remember to only rebase personal or unpublished branches, we should never change history of a public branch on which other people might be working on, as a rebase changes the hashes and they are essentially new commits with the information from the old commits.

I hope you found this article helpful.