A case for Git
If you`ve worked on any programming project worth more than a few hours of work, you`ve most likely used some kind of a version control system (VCS). Right now, the popular choices are CVS and Subversion at the free end, with Perforce and Team Foundation Server`s source control (formerly Source Safe) holding strongly at the commercial end.There is a new player in the field however, and it`s rapidly gaining popularity.
A little bit about Git
I`m not going to go into Git`s history and origins here, but let`s instead take a look at what Git is and why you would want to consider it over the one you`re using right now. If I had to give you just one reason, it would be: it`s FAST. Blazingly fast.
Its speed stems from several reasons, the main one being the fact that most of the operations are done locally, because it`s a distributed VCS. It`s also the main architectural difference to the systems listed above, which are centralized.
With Git, you don`t need to set up a server which will hold your master repository. Instead, in Git every repository is created equal — it contains the complete history of the project along with all other information, allowing Git to perform many operations locally without consulting the server, saving time and bandwidth. It`s possible to create a master repository on a remote server for all developers to fetch from and to commit to if you want, but it`s not required. A distributed VCS gives you more flexibility than a centralized one, but ultimately the workflow you`re going to use is your choice.
Aside from huge speed benefits, here are a few other notable advantages to using Git:
- Because of its speed, it`s much easier to work with on large projects. You won`t have the time to blink, much less to grab a cup of coffee while it performs a commit 🙂
- Each developer is much more independent from others, and from the central server. You can make a dozen commits while typing something up on the plane, for example. Once you get back online, you can send it to other developers if you wish and nothing will be lost. You can make branches without disturbing the rest of developers and you can share your changes with only some of them if that`s what you need.
- Efficient branching and merging. It`s fast and robust.
- A lot of common operations are automated, making your life easier.
- Its repository databases are surprisingly small.
- It`s clean (it only makes one .git directory in the root of the repository) — it won`t leave you with dozens of .svn directories all over the place.
- It can work with other VCSes. This is very important — you don`t have to persuade your whole company to switch before you can start using it. Just set aside an afternoon to learn the basics, then delve into the world of Git — and wonder how you`ve ever done without it.
- Did I say it`s lightning fast?
A short introduction to Git
Now that you`re armed with good reasons to learn more, let me give you a quick tour.
A git repository consists of commit objects and references to them, called â€œheadsâ€. A commit object is a set of files representing the snapshot of the project in the given moment, a set of references to parent commits and a SHA1 name — a 40-digit hex number representing the name of the commit. You can visualize the repository as an acyclic directed graph. Its leaves are â€œheadsâ€, and the main branch is called â€œmasterâ€ by default. The head on the currently active branch is called HEAD.
You typically initialize a Git repository in one of the following two ways:
git clone <other repository>
This would create a copy of <other repository> in the current directory.
This will initialize an empty repository in the current directory. You can do this in a directory which is not empty too, and then add the existing files to the repository.
Once we have initialized a repository, we can start adding content to it. In git, a file is always in one (or two) of the following states:
- Untracked. This file has not been added to the Git database but exists in the directory. This happens with every new file until you add it to the repository.
- Ignored. If the file name matches one of the ignore patterns (specified in .gitignore file), Git will simply ignore it and won`t report it as untracked or modified.
- Modified. The file, which had been added to the Git repository earlier, has been modified, but hasn`t been marked for the next commit. It`s also said it`s â€œunstagedâ€.
- Staged. The file, which had been added to the Git repository earlier, has modifications which are marked to be a part of the next commit.
- Unmodified. The file is a part of the Git repository and hasn`t been changed since the last commit.
This command will report files which are untracked, modified or staged.
To add a new file to the repository or â€œstageâ€ the modifications of a new file, you use the following command:
git add <file[s]>
This will take a snapshot of the given files and mark them to be committed. After this, git status command will report them as â€œChanges to be committedâ€. Use â€œgit add .â€ to stage all untracked and modified files.
Once you`re ready to make your commit, you`ll use:
git commit -m â€œCommit messageâ€
Now all of the changes that were marked for commit will be permanently added to the repository.
If you want to see the changes that have not yet been staged, you`ll use:
To see the changes which have been changed and will be a part of the next commit, use:
git diff –cached
The â€œ–cachedâ€ option can be used with some other commands too as a flag to show the information from the staged portion of the repository (as opposed to the unstaged).
Working with others:
Sooner or later, you`ll want to exchange some data with other developers. There are two commands you`ll use most often:
git push <other repository>
The first command will get the changes from the <other repository> into our own, and the other one will send our changes to the <other repository>. The <other repository> can be on the same machine, local network or a remote server. In case there were any conflicts, they will be reported and you can then use:
which will guide you through the conflicts, calling the configured merge tool and adding the resolved changes to the commit.
Branching and merging:
I`ve mentioned at the beginning how easy and fast it is to branch and merge in Git. There are several commands you will typically use:
to list the branches,
git branch <new branch>
to create a new branch called <new branch>,
git checkout <branch name>
to switch to the branch <branch name>,
git merge <branch name>
to merge the branch <branch name> into the current branch.
You`ll love branching and merging in Git because it`s fast — as all of these operations are almost instantaneous; it`s user-friendly, because it`s very easy to see the repository branch graph, differences between branches, etc.; it`s robust — in many cases you won`t have to do anything manually beyond telling Git to checkout a new branch or merge from an existing one, for example.
Git consists of a very rich and powerful set of commands, but you`ll be using a small subset most of the time. This article has been a short introduction to Git and there are many details I`ve left out, but by now you should have a basic understanding of how Git works. For more information see:
The official Git tutorial.
Now go enjoy Git, and spread the word!