Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / Git

Git Branching Essentials

3.88/5 (4 votes)
17 Feb 2015CPOL4 min read 13.9K  
Git Branching Essentials

I’ve been using Git for well over a year to manage my software projects. I was blown away by its fantastic branching capabilities, which helped me try new ideas and prototype stuff at breakneck speed.

So I thought I’d share my experiences with it. This is the first article in a series about development with Git.

Git is a Distributed Version Control System, and each computer has the full repository and commit history, not just a snapshot. This means you have access to your repo anywhere you go.

In contrast to Centralized Version Control Systems like Subversion or Perforce, where working with a branch involves a checkout into a new folder, and then tediously juggling multiple source code trees, Git makes it really easy to seamlessly integrate branches into your thought process.

I find it helps me be creative and productive without losing anything I create, in an unobstructive, intuitive manner.

I’ve drawn up an example workflow below to show you how a development process with Git would look like.

To get you started, I’ve created a Visual Studio project, with a single Awesome class that sorts anything you tell it. You can clone this project from my GitHUb repo:

git clone <a href="https://github.com/nikonian/Blog.git" rel="nofollow">https://github.com/nikonian/Blog.git</a>

If you’re interested, the bit that does the work is in AwesomeClass.cpp. It reads words typed at the console into a vector, sorts them, and iterates over the vector to print it back out. This can be achieved with just three lines of cross platform C++ code. I’ve created a Visual Studio project for this example.

C++
copy(istream_iterator<string>(cin), istream_iterator<string>(), back_inserter(_vec));
sort(_vec.begin(), _vec.end());
for_each(_vec.begin(), _vec.end(), [](string& s){ cout << s << " "; });

After you clone the repo, check the status on the newly downloaded folder:

git status

git status

git status

By default, Git has started us off on the main Master branch.

Now let's try something that will make our class even more awesome.

Let's branch the repo and switch to the new branch using:

git branch <branch name>
git checkout <branch name>

git branch, git checkout

git branch, git checkout

You can also use a single command to create a branch & switch to it:

git checkout -b <branchname>

Let’s get a listing of the branches we have:

git branch -v

git branch -v

git branch -v

The * you see next to the branch name indicates the branch you’re currently working on.

And that’s it! Our working folder is now on our soawesome branch!

Let’s create our awesome new code that can change the world. After writing the code, let’s run a git status:

git status after making changes

git status after making changes

Git has detected our new files, and we can add them all into the staging area with:

git add .
git commit -m "Awesome new code"

Staging files on branch 'soawesome'

git add .
Staging files on branch ‘soawesome’

You can also combine the two into a single command:

git commit -am "Awesome new code"

Once we’re checked in, we can jump back to the Master branch with:

git checkout master

On the master branch

On the master branch

Then we switch to the experimental branch to complete work on the class.

git checkout soawesome

On branch soawesome

On branch soawesome

You can see how git completely replaces your working folder with the branch of your choice, and if the solution is open in your IDE, and if your IDE is worth its salt, it will detect the file system changes and prompt you to refresh the solution.

If you have modified a file, and switch branches, Git will not replace it and wipe out your work, it will mark those files as modified with an M symbol, and you can either check it in or discard the changes with git checkout -- <filename>

So, our awesome new changes are ready, and we can now pull them into the Master branch. We can ask Git to merge the two branches with:

git checkout master
git merge <branch name>

One way to visualize this workflow is to imagine yourself in a sushi restaurant, with Git as your waiter, the dinner table as your working folder, and the branches as different bowls of sushi. You ask Git for the sushi bowl you want and it will clear your table & place your desired sushi bowl before you, with a courteous bow.

You can sample as much sushi as you want by asking Git for a different bowl anytime (git checkout <sushi bowl>), add sushi from another sushi bowl into the one you’re using ( git merge <sushi bowl>), or ask it to get you a new sushi bowl (git branch <sushi bowl>).

I’ve used PowerShell in this article, but you can also use Git bash, that runs on MinGW on Windows, which has the added benefit of displaying the branch name right on the prompt.

Git bash

Git bash

Now go ahead and try out what you’ve just learned! I’ll cover more interesting productivity features of Git in the next part.

Arigato!

Image 9 Image 10

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)