DEV Community

Marco Pasqua
Marco Pasqua

Posted on

TIL Rebasing and Amending in Git

Today I learned rebasing and amending in Git. To test this out, I refactored my txt-to-html-converter program. I'll talk about the process of refactoring it below.

Refactoring the Program

When looking at what to refactor in my code, I noticed quite a few lines of duplicate code that exist within the logic of my text_to_html function. This was enough for me to make 4 separate commits on a new branch that I made for refactoring.

  1. The first issue that I noticed in the text_to_html function, is that I have the same logic to create an output file for if the input is a file or folder. While this code works if an issue ever came up or I wanted to change something with the logic, I would have to edit the two separate parts of code. To fix this, I created a new function in my helper.py file. This function is simply called output_file_creator. Thanks to the creation of this function if an error ever occurred or I did want to change the logic of the way the output file is created I can change it in one part instead of two separate areas. I tested it out and found no issues, so I made a commit.

  2. The second thing that I noticed in the txt_to_html function is that I check to see if the file in the input path is a .txt or .md file. I do this twice in the function, and I wanted to fix it in case something like what I mentioned in the previous point were to happen. To solve this, I created another function in my helper.py file. This function is called extension_checker and in it I have taken the logic that checks if a file is .txt or .md and returns true if it is, and false if it isn't. It's once again another simple fix the txt_to_html function, that helps to prevent some issues I could face in the future. I tested the new function out, and found that everything was working. So I made a second commit and moved onto the next issue.

  3. The third thing I noticed in the txt_to_html function was that I had duplicate lines of code for opening the output file for writing. So I just made a new function called write_to_html. This function would open the output file for writing and pass it the contents of the file so it can write to the output file and then close it. This was done so I can only worry about needing to made changes to logic in one area, similar to the other issues I found. Just like the ones before I had no issues running it and so I made a commit.

  4. The last issue I found was that I had the same logic to check if the input file was .md. I did have some trouble thinking about how I should go about fixing this, as I could use have a variable hold the result of extension_checker function, and then have it execute the parse_md function if the variable held the value true. But this wasn't a great idea, mainly because if the function returned true for a .txt file, then it would enter the parse_md function. I also noticed this issue, and I was concerned that it would affect performance for .txt file conversion as it would enter the function and do pointless stuff to the .txt file. To fix this, I made some adjustments to the parse_md function. I added in the conditional statement that would check to see if the input file ended with .md or not. So this way, I don't have the same line written twice in the txt_to_html function. I also renamed the parse_md function to check_md_and_write to have the name match the purpose of the function. I don't feel like this solution is perfect though, as I would like the program to not enter the function at all if the input file was .txt. But for now this works out and helps to reduce duplicate code and make my txt_to_html function look cleaner. Once I completed the change, I tested it out and found no issues. So I made my fourth and last commit.

Rebasing My Commits

I now had four commits that weren't pushed to my repo. However, I didn't want my repo to display my most recent commit. I wanted it to display a summary of all four commits. To solve this, I used git rebase to squash 3 of my commits into the first pick. So this way they would all be one commit. However, I wasn't done here, as although they were all one commit, I still needed that summary of what was done. So I used git commit --amend to get the 4 commits that I just squashed into 1 and change the description of the commit. This gave me the summary of the commits that I wanted. I felt happy with the summary I made and pushed it to my repo.

Conclusion

Overall, I enjoyed refactoring my program to help make things cleaner and possibility a little faster. There may be a chance that I missed out on something that I could've improved, but if I spot anything like that in the future I will make the improvements needed. In terms of rebasing and amending, I really liked using that. I think that it could help make my history of commits look much cleaner, as by squashing them all into one and amending it. I will most likely use this for future additions that I made to my program, and it could maybe help me with looking for where bugs are. Since I can look at the latest feature addition that I made, and maybe pinpoint down where an issue would be, without having to scroll through several old commits. Thanks to everyone who read up to here. Catch you in the next post!

Top comments (0)