Basic Git Branching

DZone 's Guide to

Basic Git Branching

In this article, we walk through the basics of branching with Git to get you started with better managing your versioning during projects.

· DevOps Zone ·
Free Resource

Dr. Banner (Hulk) talking with the Ancient One about alternate timelines in regard to the Infinity Stone in "Avengers: End Game" is a perfect example of branching in Git. But, instead of source code, they were talking about time travel and alternate realities. Branching is a very useful topic in software version control, and I believe most people are aware of this idea even if they are not from a software development background.

Branching in Git is very powerful but can be overwhelming at the same time. Git branching covers a lot of workflows and scenarios. In this post, I will try to introduce you to a very basic setup that will help you can use to get started with branching and much later down the line as well.

Git branches are effectively a pointer to a snapshot of your changes.

You may also like: Top 20 Git Commands With Examples.

Local vs Remote Branch

In this post, I will focus on local branches (the branches that live on your development machine), but the concepts are the same for remote branches. Normally, when you start developing a task, a bug fix or a new feature, you can create a new branch for that activity, do all your work in that branch, commit changes to that branch, and once done, merge those changes back to the master branch. So, let's see how we can start with this basic branching setup.

Step 1: Create a New Local Branch

The command, git branch -v, is one way to list all the branches for your repository. In our case, we only have one master branch. Let's say we want to start working on a new feature in software, which we'll call “feature1”. We can create a new branch for this feature as shown below:



git checkout -b feature1

This command creates a new branch, named "feature1", and makes that branch our active branch.

Step 2: Code Changes, Commits, etc.

Now, we develop our feature, make code changes, do commits, etc., and all that happens in this feature branch. I am simulating this work by adding a text file called "feature1", but that could be a whole heap of files (HTML, CSS, JavaScript, etc).

Step 3: Back to Master Branch

Once you are done with your changes for "feature1", you can switch back to master branch with the following command:



git checkout master

Optionally, it is also good if we execute git pull origin master to get any changes from the remote repository.

Step 4: Merge the Feature Branch to Master

Now, our changes are on "feature1", and we have switched to master. We can use git merge feature1, and that will merge changes from "feature1" branch to master.

Step 5: Delete the Feature Branch

Once we have successfully merged changes to master, we can delete our local branch, and that's it. The whole purpose of this branch was to make code changes in isolation. Once those changes have been amde, we can delete with the branch with the following command: git branch -d feature1.

Step 6: Push Changes to Master (Remote)

This step is also optional. If we like, at this point we can push changes to master (remote) so other colleagues could pull these changes as well.


  • git checkout -b feature1 (create a new branch, called "feature1").
  • git checkout master (switch back to master branch).
  • git pull origin master (pull changes from master, optional).
  • git merge feature1 (merged "feature1" branch back to master branch).
  • git branch -d feature1 (delete the local branch after merge, optional).
  • git push origin master (push changes to remote master, optional).

The above-mentioned steps are all you need to start with Git branching. I will suggest that you adapt to this strategy for every code change, bug fix, or new feature. Create a separate branch for that locally. It will simplify things for you a lot. 

Once you are comfortable, you can explore other advanced topics related to Git branching. There is a nice article by Vincent Driessen, which allows you more control and cover some advance use cases, I will suggest that approach if you are dealing with complex workflows. You can access the article on https://nvie.com/posts/a-successful-git-branching-model/.

If you need more information or if something is not clear, feel free to ask, and I will try to answer. Til next time, happy coding!


Further Reading

devops ,git ,git branches ,tutorial ,version control

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}