DEV Community

Eakam
Eakam

Posted on • Edited on

Merging parallel branches without PRs in GitHub

For week 4 of my course in open-source development, I was tasked with adding two more features to my ssg project rost_gen. However, I was supposed to work on both at the same time on different branches and merge those branches into the main branch once both implementations were complete. Normally, I would use pull requests and not merge directly into the main branch.

I created two issues to add an option flag to specify the language of the generated html document, and to parse '---' markdown as a thematic break (horizontal rule or <hr> tag). After creating the branches for these issues through the UI on the issues page, I started working on implementing the new features.

Prior to this, I was parsing command line arguments manually using if statements. So, this also allowed me to address another issue to use clap for argument parsing. I was surprised by how much I was able to simplify my program by using clap to define the same logic. And once that was done, adding support for another flag was rather easy.

Further, adding support for parsing thematic breaks/horizontal rule markdown was even simpler. Since there was existing support for Heading 1 markdown (<h1> tags), all I had to do was add an else statement to check for the new markdown rule.

However, I discovered some unrelated bugs while testing my changes. Apparently I had previously forgotten to check if the specified output directory already contains a file with the same name as an input file. As a result, the generated html gets appended to the end of the existing file instead of overwriting existing content. I also found that the title parsing logic causes a blank line to be added to the title. Since these were unrelated to my changes, I created two more issues to fix them later.

Finally, it was time to merge my changes into the main branch. As expected, the first branch was merged smoothly (fast-forward merge). I was expecting to run into some conflicts when merging the second branch but it turns out there was no code overlap between the two and git automatically merged them (ort strategy) with the default merge message.

Even though this process went smoothly, I found it difficult to go through the commit history. Since I tend to commit small changes, I end up with multiple commits for adding a single feature. Usually, I would use pull requests so I can squash and merge before merging. Then, I can look for the PR merge commits and read the description to quickly see what was changed. Also, I do not need to manually close the issues if I link them in the PRs.

Top comments (0)