Practical Git: Branching

There are many resources outlining the deep level of management that Git offers for version control of a repository, though to effectively manage our day to day development, we only need to understand a handful of core commands.

Below, I’ll walk through the most practical commands I’ve found important for a beginner to get moving on a project using Git. I’ll only be focusing on the Git command-line interface. Though there are tools such as the Git GUI that provide helpful abstractions of the Git workflow, I find it important for new Git users to utilize the CLI to understand and have greater control over the actions they perform. The exception to this is VSCode’s excellent Git source control explorer. When used in conjunction with the Git CLI and integrated terminal, the two provide the best pairing of visual model vs. control.

The workflow below assumes an understanding of Git basics such as adding, staging, committing, as well as pushing and pulling from a remote repository. If these are unfamiliar, Jeff Jensen has supplied an excellent primer on these concepts Introduction to Git Concepts – Software Consulting – Intertech

Branching Workflow

By branching, we can create an organized repository which allows great control over code quality, integration, and delivery. Branching is an essential Git mechanism and hugely beneficial for small teams as well as individuals.

While commits represent a revision or snapshot of our development, branches can be thought of as a history or series of commits moving forward in time away from their starting point – “main”, “master”, or another branch. They are often visualized as a train that forks away from its main track to eventually merge back in with the main line.

Creating Branches

The goal of creating a new branch is to isolate working changes which will deviate from the main branch, traditionally called “master” or “main” (referred to below as “main”).

To create a new branch, first understand what branch you have currently checked out.

To see a list of all local branches, run:

git branch 
The current checked out branch will appear highlighted and starred.

Next, understand that when you branch away from your current branch, you carry that history as a starting point for the new branch. This includes recent changes or state that have been committed by you, merged in, or pulled from a remote branch.

To create your branch and check it out at the same time, run:

git checkout -b <branch name>
A branch is usually named to represent a division of work, a story, issue, or hotfix. Many teams will have a naming convention to adhere to.

Navigating Branches

You may need to navigate away from a branch to complete other work. It’s crucial that your current branch is in a clean working state before you checkout other branches. If not, existing modifications you’ve made will carry over to the branch you are checking out, effectively removing them from the current branch.

To achieve a clean working state, you can stage and commit your changes on the current branch or stash changes temporarily (outlined below).

Once your working state is clean, run:

git checkout <branch name>

Using Git Stash to Save Work

A common way of saving temporary changes is to add them to the Git stash. The stash is a local, first in – first out, stack-like data structure.

Note: if there’s a new, untracked file or changes present, they’ll need to be added to the index using “git add” before they can be stashed
Add your changes to the stash by running:

Once your working state is clean, run:

git stash
(I’ve also run “git status” here to show existing changes)
Verify your changes have been stashed in the list and continue on to checkout other work.

Stash items can be viewed with:

git stash list
In the command output, changes are marked as “WIP” (work in progress) on , followed by the most recent commit id and message.

Retrieving Work From the Stash

Once you’ve returned to or checked out the branch where you’d like changes to be applied, they can be restored by running:

git stash pop
This will pop the most recently added item from the stash and return it to modified state on the current branch.

(Restored changes are shown below as “Dropped refs/stash@{index number}” )

Note: Stashed changes can be applied to any branch.

Though “pop” is a quick way of restoring the most recently stashed changes, you can also “apply” a copy of a specific stash entry. Unlike “pop”, using “apply” keeps the stash entry in memory for later.

To apply a specific stash entry, find the index number of your changes by running:

git list 

To apply changes run:

git stash apply stash@{<index number>}

Fetching and Working With Remote Branches

Two common reasons for fetching remote branches are retrieving work done by another developer or work pushed as backup from another machine.

To retrieve the listing of branches in the remote repository as well as their most recent state, run:

git fetch 

To check out a remote branch in this context, we should use:

git switch -c <branch name>

(I’ve run “git branch” to show our current branch)

We could have used “git checkout” as usual, but there are circumstances where this will leave us in a ‘detached HEAD’ state. One such case is when checking out a remote branch or commit which is not ours. The message is jarring, but there’s no need for concern. In a detached HEAD state, we are on a commit and a new history that does not correspond to any of our existing branches. Essentially, we are a commit floating on a new timeline. There are contexts where entering a detached HEAD state is helpful, though it’s outside the scope of this post.

We also need to be careful if the branch name exists in two remote repos. In this case, “switch” will use the branch from the default remote repo. To explicitly tell git which remote repo the branch should be created and tracked from, we should run:

git checkout -b <new local branch name> <remote repo name>/<original remote branch name>

Merging Branches and Combining Work

state of the main branch or you may need to add another developer’s implementation which your feature development is dependent on. In this case you’ll need to merge branches.

If merging a branch from the remote repo with your local branch, first perform a “git fetch” so the corresponding remote branch listing is up to date.

Ensure that your current working branch is checked out, and merge the other into it by running:

git merge <other branch>

Below is a shortcut which will simultaneously pull and merge the intended branch from the remote repo:

git pull <other branch>

In Conclusion

This workflow is a starting point which only scratches the surface of what can be done using git. In the end, each team and organization must decide on the best practices to manage their own repositories.

For an in-depth look at Git see the official documentation at

About Intertech

Founded in 1991, Intertech delivers software development consulting to Fortune 500, Government, and Leading Technology institutions, along with real-world based corporate education services. Whether you are a company looking to partner with a team of technology leaders who provide solutions, mentor staff and add true business value, or a developer interested in working for a company that invests in its employees, we’d like to meet you. Learn more about us.