Git - Working with Branches

In the last article, we looked at working with a remote server, for which we used GitHub. We saw that it takes two stages—commits on the local version, and then a push of all the commits to the remote server. But the real power of Git is found in the branch management abilities, local and remote, so that’s what we’ll learn today.

Branches are used for various versions or additions to our software. For instance, if I have a repo with a WordPress add-on, and a customer is interested in a functioning add-on, I’ll split the first branch of the software (normally called the master) to a branch that deals with a feature. Then I’ll run a local commit, and then push the branch to the remote server. There, the automated QA can work on it. If everything is OK, then the branch will be merged back to the main branch (I’ll refer to as the master from now on).

We can even go a little wilder—say we have a product with several branches, the first of which is the master which is the main stable branch. At the beginning of the development process, we split the master branch and make the development branch. From there we split off more and more branches with each one dedicated to a different feature. Once the developer finishes working on the feature, he pushes the branch to the Git server. There the QA checks together with the automation. If everything is OK, it will be merged with the development branch. The rest of the developers, who are working on their own branches, can get updated at any time from the development branch.

At the end of the process, the development branch will be merged with the master. If this sounds confusing, don’t worry—it’ll all be clear in a moment.

So let’s talk about the branches. To create a local branch called develop all we need to do is type:

git checkout -b develop

The -b is critical here because it creates the branch. We’ll immediately get a message saying:

Switched to a new branch 'develop'

If we run git status we’ll see:

$ git status
On branch develop
nothing to commit, working directory clean

Any change we make now, including commits, will be in the develop branch. In order to push our branch to the remote server, all we need to do is use the command git push, to which we’ll add two arguments. The first is origin, which is the name of the remote server that we defined (remember? If not just go back two articles) and the second is the name of the branch the we want to push to the remote server.  git push origin develop

$ git push origin develop
Username for 'https://github.com': XXXX@XXXX.com
Password for 'https://XXXX@XXXX.com@github.com': 
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 319 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/sometestuser2/temp.git
* [new branch]      develop -> develop

So what did we do here? We made a new branch. The new branch was made from the branch we were already in (in this case master). Now, anyone with the right permission (and if I use GitHub, that’s everyone in the world) can make a clone of the repo and pull the branch. How? Just use clone which we covered in the last article—just take the URL of the remote server and do something like this:

git clone https://github.com/sometestuser2/temp.git

Now it needs to request from git to bring all the remote branches that exist:

$ git fetch --all

And then go to the branch:

git checkout develop

Notice that there’s no -b here—we’re not making a new branch but, rather pulling the remote branch to us.

If someone updates the remote branch on the server, I can pull it to myself with ease using:

git pull origin develop

Similar to push, here I’m also passing two arguments. The first is the name of the remote server that we defined as origin (remember?) and the second is the name of the branch.

And wherever we have several developers working on the same file, obviously conflicts may arise. Despite the fact that Git does merging really well, it still is going to happen. One way to deal with conflicts is very similar to SVN and I covered it already in the article on SVN and conflicts. Also, GUIs for dealing with conflicts in Git is similar to SVN which we also covered before. If you have experience with SVN or with other version control systems, then you know enough to deal with conflicts. If not, have a look at our guides for SVN.

Next up, we’ll look at merging and splitting different branches.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.