Ready, Set, GIT!
Part V — Going our Separate Ways
This article covers the concept of branching within a Git repository. I will present how we create branches in a repository so that we can explore new code, test out different scenarios, and yet be able to fall back to our current production code status.
Branching with Git is an important, no make that required, feature of any source control management system. It enables us to explore and expand our original creation to a newer improved version. Plus, it ensures that we can always go back to our current production view if fixes or modifications turn out to be incorrect or if revisions are required before we are ready to incorporate our latest enhancements.
In this final article on Git, I will cover the basics of creating, reverting, and merging branches of code.
The analogy of a tree is effective in describing the way branching works up to the point when we need to discuss merging branches. But more on that later.
Let us begin with the main branch or trunk or the root of the tree repository. In fact, in Git, the newer convention is to refer the primary branch as “main”. Main is the original branch when you create a new repository. As you add, modify, or delete elements (files of code, images, and other assets) during your ongoing commits and pushes, you continue to only work with the main branch.
At some point when you decide you are ready to create a release of your current codebase (generate your first production release of your application), you will want to mark that current version of “main” as the current production state. This will establish the application’s baseline going forward.
Now it is time to create a new branch for ongoing development knowing our current “main” branch is as stable as we can make it. I suggest creating the first branch off of “main” to be “dev” as this is the place where we can begin enhancing our app without affecting the “main” production version. The following git code illustrates how we would go about doing that.
Notice how Git informs us that the “dev” branch already exists when I tried to execute the command to create a new branch; “git branch dev”. It will not create a new duplicate branch with the same name.
The next command you see in the code is “git checkout dev”. This command changes our reference over to the “dev” branch it told us already existed and it shows us the modified files in that branch.
So, now we want to switch back to the “main” branch by using the command “git checkout main” so that we can create a new branch that we will call “hotfix”.
This time, you see that the command “git branch hotfix” ran without error and we were able to change to the new “hotfix” branch using the “git checkout hotfix” command.
At this point, I went into UnityHub and created a new script file that will “fix” the current production release called “HotFixScript.cs”. After testing out my new code, I am ready to add it into my codebase by commiting the change.
So, I issue the “git add .” command which adds any uncommitted code add/changes to the current branch.
Then I create a commit to the “hotfix” branch using the “git commit -m ‘Added HotFixScript.cs to fix a production issue’” command.
At this point in time, I have the following branches in their various states:
The “hotfix” branch contains all of the “main” branch plus the new file, the “dev” branch currently looks exactly like the “main” branch. The “main” branch has remained the same since we started.
So, now let’s merge our “hotfix” back into the “main” production branch. We do this in the following manner.
First, we have to switch back to the “main” branch since it will be the target of the merge process. Then, we simply issue the “git merge hotfix” command to take our “fixes” and merge them back into our current production version.
So, what about the status of all of our branches?
As you can see, the “main” branch is clean, the “hotfix” branch is clean, and the “dev” branch still is not “aware” of the hotfix that was required to fix the production version of the application.
At this point, we can continue down our “dev” branch making ongoing changes as necessary and working on our development project, or we could perform a similar merge from the “hotfix” branch to get our “dev” branch back in sync with the production version.
Depending on how critical the hotfix was will determine which route we take; integrate or wait. The beauty is that Git enables us to make that determination as needed.
I hope you have enjoyed or at least gained a new appreciation for Git as a repository resource as you progress in your coding journey.
