
5 months ago when I first started contributing to open source, something made me nervous all the time.
Every single commit message on the branch had to follow a format, or your pull request doesn’t get merged.
Specifically, it should be: "PREFIX: Summary of what this commit is about".
What happens if you have worked on a pull request for 2 months, but get the last commit message wrong?
Well…..
I decided that I didn’t want to know.
I used to hold my breath, and triple check everything before pushing. I even postponed opening a branch because I didn’t want to risk it.
To calm down and learn git, and eventually, interactive rebase, has been hands down one of the best investments a git user at my stage can make.
The good news is: it’s not rocket science. Take a look and tell me what you think.
Prerequisites: Some Git
Git basics such as clone, add, commit, push are better explained by many other authors. I would make the best of your time by putting links to them here:
For people who identify themselves as complete beginners, I recommend this clear guide with a hands-on project. It is brought to you by Anne Bonner, the deputy editor of Towards Data Science.
Getting started with Git and GitHub: the complete beginner’s guide
How Git Works By Paolo Perrotta
If you would prefer a course. I highly recommend this one.
This course is way advanced than this article. It dives way into the mechanisms and explains things from the root. It’s also filled with animations and real, concrete examples. As I’ve enjoyed it a lot, it is only natural to put it here for people interested in learning more.
Pro Git book
This book is also helpful. I didn’t get most of the concepts in How Git Works on the first few tries, but much of it came clear after reading this.
Prerequisites: Ways to mess up a commit
Two of the most common mistakes I make
- Wrong commit message (e.g. messing up the prefix)
- Wrong commit content (e.g. extra line, extra space)
Interactive rebase is far more capable than fixing these, but I’m focusing on the two since I run into them the most.
What is a Rebase?
Simply put, it is redefining the sequence of what happened in the past.
So what we’re actually doing, when changing the past, is first make a new thing happen.
Then we replace that new event with the commit that actually happened.

However, interactive rebase makes things pretty simple. Even if you don’t understand this part, it will not stop you from getting the core takeaways of this article.
Changing the Past
Step One – Pick the part of history you would like to modify
do git log
and copy the hash of the commit. It should be the 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a
in the example below
% git log
commit 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a (HEAD -> branch-name, origin/branch-name)
Author: my-username <[email protected]>
Date: Tue Sep 7 19:14:08 2021
Step Two – Copy the numbers, and start the rebase
Here’s the command
git rebase -i 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a^
Notice that it consists of
- git rebase -i
- the hash code
- ^
to put it simply, ^ means that you want to start changing the past from this point. It’s like an arrow that points to the place we would start.
If you will, something like git rebase -i 5a6e6cdc^
will also work, because they will just look for the hash that starts with the prefix.
Bonus Step – Use vim as your editor
If the previous step didn’t work because the editor doesn’t work with it, try this, and then step two again:
git config --global core.editor vim
This will allow you to do the interactive rebase in the terminal window. I prefer this and will provide further instructions on how to work with it below.
Step Three – Select the commit(s) you would like to modify
This is the most complicated step.
You should be getting something like this:
% git rebase -i 5a6e6^
hint: Waiting for your editor to close the file...
pick 5a6e6cdc63 The commit message here. Note by the author
# Rebase 71b43c0db0..5a6e6cdc63 onto 71b43c0db0 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
Take a look at all the commands! Git rebase -i is capable of so much. Yet for now, I’m only going to stick with the only one I use a lot: edit
.
Go change the pick
into edit
, then save and close the file.
If you’re using the vim editor like me, here are the keys to that:
i
= start editing. Up/down/left/right to navigate through the lines.
backspace
to delete the "pick" text. Type normally.
esc
=stop editing
:wq
= save w
and close q
enter
to execute
Step Four – Do the content edit
You have the code that you want to change. See for yourself by doing git status
. It should be as if you haven’t stage those files yet.
Make your changes now.
If you only want to change the commit message, just skip this section.
Bonus Tip – How to test the code by compiling before making changes during rebase
The harsh truth is that we can’t compile and test the code during a git rebase, but the good news is I have something almost as good.
If the commit you would want to edit is the latest one, this should work:
Before doing the rebase, make the changes and compile as you wish.
Then do git stash
. This is a command that’s a little like "cmd/ctrl + z" or "cut". It takes away all the changes and stores them away.
Later as you are rebasing and have arrived at this stage, do git stash pop
. This will "cmd/ctrl + v" or "paste" the changes here. Voila. You have the changes.
Step Five – git add, commit, git rebase continue
This hint message should show up in the terminal –
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
Do as it says, but first git add
all the changes. This is necessary to proceed.
Then git commit --amend
The following should show up in your editor:
Commit message here. Note by the author
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Tue Sep 7 19:14:08 2021
#
# interactive rebase in progress; onto 71b43c0db9
# Last command done (1 command done):
# edit 5a6e6cdc62 SCI: Set name of new file to tts, function name to ttsPickLB2NotebookTopic, and remove extra lines
# No commands remaining.
# You are currently editing a commit while rebasing branch 'sci-tts' on '71b43c0db9'.
High time to edit the commit message. You should be fine with the vim editor keys I have mentioned above. They work the same way.
Then wrap up the rebase with this.
git rebase --continue
Step Six – git push with force
Time to show your work.
Instead of git push
, do:
git push --force
This is because we have made changes to the history, which is conflicting with what is stored on the remote (on Github).
--force
means to "Do it anyway. I am certain that I have the right version".
After this, you should see the changes you want on Github.
If anything goes wrong…
git rebase --abort
this stops the time-traveling and takes you back to the normal state.
I hope this article finds you well
Sincerely I hope you will be alright with whatever git problems you are facing or might face in the future.
Instead of wishing that you will never run into any problems, I would say…
Lasting happiness comes from the ability to deal with the bad stuff in life.
and I wish you will cope with yours well.
The Medium membership made it possible for me to learn enough and write for Towards Data Science. Sign up with my personal link, then let me know, and I will send you a pdf that shares my full journey.