Developing Two Features at Once with Git Branches. (merge)

Today, I want to talk about my experience with Git branch merge system. Git's branching feature allow users to develop two different features simultaneously and independently in a single project. I was able to browse through with hands-in experience through OSD600 Lab3.

I've added two more features to my Repo-Code-Packager:

1. --line-numbers: A flag to display line numbers in the file content
2. --dirs-only: A flag to show only the directory structure without file content.

Feature 1: Adding Line Numbers(--line-numbers)
First task was to add --line-numbers feature. This one is pretty straightforward. When user add -l or --line-numbers flag, it adds a line number on the left side of file content. These are the steps I went through to complete the task.

• Create a Github issue(issue-7): it is always a good practice to open the github issue to efficiently track the task that must be completed.
• Create a Dedicated Branch: I created new branch from main called issue-7 and added code there. Creating separate branch allowed me to modify and test the new feature without ruining main branch.
• Code Implementation: I added the -l flag using argparse and then modified the format_file_contents function to split the file content by line and add number to each one.

Overall, it was quite straight forward process.

Feature 2: Directory Only File structure(--dirs-only)
Next task was to add --dirs-only feature. This task adds -d flag that strips out all the code content, showing only the ## Structure section. It would be useful to quickly scan the overall project structure if there are multiple numbers of directories.
These are the steps I went through to complete the task.

• Create a Github Issue(issue-8): Similar to issue-7, I created separate issue for issue-8.
• Create a New Branch: I've created separate issue-8 branch to work and test this feature. I had to change the logic of main function which requires precise testing so having separate branch from main provided me comfort and freedom to enhance the code.
• Code Implementation: The main update of this feature is the output. It now gathers all the pieces(Header, Git info..etc.) and put them into a list called output_parts. The reason why I chose to make this change is that it may cause a repetitive code block if I gather the result in a one big string. -d requires a if statement check if -d tag is added by user. This means that the "one big String" output code may be redundant. By creating a dynamic list and change what output to append depend on user request is much more efficient method.

Wait, Why Does All the Code Look the Same?
Honestly, I was so confused when I created a new branch and used git checkout to switch between my branches. One of the main confusion was the main.py file was not changing at all. In fact, whether I was in main, issue-7 or issue-8 branch, all the code looked identical. Panic button was slowly raising up in my brain.
What I Learned from that?

• The core lesson was "The working Directory is Singular". My project folder can only show the content of one branch at a time. The git checkout command is like a magic trick. It instantly swaps code based on the branch that you swap to.
• Another useful lesson here was git log. It showed me a map of the entire repository and revealed that I hadn't actually committed any changes correctly, so all my branches were just point to the same location. I ended up cleaning all of my branches and applied changes again but it was a valuable lesson.

Merge!
Now that I have two branches with two different features in parallel universe, I've used git merge [branch-name] to merge the two branches to main. I had to go through "Conflict-merge" even for the first issue-7 branch because stupidly, I've made changes on main after making `issue-7 branch. However, it was not difficult problem to rearrange the conflict codes.
issue-7 merge
issue-8 merge

Lots of new materials every week and this is actually getting very interesting.

Project Repo: Repo-Code-Packager