How do you use git rebase? Let's go through one use case

Git rebase is a powerful tool that allows developers to reorganize and clean up their commit history, such as by squashing or fixup-ing multiple commits into a single commit, which can be useful when submitting pull requests.

Published on: 2024-04-23

Written by Schalk Neethling

I have been making these short (1 to 5-minute) videos covering a specific topic that I use daily or frequently. I have been posting them to my YouTube channel but they have not gained much traction over there so, I thought I would share them here along with an extended transcript.

If you like this one and want to see more, please let me know in the comments. If there is something specific you would like me to cover, same deal. 😉 👍

Let’s say you opened a pull request and then reviewed your code and realized there’s something that you forgot or want to change. You could make the change, add a new commit, and push to your code hosting service of choice, but now you have two commits.

While using multiple commits can be incredibly useful, I like to start my initial pull (merge) request with a single commit. This is a general practice I picked up while working at Mozilla and it has served me well.

Ok, good to know, but what do you do when you inevitably run into this scenario? In these instances, git rebase is your friend.

After you have added your new commit, type the following in your terminal:

git rebase -i main

The -i above will put you into interactive mode and main is the branch against which you want to rebase. When you press enter, you will see something similar to the following:

pick 4ad8867 page: identity federation product page
pick d57c578 small prose change

# Rebase 2004347..396a1b6 onto 2004347 (2 commands)

The above will be followed with a lot of documentation concerning the command and the various options you have.

Note: Addressing all of those is not in the scope of this post, but if you would like me to cover this in more detail, let me know.

For this use case, I almost always use fixup over the other options. The reason I use fixup over squash is that I only want to keep the commit message from the initial commit. That then is also the primary difference between these two options. Let’s fixup our commit history:

pick 4ad8867 page: identity federation product page
f d57c578 small prose change

# Rebase 2004347..396a1b6 onto 2004347 (2 commands)

Once you have done the above, you will be left with a single commit and only the initial commit message. Great! All that is left to do is push this to the remote repository.

If you try to do this using git push origin branch-name, you will encounter an error message and Git will not allow you to push to the remote. This is because the above action changed the history (as mentioned above) and Git generally does not want to encourage this.

However, we are okay with having changed the history so we can use the -f (force) flag to tell Git that we know what we are doing and to allow our push to overwrite what exists on the remote branch.

git push -f origin branch-name

With that, we now have our most recent changes on the remote branch, but still only have a single commit using our initial commit message.

I hope that you found this helpful. As mentioned earlier, if you would like more of these, have specific topics you would like me to cover, or have any other feedback, please let me know.