Over the past week, I’ve been working on two features for my Repository-Context-Packager project. But this was my first time seriously managing parallel branches, resolving merge conflicts, and getting multiple features merged into main.
The first feature I implemented is issue-7.
And second feature is issue-8.
To do this two features, I created two separate branches and after finishing both features, I started the merge process. Merging the issue-7 branch into main was very smooth. Git performed a fast-forward merge, which simply moved the main branch pointer forward without creating a new merge commit. But things got interesting when I merged the issue-8 branch. Since both branches modified overlapping files (README.md and src/cli.js), Git couldn’t merge them automatically. I had to manually resolve the conflicts, making sure both features’ changes were preserved.
After resolving the conflicts, I staged the changes and completed the merge with a commit. The final merge commit is here: Commit 2a927ed
Parallel branches that touch the same files will collide. Resolving conflicts wasn’t too hard once I carefully compared changes, but it reminded me how important clear code organization is. Seeing the difference between a clean fast-forward merge and a conflict merge, I learned a way to keep a merge commit: using --no-ff to keep history explicit.
Top comments (0)