Jump Start Git: Branching in Git

The following is a short extract from our book, Jump Start Git, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.

What Are Branches? Creating a new branch in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the master branch.

But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the master. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.

So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on CVS was a very tedious one. If you’ve had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)

In Git, you find yourself in the master branch by default. The name “master” doesn’t imply that it’s superior in any way. It’s just the convention to call it that.

Note: Branch Conventions Although you’re free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the master branch.

You might argue that, with the ability to go back to any commit, there’s no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the master branch or the main branch.

Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let’s say you submit feature 1 for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on feature 2. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.

Let’s now start working with branches in Git. To see the list of branches and the current branch you’re working on, run the following command:

git branch If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix -a to the command above:

git branch -a

As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the origin remote.

Create a Branch There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:

git branch test_branch Here, test_branch is the name of the created branch. However, on running git branch, it seems that the active branch is still the master branch. To change the active branch, we can run the checkout command (shown below):

git checkout test_branch

As shown above, branch_A initially is the active branch and HEAD points to commit C. Commit A is the base commit and doesn’t have any parent commit, so the commits in branch_A in reverse chronological order (which also forms the pathway I’ve talked about) are C → B → A. The commits in branch_B are E → D → B → A. The HEAD points to the latest commit of the active branch_A, which is commit C. When we add a commit, it’s added to the active branch. After the commit, branch_A points to F, and the branch follows F → C → B → A, whereas branch_B remains the same. HEAD now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.