Git Branching and Merge Strategies

Main Idea

The main objective was to gain experience with git branches and practice different merge strategies by implementing two features on separate topic branches. Through this process, I encountered both fast-forward and three-way recursive merges.

Issues

I created first issue to track the file size display and i created second issue. Both features were added to my repo.

Implementation

For the file size feature, I used std::filesystem::file_size() which efficiently retrieves file sizes without manually reading files byte-by-byte. The second feature involved implementing a md --dirs-only or -d flag that modifies the output to show only directory structure without file contents.

Confusing Challenge

Before solving these issues, i accidentally implemented file statistics(i was refactoring my code to make it more maintainable) in main branch. This meant my file size feature was on issue-9 while statistics was on main. I merged main into my feature branch to combine them and test the new feature properly. I decided to merge main into branch which caused confusing git history .This taught me to keep all feature work on branches and avoid direct main commits. Then when i merged first issue ,it was smooth(fast-forward). When i merged my second branch Vim popped up and i wrote a new commit merge commit. I got confused where i implemented file statistics. I did not have any merge conflict because i did not touch a lot of code and i used different modules when i was making changes. Lastly i forgot to add 1 line to README file in the second issue which was related to the functionality of the feature. I realized it after pushing to main.

Rewarding Knowledge

I reminded myself that writing git status or git branch is a perfect habit because it prevents confusion about which branch you're working on. Also, I understood that you need to commit changes before switching branches to keep your working directory clean. I also realized that fast-forward merges happen automatically when possible, while three-way merges create explicit merge commits. Because Three-way merges happen when branches split apart. Git finds their common ancestor and uses it as a reference to combine changes from both branches into a new merge commit. This resource About Branching and Merging helped me understand better.

Future Decisions

I understood that it is better to refactor the code first then create a branch and add a new feature instead of adding it later to the branch. Also, i could create a new branch instead of using the current one and solve this issue in a nice way, because at the end of the day creating new branches are not expensive. Lastly i will pay attention to not forgetting README file when a new feature is added.