Revision Control Systems: Quick Git Notes

Vladislav Rovda

Git: Short introduction

Some time ago I was freelancing for a small Web development company that was creating medium-sized Web sites. The company’s employees didn’t use any version control system, because, according to them, working with any version controller takes more time than working without it. However, the working process was poorly organized. There were no documentation, iterations, builds, detailed tasks, or change requests. I was receiving most information from the Skype chats.

As usual, several developers worked for the project. Sometimes these developers made changes in the same place of the program, because they didn’t know what their co-workers were doing, or made changes that had a part of the project broken. So, we needed more time to solve that problem. It was a bad situation, and I thought that the company would never be successful with a development process like that.

So, what did they have to do to improve the situation? There were many possible solutions, and it was difficult to imagine something worse. However, in my opinion, the first and foremost solution was to implement version control system, such as SVN, CSV, Git, Bazaar, Mercurial, etc., and the second one is to keep all tasks/bugs/requests/comments in a single location. At that time, I was working in Altoros in a twenty-person team that successfully utilized Git as a version control system on a long-term commercial project. We really succeeded in working with it.

Everyone saw what changes had been made in the project’s source and who had made those changes. We had a full copy of our project across all our computers. If somebody broke our project, we saw where the problem was located. Also, we could revert the latest version, if the problem was too difficult to have been resolved. Git saved us a lot of time and customer’s money.

The answer to what kind of version controller we could have used for that small Web development company was obvious, since Git proved to be a highly effective tool for efficient source management.

So, what is Git?

Git ( is a free and open source distributed version control system designed to handle everything from small to very large projects at a high rate of speed and efficiency. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, independent of network access or a central server. Branching and merging are fast and easy to do. This project was developed by Linus Torvalds for Linux kernel development.

As I wrote, this tool is a distributed version control system, which means that if your server crashes, repercussion will not be so fatal, because a copy of the repository and all history is stored on local machines.

Git is a multiple-platform tool. You can use a console version, and there are several graphical interfaces that allow you to work with the Git repository:

  • gitk—a simple, fast tool (
  • gitg—an interface for Gtk+/GNOME (
  • giggle—another interface for Gtk+ (
  • gitx—a tool for MacOS, based on Cocoa (
  • git extensions a tool developed using .NET (
  • turtorisegit another tool for Windows (
  • and so on

In this post, I’m not comparing Git with other versions controllers. However, if you use another tool in your project and think of changing it to something else, I think it will help you make a decision. The whole chapter in the git book ( describes how to migrate to Git.

I think the best way to present Git’s functionality is to do some simple tasks. Please note that Git should be already installed. My computer runs Ubuntu, so if you prefer to use another OS, you may observe some differences in behavior.

I’ll start with the task to create a public repository at For example, FirstRepo, which allows several persons to work on a project with keeping all history.

Let’s do it.

Open (I suppose you already have a registered account) and create a public repository.
Then you should configure the global user name and e-mail on your computer. For doing this, open your favorite terminal emulator and run:

  • $ git config –global “Your Name”
  • $ git config –global

Generate new key pair for access to your repository:

  • $ ssh-keygen -t rsa -C “

Open your Git account page. In the“SSH Public Keys” section, click “add another public key” and paste entry from your ~/.shh/ to your public key into the “key” field. If you leave the title blank, the key comment (your e-mail) will be used for the title.
After that, create a folder where your project will be located:

  • $ mkdir FirstRepo

Go to that folder:

  • $ cd FirstRepo

Create a file:

  • $ touch ReadMe

Edit your file. Open ReadMe in your favorite editor, type something—for example, “Hello World”—and save it.
Add the file content to the index:

  • $ git add ReadMe

Make a commit to your local repository:

  • $ git commit –m “First commit”

Add a remote repository:

  • $ git remote add origin

Finally, push your commit into the remote repository:

  • $ git push origin master

If you have any problems with synchronization, look at github help.

So, we have created a public repository and made the first commit. Let’s check it. Open the browser at You should see the ReadMe file in your repository.

Now you can create new files or edit existing ones. Let’s create a new branch and work with it:

Return to the console and type the following there:

  • $ git branch new_branch

Change the branch to new_branch:

  • $ git checkout new_branch

Add several new files to your branch. For example, test_file_1 and test_file_2.
You can check the status of your branch using the git status command. Console output will show you which files you should add to the repository.
Add test_file_1 and test_file_2 to the repository

  • $ git add test_file_1 test_file_2

Now you can commit these files into your local repository:

  • $ git commit -m “New files”

Use the git log command for reviewing Git’s history in the terminal or another tool (gitk, gitx, gitg, etc). In our case, local branch has just one commit. Let’s imagine, you need to merge your work from your local branch into a master.

Checkout to the master:

  • $ git checkout master

Synchronize your local repository with the remote repository:

  • $ git pull origin master

You need to do this for getting a new version of the master, because anybody could make updates.
Try to merge our branches

  • $ git merge new_branch

If you have any conflicts, you will be notified to have them resolved. After that, it will be possible to review changes using the git diff command, and then you should use git add file_with_conflict. After that, type git pull origin master once again. If all of the conflicts have been resolved, you should run git push origin master.

Sometimes, we need to discard untracked changes made in our files. In this case, we should use git reset:

Modify test_file_1. The git status command shows that this file is modified. For discarding changes, you can use git reset:

  • $ git reset –hard HEAD

Now, if you run git status, nothing will be updated there.

In other scenarios, we need to freeze the state of our code in another symbolic point—for example, for rolling up a QA release for testing. In this case, we can use the git tag command:

  • $ git tag v0.1
    or indicate some commit
  • $ git tag v0.1 ae0895e6b2b22843c32bcadeb91f3319f2d006f2
  • $ git push –tags

Finally, I would like to mention one of the disadvantages that brings in some inconvenience. If any machines based on Windows or Linux/MacOS are being utilized together in your project, you will face a problem working with Line endings. However, it is possible to resolve this. See github help ( for more details.

Everything described above is only a basic demonstration of Git’s capabilities. If you are interested, start reading Git manuals and Git book. Other amazing things can be found there. Send me a note if you succeeded in implementing Git for your projects.

No Comments

Benchmarks and Research

Subscribe to new posts

Get new posts right in your inbox!