Revision Control Systems: Quick Git Notes
A short introduction to Git
It sometimes occurs that employees of a company don’t use any version control system, because they think working with a version controller takes more time than working without it. The reality is that without such a system development-critical workflows lack proper organization. There is no documentation, iterations, builds, detailed tasks, or change requests. You just receive most information from Skype chats.
Once in our practice, the customer didn’t use any version control system for the project. As a result, the developers happened to introduce changes to exactly the same component that was already modified by their colleagues. Furthermore, some of the changes introduced resulted in broken functionality. Thus, you need more time to solve the problem. It is a bad situation, and a company probably would never be successful with a development process like that.
What did they have to do to improve the situation? There were many possible options, and it was difficult to imagine something worse. However, the first and foremost solution was to implement a version control system, such as SVN, CSV, Git, Bazaar, Mercurial, etc. The second one is to keep all tasks/bugs/requests/comments in a single location.
We really succeeded in working with Git as a version control system for projects. When using it, everyone can see what changes were made in the project’s source code and who made those changes. You have a full copy of your project across all your computers. If somebody breaks your project, you will see where the problem is located. You could also revert the latest version, if the problem is too difficult to be resolved. Git saves us a lot of time and customer’s money.
The answer to what kind of a version controller we could have used for the customer was obvious, since Git proved to be a highly effective tool for efficient source management.
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. Each 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 was mentioned above, 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 are 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
In this blog post, we are not comparing Git with other versions controllers. However, if you use another tool in your project and think of changing it to something else, it may help you to make a decision. The whole chapter in the Git book describes how to migrate to Git.
We think the best way to present Git’s functionality is to do some simple tasks. Please note that Git should be already installed. Here we use computer that runs Ubuntu, so, if you prefer another OS, you may observe some differences in behavior.
We’ll start with the task to create a public repository at GitHub. For example, FirstRepo, which allows several persons to work on a project, while keeping all history.
Let’s do it. Open github.com (we suppose you already have a registered account) and create a public repository. Then, you should configure a global user name and e-mail on your computer. For doing this, open your favorite terminal emulator and run:
$ git config --global user.name—Your Name$ git config --global user.email—youremail@example.com
Generate new key pair for access to your repository:
$ ssh-keygen -t rsa -C—youremail@example.com
Open your Git account page. In the SSH Public Key section, click add another public key and paste entry from your ~/.shh/id_rsa.pub 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 and 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 origingit@github.com:yourlogin/FirstRepo.git
Finally, push your commit into the remote repository:
$ git push origin master
If you have any problems with synchronization, look at GitHub help.
We have created a public repository and made the first commit. Let’s check it. Open the browser at github.com/yourlogin/FirstRepo. 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:
$ 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. The 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, a local branch has a single 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.1or indicate some commit$ git tag v0.1 ae0895e6b2b22843c32bcadeb91f3319f2d006f2$ git push --tags
Finally, we 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 us a note if you succeeded in implementing Git for your projects.
About the author
Further reading
