During this lab, I got hands-on experience working with parallel feature branches in Git and merging them back into the main branch. This was actually my first time doing proper merges, and I was a bit nervous about breaking anything in my repository. The project repository.
Features Implemented
The first feature I worked on was Directory-Only Mode --dirs-only (Issue #11). The goal was to add a CLI flag that prints only the directory structure of a repository, skipping all file contents. To implement this, I added a dirsOnly field in my Config class, updated the CLI parser to recognize -d and --dirs-only, and modified OutputFormatter::generate to skip file contents whenever dirsOnly was true. You can see the merge commit here: Merge Commit
The second feature was Custom Exclusion Patterns --exclude-pattern (Issue #12). This allows users to skip files that match a regex pattern while scanning the repository. I added a c_excludePatterns field to the Config class, updated the CLI parser to recognize -ep and --exclude-pattern, and updated RepositoryScanner to actually skip files that match the patterns provided by the user. The merge commit for this feature can be found here: Merge Commit
Merging Process
For both features, I created separate branches: feature/dirs-only and feature/exclude-pattern. Once I finished implementing each feature, I merged them into main using local console merges. Since this was my first time doing merges, I was a little worried about conflicts or messing up the commit history. That might be why my history ended up with four commits instead of the two I expected. Seeing those extra commits made me nervous at first, but I realized it was normal because Git creates merge commits when combining branches.
Challenges
There were a few tricky parts along the way. Handling relative paths in OutputFormatter was sometimes difficult because std::filesystem::relative could fail for certain paths. Another challenge was making CLI pattern matching work consistently; I had to normalize user-provided patterns and convert them to lowercase so that both --include and --exclude-pattern behaved as expected.
At first, I was nervous about merging and worried about potential conflicts. It was only after I merged everything that I realized I had actually created the second branch after finishing the first one, so conflicts couldn’t happen this time. I’m still learning how branching and merging fully work, and it showed me where I had been a bit confused.
Lessons Learned
This lab taught me a lot about using Git for parallel development. Even though I was nervous about merging for the first time, I now see the value of creating separate branches for each feature, since it lets me experiment without affecting the main branch. I ran into some issues with my branches, but that was mostly because it was my first time and I wasn’t fully confident in what I was doing. Looking back, I can see where I got confused about how branching and merging work, and this experience will help me handle parallel work more confidently in the future. I also learned to pay attention to commit messages like “Fixes #issue_number” so that merge commits automatically close the related issues.
Top comments (0)