Don’t Panic If You Ever Make the Wrong Git Commit. I’ve Got You Covered | by Taylor Zhancher | Towards Data Science

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.
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.
towardsdatascience.com
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.
app.pluralsight.com
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.
git-scm.com
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.
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.
do git log and copy the hash of the commit. It should be the 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a in the example below
% git logcommit 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a (HEAD -> branch-name, origin/branch-name)Author: my-username <myemail@gmail.com>Date:   Tue Sep 7 19:14:08 2021
Here’s the command
git rebase -i 5a6e6cdc63ecd1ad4c03ed004099d298b776e06a^
Notice that it consists of
git rebase -ithe hash code^
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.
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.
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
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.
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.
This hint message should show up in the terminal —
You can amend the commit now, withgit commit --amendOnce you are satisfied with your changes, rungit 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
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.
git rebase --abort
this stops the time-traveling and takes you back to the normal state.
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.