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.
Top comments (0)