This week in my open source course, I’m working on Lab 3, where we are learning how to use git merge in different situations and understanding the concepts behind it. The first type we learned was fast-forward merge, and the second was the three-way recursive merge.
I am currently working on my repo repo-snapshot with two issues: implementing a --grep option to search for keyword in files issue-8 and a --preview option to display only the first N lines of file instead of full content issue-9.
As I mentioned above that I made these two features in separate branches for this OSD600 Lab 3.
--grep: Includes only files that contain the specified keyword.
--preview: Shows only the first N lines of each file instead of entire content.
I created the issue-8 branch using git checkout -b issue-8 for the --grep feature. After finishing it, I switch back to the main branch and created another branch issue-9 with git checkout -b issue-9 for the --preview feature.
After finishing both features, I merged them back into main. First, I merged issue-8 into main with git merge issue-8, which resulted in a fast-forward merge because there were no conflicts. However, when I merged issue-9 with git merge issue-9, I encountered conflicts in src/index.ts and README.md.
I opened both files, reviewed the conflicts, and decided which changes to keep or whether to combine them. After resolving the conflicts. I staged the files and ran git merge issue-9 again, which completed successfully. Finally, I pushed the changes to the main branch.
I learned that when multiple branches are created from the same base branch, conflicts are more likely to occur if different people (or even myself) make changes to the same parts of the code in parallel.
To avoid conflicts in the future, I think it is helpful to regularly check for upstream changes on GitHub, or communicate via comments before making changes that might overlap. This can help keep the development process smooth and reduce merge conflicts.
Top comments (0)