TIL Rebasing and Amending in Git
Tags: beginners, github, git, python
Published: 2023-10-13 21:40:09

Today I learned rebasing and amending in Git. To test this out, I refactored my [txt-to-html-converter](https://github.com/Pasqua101/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!