In a deep ocean of version control systems, the most trendy now is Git. One of the basic advantages of Git is that it is a distributed version control system, not centralized, unlike SVN and CVS. That makes it more feature-rich and efficient system. Assuming that you agree with that station and going to integrate Git into your everyday workflow.
After you installed Git and figured out the basics of using it. Then let’s talk about it feature that makes development process much easier – Branching. In this tutorial, I’m going to show you what is Git branches, when you may need them and how to use them effectively.
Also, we’ll talk how to create them, make changes, how to select a branch and of course how to put a forked history back together by merging.
When actually a need to use branching arises? Well, imagine the Situation.
You are working on a project and already have several commits. Out of sudden, there is an urgent need to work on some Issue on the one hand, and your teammate has to work on some Feature at the same project on another. And at the same time, main code base shouldn’t be messed by unstable code.
In such a common daily situation you just need an independent line of development which a Git Branching is.
Talking about the Basics
The main essence of a branch is a separate line of development with its own project history that allows to make all necessary changes and clean up properly before merging it into the main code. It possible to make several branches and to work on them in parallel.
Git branch integrated with commands that allow to create, rename or delete branches. Also, there is no way to switch between branches but instead, there is a Git checkout command.
To start working with Branches you have to run a console and connect through ssh to your server or just work locally through a console. Then open your repository directory.
To see all branches you have, even those you do not have in your local workspace, type:
git branch -a
To list all of the branches in your repository, type without -a
In output, you’ll see smth like this
Where asterisk * indicates on which branch you currently are. And according to the example above, you are on the master branch now. Next line just shows that on your remote, named origin, there is a single branch, also called master.
The first and main branch usually called “master”.
Now when we indicated where we are and what branches we have, let’s create a new branch.
Assuming you want to work on multiple features in a single repository.
Main branch set by default as <master> and a new single branch named <some-feature>.
Create a new branch
To create a new branch, named <some-feature>, type the following:
git checkout -b
Here the -b function runs at once also and git branch <some-feature> before running git checkout <some-feature> branch.
Or in other words, it’s a shortcut for:
In case you actually already have a branch called <some-feature> you’ll see
fatal: A branch named already exists.
But if you don’t have it yet, Git will tell you that it
Switched to a new branch
By the way, if you need to rename your current branch you may use command
git branch -m
Navigate between the branches
To switch between your branches use git checkout command
Switched to branch
It makes <some-feature> the current branch, and updates the working directory to match.
In case you try to switch to non-existing branch, like
error: pathspec did not match any file(s) known to git.
Create and commit new file
After switching to <some-feature> branch you need to create a <new file>.
But at first, tell Git that we want to track it.
Now, to create a blank file, named <new file>, and add it to Git run
Then to commit new snapshots run
git commit -m
And with all that, all the snapshots remain in the <some-feature> branch that is absolutely detached from the main <master> branch. So, you can feel free to make as many commits as you need and don’t concern about affecting other branches.
When you ready to merge your <some-feature> branch with other code, the first thing you need to do is to check out the <master> branch.
git checkout master
Now when you on the <master> branch all you need to do is to run the merge command.
One of the possible options of merging is running a command “–no-off” that says to keep all of the commit messages before the merge. It helps if you want to chronicle all merges in a repository and it will be easier to track changes.
Following will merge <some-feature> branch into the current branch which is <master>.
git merge --no-ff
In the output you’ll see smth like this:
Merge made by the 'recursive' strategy.
0 files changed
create mode 100644 develop
Now when you merged all your code from <some-feature> branch to the <master> and you don’t actually need it anymore. You may delete it. There are two options for deleting.
A “safe” one. It is preferable to use because it protects you from losing unmerged commits.
git branch -d
But if you haven’t merged that branch following error message will be shown:
error: The branch is not fully merged.
Force delete. In case you are definitely sure you need to delete it, run
git branch -D
Use it only when you are sure you want to delete branch permanently because it will erase all of the commits associated with this part of development.
Push all changes
In the end use Git push command to send all changes to your remote server.
The example above demonstrates the basic Git branching process. Hope it was helpful and clears some points about parallel branch workflow. If you have any questions or have smth to add please share your thoughts in comments.
More about merging cases and possible conflicts read in the next post.