Polish my git feature branch before merging or submitting for review
It is a good practice to commit as often as possible while you work on your personal feature branch. That helps you trace your changes as well as to have a backup to jump back to in case something goes wrong terribly. However such git branches with dozens of commits (that may not make sense) are hard to merge and review. In this lesson we’re using an “interactive rebase” to adjust our git history.
Instructor: [00:00] I've been working on my app refactoring feature branch. I usually follow a best practice, which is to comment as often as possible. This is really useful. In this way, I always have a backup point in case something goes terribly wrong. I can always jump back and resume the work where I have left.
[00:17] However, as you can see, these comment messages are pretty cluttered up. For instance, here, I started to work apparently on the intro text section, then on the intro style, which seems to be a work in progress. Then here, I was probably in a hurry. I didn't even formulate nice comment message. Apparently, up here, I concluded the intro section style.
[00:37] If I want to submit this for review because my branch is basically done, then I don't want to push up all of these into a pull request. My colleagues which have to review this would have to go through all of these comments, which in the end are not even meaningful.
[00:51] Before merging or before submitting for peer review, we really want to clean up our branch into some meaningful messages and even remove some messages which don't make sense.
[01:01] In this specific case, I want to refactor here up to that app refactoring origin pointer. That was the last time I submitted to remote repository. I copy here the identifier of the comment. Then we can do a rebase interactive, which is done with the "-i." Then we basically provide here that comment identifier.
[01:23] Now we get basically representation of all the comments that have happened basically from that hash onwards. In front, you can see these keywords, which tell Git what it should do with the respective comment message. Below here, we see the various comments you have at disposable.
[01:37] Let's clean up our history. First of all, this comment here is fine. We can leave it as it is. The next one, we want to reword. We want to change here that work in progress into some more meaningful.
[01:49] The next one here, we actually want to remove in the sense of the comment message, but we want to keep the changes who happened inside there. We want to use that fixup. This is like squash, which uses the comment but melds it into the previous comment.
[02:02] We want here to really squash basically but discard also the comment's log message because it's not meaningful. I use the fixup. Here as well.
[02:13] Then we basically close our editor here. Now we go into interactive rebasing. You can see Git basically took the first comment because we said to pick it as it is. On the second one, however, it stops because said we want to reword it.
[02:28] Here, I simply want to add "Add intro section style." Then we save. All of the other comments will simply be merged on top of it. Now let's do a "git log" again. Now we can see this history is quite clean.
[02:44] We have here the "Add intro text section," which we left as it was. All of the other comments have now been merged into a single one, into a new one, which is now called "Add intro section style."
@Erik thanks so much for the nice feedback 😊
I really appreciate how this course is providing useful examples and also mentioning best practices for devs. It's great knowing that I can take the time to go back and polish things up before having the code reviewed.
I've mostly been working independently on projects, so this thankfully helps me understand the importance of being mindful of my coding style and organization. Then after working on a contract, others who get hired later on can benefit from the effort I put in to learn how to properly organize my work.