DEV Community

Namatuzio
Namatuzio

Posted on

Rebasing using Git

Today I learned about the incredible functionality of rebasing and amending commits in GitHub.

I've always heard about rebasing repositories from classmates but never had to rebase a repo myself. It was quite a rewarding experience to finally work with rebasing myself. I've previously refactored code before but never to the depth that git requires from its users, especially when trying to find refactoring patterns inside my code. It feels great to finally understand the strategies and techniques required to use this feature. So anyways, what changed?

File Extension Function

One of the most glaring issues with my codebase that I noticed right from the get-go was how many times I would make an if statement to check file extensions. I refactored the logic into a function; utilizing the extracting functions technique which mitigated redundant code and made everything look a lot easier on the eyes.

Argument Parsing

Moving on, I noticed the abundance of if statements I was using for my argument parsing, especially for the TOML file parsing. Luckily, Python is great at managing itself allowing me to almost entirely simplify what I was previously doing by using the or operator when assigning variables.

Relative File Path Simplification

Finally, I simplified and refactored the relative file path functionality within my program. It was very messy before taking up around 7 or so lines in total, which I was able to shed about 4 lines off the total.

Rebasing, Amending, and Squashing

The main course of all this work was being able to finally use the rebase command. It was called with git rebase <branch> -i with the -i standing for interactive. It opened up the VIM editor and gave you a useful set of arguments to assist with the rebase though I only used 2; pick and squash. pick is used for taking a commit as-is which I used as a base commit for my rebase. On the other hand, squash merges the selected commit with the one before it so it ends up becoming a sort of hierarchy where you flatten the latest commits into the earliest commit. This then combined all the commit messages together, which I ended up changing using git commit --amend to make it more concise on what I refactored in my code.

Next steps

I feel like more can be simplified which is why I absolutely want to find more, but even after asking a friend for an opinion on what can be changed, we struggled to find one that would make meaningful changes to the codebase. It may just be a time thing - maybe I'll have an epiphany and know exactly what I can change - but overall, the experience was great.

Top comments (0)