Branching allows git to track multiple lines of development. This essentially allows you to have multiple versions of your project in development at the same time. For example, many projects will choose to have a stable master branch while new features or bug fixes are implemented in a development or testing branch. Once the project organizers are satisfied that the changes made in the development branch have reached the required level of maturity, they may choose to merge those changes into the master branch.
For many larger projects this cycle will often be repeated indefinitely. The benefit of implementing this strategy is that it helps to reduce the introduction of mistakes into the primary version of the codebase and therefore reduces the occurrence of bugs and other potential adverse behavior in the software. Simultaneously, it allows developers to test new ideas without restrictions. Therefore, they may continue to creatively contribute to the project in an efficient manner.
In this tutorial you will learn:
- What is branching
- How to create branches
- How to switch between branches
- How to delete branches
- How to merge branches
- How to manage tags
- How to use tags to keep track of versioning
- How to work with branches and tags on remote repositories
Software Requirements and Conventions Used
| Category | Requirements, Conventions or Software Version Used |
|---|---|
| System | Any GNU/Linux Operating System |
| Software | Git |
| Other | Privileged access to your Linux system as root or via the sudo command. |
| Conventions |
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command$ – requires given linux commands to be executed as a regular non-privileged user |
Creating Branches
Let’s examine a quick example of how to work with branches, continuing with the initial git project we created in the previous Git tutorial for beginners. First, make projectname your current working directory. Now let’s create a branch specifically to work on the documentation for out project. Issue the following command to make this new branch.
$ git branch docs
Now, lets take a look at all of our branches.
$ git branch
Simply issuing the git branch command as above displays a list of all the branches in our git repo. You will notice that the first branch is called master by default. In our case, we see the master branch and our newly created docs branch. Note that the current branch we are working in is marked by * and it is still the master branch. To begin working in the docs branch we need to checkout the branch.
Switching Between Branches
$ git checkout docs
Now that we have checked out the docs branch, any changes we make will affect that branch alone and the master branch will remain untouched and in the exact state that it was in prior to checking out the docs branch.
Lets create a readme.txt file for our project.
$ echo "This is a simple Hello World program that was created during a git tutorial." > readme.txt
Now that we have a descriptive readme file for documentation, let’s stage it and commit it just like we learned how to do in the previous Git tutorial for beginners article.
$ git add readme.txt $ git commit -m "added readme to docs branch"
Now that we have committed the change in our docs branch, we can switch back to the master branch by checking it out.
$ git checkout master
Go ahead and list the directory contents.
$ ls
You will notice that the master branch does not have the readme.txt file because at the moment it only exists in the docs branch. This demonstrates how the two branches represent two distinct states of development.
Merging Branches
Now, what if we feel like our documentation is complete and ready to be merged into the master branch? This is where the git merge command comes in handy. Enter the following command to merge the docs branch into the master branch.
$ git merge docs
List the directory contents and observe that the master branch now contains the readme.txt file.
$ ls
If we issue
$ git log
then we see that the log history of the two branches has been merged together as well.
Deleting Branches
Now that we have completed our documentation and merged the docs branch with the master branch we can safely delete the docs branch if we want. To do so simply add the -d flag to the git branch command.
$ git branch -d docs
Now we only have one branch in our project again and it reflects all of the changes that we have made throughout it; including the addition of a readme file.
Tagging
We might want to be able to easily see and refer to a specific commit without having to use its commit id. To accomplish this we can use the git tag command to give a commit a memorable name. In our case, let’s name our fist commit init, our second commit source and our last commit readme so that if we ever need to in the future we can easily refer to the commits where we initialized the project, added source code, and added a readme file respectively.
$ git tag init abbda7da6f6257effc7da16766ffc464c4098a8e $ git tag source 41dccee5478129094c3cbbcd08a26076a9aa370b $ git tag readme
You may notice that for the last command we did not have to specify a commit id. This is because that commit is our current HEAD and the current HEAD is named by default if a commit id is not provided. We could have provided the commit id if we wanted, but it would have been unnecessary.
If we use the tag command without any arguments it will give us a list of all the tags we are using.
$ git tag
If we want to see all of the tags along with the other commit information we can issue the familiar log command:
$ git log
From now on when we want to reference these commits we can use their tags in place of their commit ids. Just like we can checkout a branch, we can also checkout a specific commit. If we decided we wanted to checkout our first commit, we could now check it out using its tag.
$ git checkout init
From this point if we decided that we want to create a new branch that went in a completely different direction than our original project we could do that by making some changes here and issuing the switch command with the -c flag followed by the new branch name. Similar to the checkout command, switch changes branches, but with the -c flag it is also able to simultaneously create a new branch.
$ git switch -c new-branch-name
You can also create a new branch and switch to it with the checkout command as follows.
$ git checkout -b new-branch-name
Use whichever you prefer, but it is important to note that according to git’s man pages the switch command is experimental and its functionality may change in the future.
Other Considerations
We are using a very simple example in order to focus on git itself rather than the code we are managing. As a result, the tags we used reflect a simple naming scheme based on the introduction of features. However, larger projects will typically use tags as a means to keep track of versioning by tagging commits that correspond with specific release point numbers.
For example, version1.0,
version2.0 etc. It is also important to note that when you are pushing your changes to a remote server, new branches and tags are not pushed by default and must be specifically pushed using the following commands.
$ git push origin new_branch_name $ git push origin tag_name $ git push origin --tags
The first command will push the specified branch to the remote server, the second will push the specified tag to the server and the third will push all tags to the server.
Another important thing to note regarding remote servers is that if you have cloned a remote repo then the master branch has cloned to your local machine, but not the other branches.
To see all other branches on the remote repo issue the following command using the -a flag which shows all local and remote branches.
$ git branch -a
Once you checkout a remote branch it will be downloaded to your local repo and you can continue to work on it locally until you want to push the changes you made to the branch back to the server.
Conclusion
After working through the above examples I encourage you to continue playing around with branches and tags until working with them begins to feel intuitive to you. If you don’t have access to a remote repository where you can practice things like pushing branches, pushing tags and checking out remote branches then I encourage you to create a free GitHub account and select the option to create a private repo there.
In fact, I would recommend doing so even if you do have access to other remote repos. If you make a mistake on your own private GitHub account while you are learning then there is no major harm done. I would recommend that you start to use git collaboratively once you start feeling super comfortable with it.
After following this article and the Git tutorial for beginners guide you should now feel comfortable installing git, configuring git, working with branches, the concept of versioning, tagging and using git to work with both local and remote repositories. You now have the working knowledge to take the power and efficiency of git further as a distributed revision control system. Whatever you may be working on, I hope that this information changes the way that you think about your workflow for the better.
