As said in the previous article, the change proposed by the reviewer is very simple, we just need to include the variable and changing our function. So, let’s do it now.
Note: If you want to stage the file via git-cli command execute the command below.
How we can see in the figure above, we changed the method and staged the file. Pay attention that we didn’t put any commit message, because we will use the --fixup option to do this commit.
The fixup option simply makes changes to a previous commit, that is, it fixes a previous commit, for that we need to know the hash of the commit and inform this to the fixup. To know the hash, we simply look in the git history. I use a very friendly format for this, run the command as in the picture below and you will get the same answer as me, of course the hash will not be the same as you will be doing it in your repository 😜.
A little help 😄:
git log --color --pretty=format"%C(yellow)%h%C(reset) %s%C(bold red)%d%C(reset) %C(green)%ad%C(reset) %C(blue)[%an]%C(reset)" --relative-date --decorateTip: you can put this command in the ~/.gitconfig file.
In my case the hash that I need is f0da59b , so let’s commit a fix up with this hash.
Now let’s see how our history turned out.
As you can see, the fixup used the same commit message as the past hash, this means that when the commits are squashed (we’ll see that soon) these two commits have turned into a single commit, thus fixing the problem and leaving the history clean and tidy commits, instead of having a bunch of commits with messages like “fix this” and “fix that” in our history. Cool right? 😎
Let’s now push the changes to our repository, it’s VERY IMPORTANT that at this point you don’t do any rebase (I know you thought about that), because if you do a squashnow, the reviewers have lost the references from the comments. Let’s just do a push.
Our pull request will look like the figure below, with one more commit.
And our conversation will have one more line where the reviewer can click to see if the suggestion was applied and thus resolve the conversation.
When the reviewer clicks on the fixup link or navigates to the commits tab and opens the commit related to the HTTP package he/she will see the screen below where he/she will be able to verify that the change has been made and thus, finally, resolve the conversation and approve the pull request.
Now that the pull request is approved, you might still want to think about rebasing (I know you thought about it again) but in this scenario you don’t need to use git rebase -i --autosquash to do the squash, we’re going to use the squash and merge option of our version control tool and it will do it for us, just change the option by selecting squash and merge as shown in the figure below.
When you click on this button, you will see the figure below and you must remove the fixupmessage from the box so as not to duplicate the commit history (not having two identical messages).
And finally, click in the confirm button and be happy! 🎉
To confirm how our commits turned into just one, let’s open the main branch’s commit history.
As you can see we have only one commit from our PR! Incredible, right? 😃
If you want to dig deeper, you can open the commit we made and see that the commit messages from all atomic commits have been squashed and put into the body of the final commit. Very cool, clean and simple.
We have reached the end of this series of articles, there is still a point to explore about the divide to conquer strategy where we can show the use of rebase, but I am not sure if I will do this article, but here is the information that we still have subject on this topic to explore.
Hope you enjoyed the content. Cheers! 🍻
Next: Hands-on with Atomic Commits — Part 8: Rebase (coming soon, maybe)
Previous: Hands-on with Atomic Commits — Part 6: Code Review
