Theory Behind Branch and Merges
Whenever someone talks about branches in Git, the basic understanding is that it is a way to support parallel working amongst multiple developers,
But, this post will now provide information about how branches work inside Git.
At their core, branches in Git are movable pointers to specific commits. When you create a branch, you're essentially giving a name to a particular commit's SHA in the Git log. As you make new commits on that branch, the pointer automatically moves to the latest commit.
Commit SHA and corresponding Branch
Feature Addition To My Project
This week I had to go through the process of working with multiple branches and also resolving multiple conflicts due to the addition of two new features in my project, DialectMorph
First Feature
I observed in my codebase that most of the functions related to the Singleton class for Groq Client lacked try and catch error blocks and they lacked the correct error message for the same Also, the CLI function, had inconsistent error codes while exiting the program, so I added an issue to my GitHub repo to resolve this issue,
I made a branch and named it after the issue that was opened on GitHub, in this case, it was issue-22.
Second Feature
The CLI tool only supported Groq API to transpile the files, I wanted to support the addition of another API to provide a diverse range of LLM models that the user can choose from to generate the transpiled files, so I decided to include Gemini API as well. I added a description of what features were to be included in the Gemini API feature on the new issue that I had opened on GitHub, I started working on branch issue-23 which was the number assigned to the issue on GitHub.
Fast Forward Merge
After I had finished working on issue-22, I decided to merge the changes on the local main branch, this meant that I had to perform the following command
git checkout main
git merge issue-22
now since I had not made any commits on my main branch, the merge that would perform here would 'fast-forward' my main branch to the latest commit on the issue-22 branch, to better illustrate this I have a graph that would demonstrate how this would work
Fast-forward merge of issue-22 into main branch
as can be seen from the diagram, after the merge is finished the main branch is moved to the new commit with merged/updated changes,
A full descriptive version of my merge commit can be found here
Three-Way Merge and Conflicts
After I had finished working on issue-23, which was adding the support for Gemini Client in my codebase, I again wanted to merge the changes in my local main branch, but this time around since my main branch had new commits due to an earlier merge from issue-22 branch, the merge would be a Three-Way Merge and that's not all, I even had a couple of merge conflicts this time around.
To get started on what a Three-Way Merge is I would have to demonstrate a simple example with the help of a graph
I have three branches: main, issue-22, and issue-23. I created both issue-22 and issue-23 from the same commit (or snapshot) on the main branch. After that, I started working on issue-22, made changes, and performed a fast-forward merge back into the main branch.
While working on issue-22, I was also making progress on issue-23, and now I’ve completed the feature on the issue-23 branch. However, there’s an issue when I try to merge issue-23 into main—the main branch already has commits from the issue-22 merge, which means a fast-forward merge is no longer possible.
This time, I’ll need to use what’s called a Three-Way Merge. In this process, Git identifies the common ancestor between the main branch and the issue-23 branch. This common ancestor, referred to as the "base" commit or snapshot, is used to merge the changes from both branches and resolve any merge conflicts between the two—in this case, between main and issue-23.
A full descriptive view of this can be found here
Conclusion
I believe the best part about being a Software Engineer/Developer is knowing what you're doing but at the same point having no idea how you will be able to do it, this week proved this for me, I knew from the start how I will be able to merge my changes but I never knew I had to go through the intricacies of different merge types and conflicts. But to be brutally honest, I am enjoying delving into features I knew existed in Git but had never tried them earlier.
Top comments (0)