Let's start using the git branch command alone. If you do this, you will get a list of the branches included in the current repository:

$ git branch

We will get the following response:

As expected, Git tells us that we have only the master branch. The branch is highlighted with a star and green font just because this is our actual branch, the branch in which we are located at the moment.

Now, let's start creating a new branch for a new activity.

Open the Bash shell in C:ReposMyFirstRepo and create a new branch from where you are using the git branch command, followed by the name of the branch we want to create. Let's assume that the name of the branch is NewWork:

$ git branch NewWork

Well, it seems nothing happened and we are still in the master branch as we can see in the following screenshot:

Git sometimes is a man of few words. Type the git branch command again to get a list of the actual branches:

Hey, there's a NewWork branch now!

The only thing we have to do now is to switch to the NewWork branch to begin working on this separate argument. To move around from one branch to another, we will use the git checkout command. Type this command followed by the branch name to switch to:

$ git checkout NewWork

This time, Git gave us a short message, informing us that we have switched to the NewWork branch. As you can see, NewWork is within brackets in place of master, indicating the actual branch to us:

Super easy, isn't it?

At this point, nothing special seems to have happened. However, you will soon change your mind. Just to give you a visual aid, consider this figure:

Assume that our last commit on the master branch was the C3 commit. At this point, we now have two other pointers: the master branch pointer and the NewWork branch pointer.

If you have used Subversion or a similar versioning system earlier, at this point, you would probably look for a NewWork folder in C:ReposMyFirstRepo. However, unfortunately, you will not find it. Git is different, and now, we will see why.

Now, to better understand what a branch is for, add NewWorkFile.txt, stage it, and commit the work, as shown here:

At this point, we have a new commit in the NewWork branch. This commit is not a part of the master branch, because it has been created in another branch. So, the NewWork branch is ahead of the master branch, as shown in the following figure:

Working with Git in this kind of a situation is ordinary administration, just like it is in the day-to-day life of a developer. Creating a new branch is cheap and blazing fast even in large repositories, because all the work is done locally. You can derive multiple branches from a unique point, branch from a branch that branched into another branch, and so on, creating all the ramifications you can manage without going crazy.

Moving from a branch to another is easy. So, let's turn back to the master branch and see what happens:

If you have used Subversion earlier, at this time, you are probably wondering at least two things: why is there no NewWork folder containing files from that branch and, most of all, what was the fate of the NewWorkFile.txt file.

In Apache Subversion (SVN), every branch (or tag) you checked out resides in a separate folder (bloating your repository, after some time). In Git, there is a huge difference. Every time you check out a branch, files and folders of the previous branch are replaced with those contained in the new branch. Files and folders only on the destination branch are restored, and those only on the previous branch are deleted. Your working directory is constantly a mirror of the actual branch. To have a look at another branch, you basically have to switch to it.

This aspect might look bad to you the first time, because seeing files and folders disappear is scary at first. Then, you can't differentiate the two branches as we probably did earlier by simply comparing the content of the two folders with your preferred tool. If I can give you a piece of advice, don't lose heart about this (as I did at the beginning): soon you will forget what you lost and you will fall in love with what you gained.

So, let's go back once again to the NewWork branch and have a look at the situation with the aid of a visual tool, Git GUI. Open the C:ReposMyFirstRepo folder and right-click inside it. Choose Git GUI from the contextual menu. A dialog box will pop up as shown in the following screenshot:

Git GUI is not my preferred GUI tool, but you have it for free when installing Git. So, let's use it for the moment.

Go to Repository | Visualize All Branch History. A new window will open, and you will see the status of our current branches, as shown in the following screenshot:

We do not have the time to go into all the details here. As you become more confident with Git fundamentals, you will learn little by little all the things you see in the preceding picture.

If you don't want to leave the console to take a look, you could get a pretty output log even on the console. Try this articulated git log command:

$git log --graph --decorate --pretty=oneline --abbrev-commit

This is a more compact view, but it is as clear as what we saw earlier.

Before continuing, just a little warning. The last command we used is not the easiest thing to remember. To get around this nuisance, Git offers the possibility of creating your own commands, aliasing some of the verbose sequences.

To create an alias, we will use the git config command. So, let's try to create a tree alias for this command:

$ git config --global alias.tree 'log --graph --decorate --pretty=oneline --abbrev-commit'

So, the syntax to create aliases is as follows:

git config <level> alias.<alias name> '<your sequence of git commands>'

Using the --global option, we told Git to insert this alias at the user level so that any other repository for my user account on this computer will have this command available. We have three levels where we can apply config personalization:

To create a repository user-specific config, we used the --global option. For the system level, we will use the --system option. If you don't specify any of these two options, the config will take effect only in the repository that you are in now.

This is a concept that sometimes raises some trouble. To avoid this, we will have a quick glimpse of it. You don't have to wait for the work to be done before merging another branch into your branch. Similarly, you don't have to think about merging as the last thing you will do before cutting off the other branch on which you worked.

On the contrary, it's better if you merge frequently from branches you depend on, because doing it after weeks or months can become a nightmare: too many changes in the same files, too many additions or deletions. Don't make a habit of this!

In this exercise we will learn how Git can handle automatically file modifications when they are not related to the same lines of text.

In this exercise we will learn how to resolve conflicts when Git cannot merge files automatically.

If you want to do it in a more Git-like way, you could use the git diff command. Let's give it a try by performing the following steps:

Now, try to have a look at the differences between the master and NewWork repositories. Finding out the difference between the two branches is easy with the git diff command:

$ git diff master..NewWork

The syntax is simple: git diff <source branch>..<target branch>. The result, instead, is not probably the clearest thing you have ever seen:

However, with a little imagination, you can understand that the differences are described from the point of view of the NewWork branch. Git is telling us that some things on master (NewFile.txt modifications and NewMasterFile.txt) are not present in the NewWork branch.

If we change the point of view, the messages change to those shown in the following screenshot:

Another way to check differences is to use git log:

$ git log NewWork..master

This command lets you see commits that differ from the NewWork branch to the master branch.

There is even a git shortlog command to give you a more compact view, as shown in the following screenshot:

All these commands are useful for short change history. However, if you have a more long change list to scroll, things would quickly become complicated.

Git lets you use an external diff tool of choice. On other platforms (for example, Linux or Mac), a diff tool is usually present and configured, while on the Windows platform, it is generally not present.

To check this, type this command:

$ git mergetool

If you see a message like this, you would probably have to set your preferred tool:

This is the most common kind of conflict: someone edited the same line in the same file on different branches, so Git can't auto merge them for you. When this happens, Git writes special conflict markers to the affected areas of the file. At this point, we have to manually solve the situation, editing that area to fit our needs.

Let's try this by performing the following steps:

As you can see, Git highlighted the conflict. A conflict-marked area begins with <<<<<<< and ends with >>>>>>>. The two conflicting blocks themselves are divided by a sequence of =======. To solve the conflict, you have to manually edit the file, deciding what to maintain, edit, or delete. After that, remove the conflict markers and commit changes to mark the conflict as resolved.

Once you resolve the conflicts, you are ready to add and commit:

Merge done, congratulations!

Removed file conflicts occur when you edit a file in a branch and another person deletes that file in their branch. Git does not know if you want to keep the edited file or delete it, so you have to take the decision. This example will show you how to resolve this both ways.

Keeping the edited file

Try again using NewFile.txt. Remove it from the NewWork branch and then modify it in master:

After that, merge NewWork in the master branch. As said earlier, Git spots a conflict. Add NewFile.txt again in the master branch and commit it to fix the problem:

When resolving merge conflicts, try to commit without specifying a message, using only the git commit command. Git will open the Vim editor, suggesting a default merge message:

This can be useful to spot merge commits looking at the repository history in the future.