This week I added a couple more new features to my Open Source project repo, go-go-web, a program that converts TIL posts in txt or md format to html.
The first feature I added was the ability to parse code blocks in Markdown files. Link to issue
Fenced code blocks written in Markdown such as
```
int x = 100;
int y = 200
int z = x + y;
```
will be converted to html code blocks inside <pre> tags:
<pre>
int x = 100;
int y = 200
int z = x + y;
</pre>
Inline code such as `console.log("Hello");` will be converted to html inline code inside <code> tags:
<code>console.log("Hello");</code>
The second feature I added was the ability to parse horizontal rules in Markdown files. Link to issue
Horizontal rules denoted by --- will be converted to html <hr /> tags.
My Process
My process involved first creating two issues for the two features I planned to implement (#8 #9). Next I created two new branches off of main to work on these two issues. I finished working on issue #8 on the first branch and committed my changes. I then switched to the second branch to working on issue #9 and committed my changes there.
When both features were completed, I switched to my main branch and merged the first branch. This went smoothly. Then I merged my second branch, and there were merge conflicts. I was always intimidated by merge conflicts in the past; however it turned to not be as difficult to resolve as I had thought. There was only one file where the conflict occurred, so I analyzed that files in VS Code and I saw that there were a few lines of duplicated code after the merge, as well as one line of code from the second feature that should go inside an if block of the first feature. I made the adjustments to that file and did git add and git commit again. I also tested the program to ensure that both features worked and no existing feature was impacted. When I was satisfied, I pushed my changes.
After my features were implemented, I closed my original two issues with comments linking them to the two commits I made (See first commit, See second commit).
Resolving Issues
I had a merge conflict problem occur when I attempted to merge the second branch. I researched how to deal with merge conflicts online, and then I decided to look at the conflicting file and manually fix the code there. I also had trouble deciding whether to update the version and README file in my first or second branch. I did the update in my second branch, but next time, I will do these documentation updates after my two branches are merged and working.
I learned that merge conflicts were not as intimidating to resolve as I had previously thought! And I found that having multiple branches is a good way to divide up the work that needs to be done on a large project. I also learned that if the new features did not change the existing code and only added to it, there should not be many merge conflicts between branches.
Next time I need to make changes to a project, I will use branches for each new feature or fix I need to implement. I will also try using Git Mergetool to resolve my merge conflicts.
Top comments (0)