Refactoring
As you may know, I admitted that palpatine was a bit of a mess, in my previous posts in this series.
While this project is something I enjoy wholeheartedly, it is also a project I get grades from. Due to deadlines, quick decisions had to be made, therefore, there is room for improvement.
Ultimately, I decided to refactor the codebase, get rid of the duplicates and make it more readable in a different branch called, refactoring. Meanwhile, I didn't forget about unit tests. Currently palpatine doesn't have any, but later in a couple of weeks I will be adding them as required. Refactoring the code and making sure you are satisfied with how it looks, plays a big role in the process of writing tests. It is much easier to write tests for code that is well structured and easy to understand.
The plan
I ended up with a new file FileHandler.h with the base class Handler and the classes MarkdownHandler , TextHandler which inherits the base class. They have virtual functions that are overridden in the derived classes, so that I can use the concept of polymorphism respectively. This reduced the lines of code drastically, making it more robust.
Rebasing
After I was satisfied with the refactoring, I rebased the branch refactoring. If you worked with git in depth before you probably know what rebasing is.
For my case ? I was only getting along with simple git commands (push,pull,commit,merge) until this 2k22Hacktoberfest.
As we are in the middle of
Hacktoberfestand if you are raising PRs in big projects, you probably know what I am talking about. (strict guidelines on linting, commit messages, rebasing, squashing, etc.)
Rebasing is one of the most powerful/useful commands in git, but it can be tricky to use it correctly.
I had to do this because I had a lot of commits that were not related to the refactoring. I wanted to keep the history clean and easy to read. I used the following command to rebase the branch:
git rebase main -i
You also can use git rebase -i HEAD~<number of commits> to rebase the last <number of commits>.
Since I am specifying -i , --interactive This will open an editor that you specify in your git config. (i.e set the editor as VSCode -> git config core.editor "code --wait"). This editor shows all the commits that I want to rebase and allow me to specify what to do with each commit. You can change the pick to squash or fixup to combine the commits.
Combining multiple commits (squash)
After rebasing, I combined the commits that were related to the refactoring. Meaning that, all the commits in the branch refactoring would get squashed into one single commit. This is achieved by changing the pick to squash in the editor.
I use
git log --graph --all --onelinea lot. It shows the history of the commits in a graph. It is very useful to see the history of the commits and the branches.
Update commit messages
After squashing the commits, you may still want to edit the commit message, maybe it wasn't quite right. You can do amended commit which will change the previous commit message:
git commit --amend
Takeaways
The real power of interactive rebasing over merging is that, if you check the history of the commits from the resulting main branch, it will look like you have only one commit. (i.e check my squashed commit for palpatine 8ceba56) This is incredible in a way that to everyone else, it looks like you're a "flashy" developer who implemented all the code with the perfect amount of commits. But in reality, you have multiple commits that you squashed into one. Indeed interactive rebasing is vital for keeping the history clean and easy to read.
Top comments (1)
Fantastic post!