Most of us know how to write good git messages. That’s great, since otherwise it’s painful in situations like trying to find why somebody commented that vital piece of code, and all you see is a bunch of “fix” messages. But what do you do when you realize that you missed something after committing your changes? Or when you need to make the corrections pointed out in the pull review? That’s when we can use git rebase to fix our history.
First of all, it is important to make sure to have your git’s text editor correctly configured, or this process can be so much scarier. When I first tried to do this, I had Vim as my text editor, and I’m clueless about how to use that. So, if you don’t know anything about Linux like me (which I recommend you to learn), or just rather use something else, check this guide.
Rebasing
Let’s go back to the pull review example. You have just committed your files and are anxiously waiting for those approvals. But it’s hardly that simple right? Now your colleague just pointed out that you aren’t following any method naming best practices! Even worse, you have accidentally added an empty line. How can we name our next commit now? Thing is, you don’t have to, you can just squeeze them in the previous commit. But first, you will need to commit your new changes. You can just throw in any message, trust me, we can fix it.
After that, we need to run this command:
git rebase -i HEAD~2
Let’s break it down to see what’s going on:
- git: git, right?
- rebase: this one is pretty complex to explain, but in short, it allows us to say “Hmm what if this branch started from a different one?” among other ways of rewriting history. You can read more here.
- -i: interactive, meaning it will open our configured text editor for us to do our magic.
- HEAD~2: We will be working with the latest 2 commits. You can change the number to whatever you need.
And then you will get something similar to this:
As you can see, git provides a bunch of ways for us to fix our mistakes. In this case, the first 2 lines (remember HEAD~2?) represent our current history, and everything else is documentation that will be ignored. Currently, what we need to do is to change our 2nd commit command to fixup, which will cause it to be merged with the previous commit, and use its message as well. Now save your file, close your editor, and your git operation should go flawlessly.
I would like to to highlight the interactive flag wildly changes rebase’s behavior. I’m not going through it in this article, since it requires one on its own, but you can see how rebase naturally works here, for example. (Thanks, Jesse!)
Pushing your changes
All that remains to do is to push it. If both commits were in your machine, you should be able to do it normally. But, since we are working with a commit under review, that means it has been pushed already.
So in order for us to be able to do it, we need to use the -f parameter, which stands for faith force. And why is that? It’s because git doesn’t understand how it had 2 commits before and now just one, so it needs us to confirm that we know what we are doing.
Conclusion
Rebase is a powerful command which can save our lives, or wreck our history, so I advise you to tread carefully when using it. When first using it, check with your Senior if you are doing the right thing. Unless you are the Senior, so in this case, good luck my brother.