How difficult is Git branching?

Well, in short – it isn’t! But, when it comes to branching, it comes to “merging problem”. I say problem although it isn’t, and if you’re interested, I’ll show you why.

Basics About Git Branching

Well, I’ve noticed that some Git users that have just switched from SVN didn’t know that every single one of Git repositories contain at least one branch called “master”. And all commits to Git repository, if you don’t work with branches are pushed to it, by default. I say this because if you’ve used SVN, branches are considered as high-end knowledge, and in Git – it’s considered almost as the basic knowledge (it comes just after you learn how to use commit -> push -> pull loop).

So, to conclude this introduction – since everything you do with Git is on some branch, you should learn how tho use them in your advantage.

The Creation

Fist of all, go to console, navigate to your repository, and type this:

git branch -a

You should see something like this:

* master

Make sure you have at least one file inside your repository (project) directory and make sure it’s added to repository. If it isn’t, create sample file “test.txt” and do the following:

git add test.txt
git commit -m "Added test.txt to repo"

And now, let’s create our first branch manually:

git branch mybranch
git checkout mybranch

With first command git branch mybranch we’ve created a new branch called mybranch, and at this point you’ve created your first “tree” of branches. At that point, you’ve copied “local repository state” to new branch. And with second one, you’ve switched to work on your new branch.

And with this, I’ll conclude “The Creation” part of this article. Moving on to the fun part:

The Work

Let’s say we created our local branch for testing. When we’re done, we’ll merge it back to master branch, if we’re satisfied with our work, and if not, we’ll simply delete it.
So, just to be sure, after you type in:

git branch -a

You should see this:

master
* mybranch

This means there are currently two branches “master” and “mybranch”, and we’re currently working on latter.
Now, let’s edit our test.txt file. Just add a line of text that’s saying “mybranch – first line” with your favorite text editor.
Back on to the “Git stuff” again. We’ll commit our changes to our current branch (mybranch):

git commit -a -m "mybranch - first commit"

Note: “-a” i our last commit just commits files that have been edited, in our case, test.txt.

To get a clearer picture, just write this to console:

git log -1

After it executes, you should see last commit’s author, date and message. It should be yours with message “mybranch – first commit”.
Moving on:

git checkout master
git log -1

We’ve just switched back to master branch and looked at last commit’s info. Message should go like this “Added test.txt to repo” – from our initial commit when we added the test.txt file at the beginning of this article.

Now, let’s say we’re satisfied with our work on test branch we called “mybranch”, and we want to merge it back to master, and move on with development. Since we just switched to master branch, just do the following:

git merge mybranch

Note: with this command, we’re merging branch called “mybranch” into branch we’re currently in (“master” branch)

If you followed everything to the letter, you should see a success message in your console. If not, you’ve already reached next part of this article:

The Problem

Well what if we edited same file on both branches and tried to merge them? We’d ge a merge conflict. Git will tell us there’s a problem, and we need to look into the file while it’s in the MERGING phase, resolve the conflict, re-add the file and commit merge. After that, it’s resolved.

I know this sounds complicated, but let’s move on with our example. While we’re in “master” branch, edit out test.txt file, and add new line of text – “line two”, and save it. Just after that execute the following:

git commit -a -m "Edited file on master"
git checkout mybranch

First line committed current state of files (our line we added) to “master” branch, and second line just got us back to “mybranch” branch. Open our sample file again, and you shouldn’t see our second line. Add a new line here as well – “line three”. Commit the change with following command:

git commit -a -m "Edited file on mybranch"

Switch back to master, and try to repeat the merge:

git checkout master
git merge mybranch

You should get the “Automatic merge failed” message, in file called “test.txt”. If so, you’ve done everything right. Then, in console, you can notice that you’re on “master|MERGING” branch. This is state in repository where you need to resolve the conflicts, re-add the files, and commit the merge to finish. So open the file, keep what you need after the merge, save it and execute the following:

git add test.txt
git commit -m "First conflict resolved"

You might notice you’re back on “master” branch (not “master|MERGING”). This means you’ve done it. You managed to do the following:

• create a branch
• edit files on both branches
• cause the conflict
• resolve the conflict

And now on to the last part:

The conclusion

Although all of this might seem like an overkill for something simple, it really isn’t. Even if you use console instead of some GUI tool, all of this is done under 1 minute, when you get used to it. And in return, you can isolate your work from your colleagues to work without messing into each other’s code.

I hope I was clear, and that this article will be of some help for beginners.

Feel free to comment.