SVN’s (Subversion) time at the forefront of source control may be coming to an end. There’s a newer, quicker, lighter and more flexible solution : GIT. In this article Tim Hustler, developer at Creative Jar, shares his thoughts on GIT and why it is worth investigating further.
According to the world’s most famous open source developer, Linus Torvalds, GIT is the latest and greatest way of working with collaborative projects alongside developers from all corners of the globe. Linus is the developer who started work on the Linux kernel way back in 1991. He inspired the world with his ‘hobby operating system’ and changed the way software of this type can be developed. Collaboration between disparate developers flourished and, as the project gained steam, more and more developers from around the world were chipping in and sharing code with each other via SVN.
SVN holds a distinct image of code files at certain intervals called revisions. Every time a change is made a new revision is created and the old image is archived. Archiving is required to support rollback and this can come in handy if the submitted code turns out to be incomplete or flawed. This happens quite frequently in open source projects. While the amount of code generated in open source projects can be voluminous, the quality of it is assessed by public committees which may or may not agree with the developer’s logic and/or coding style. So changes are frequently rejected or submitted for further revision before being applied to the main development files which would then be compiled into the next release
However, consider the facts; the Linux kernel currently consists of 13,320,934 lines of code split over many thousands of files. In order for these to be compiled, a revision of each file is held and it adds up to many hundreds of thousands of states. A developer might only change one word in one line of a file, but the whole file is taken as a revision and stored in the archive, ready to be rolled back at a moment’s notice. By design SVN turned out to be problematic for huge projects and Linus started looking for alternatives.
What is GIT – a distributed version control system?
Linus himself developed a new way of mapping just the changes to a file, rather than the entire file. This makes for much smaller databases, which can be updated much faster than is possible with SVN.
GIT still has a central location for the main files, called a repository. Developers can be given access to the files over the web and the files can be downloaded in their entirety. This is where the similarity to SVN ends. The act of downloading the files creates another mini-repository local to the developer; changes to the files are compared to the local repository, allowing for local rollbacks and updates before being uploaded back to the central repository.
The files are tracked by the developer’s local repository and small sets of “deltas” are created, mapping out the lines of code which have been added/edited/deleted so these deltas can be applied to the central repository, without the need to upload the whole file, which can be many thousands of lines long.
The beauty of GIT is in its delta and merging capabilities. Its internal merger is of such great quality that manual merging of files (comparing them side-by-side and manually selecting the lines from each file that should be kept) are almost a thing of the past.
The repository itself has some great features for developers to peer review before submitting them for a central review. Paired programming can be of great benefit in stopping those nasty bugs getting in and ruining a good commit.
The commands are all written in the shell rather than using any form of drag & drop based system utilized in windows, makes perfect sense though since 99.999% of Linux programming is done in the terminal with no icons or windows in sight!!
The learning curve for GIT can be a bit overwhelming when coming from an SVN background, but you wouldn’t expect anything else from the world leader in geekonomics! Fortunately there are interface tools to help you get started.
Graphical Interface Tools
Using GIT will be much easier if you have a graphical interface. Even though GIT is a newcomer there are good options to choose from.
- GitX (Mac OS X) – GitX is a git GUI specifically for Mac OS X. It currently features a history viewer much like gitk and a commit GUI like git gui. But then in silky smooth OS X style!
- TortoiseGit (Windows) – TortoiseGit is a port of the popular TortoiseSVN project to Git. TortoiseGit is very complete, able to commit, show the history log, diff two versions, create branches and tags, create patches and more.
- Git Extensions (Windows) – Git Extensions is a small toolset to make working with Git under Windows a little more intuitive. The shell extension will intergrate in Windows Explorer and presents a nice context menu on files.
- qgit (Qt) – qgit is a Qt GUI for browsing history of Git repositories, similar to gitk but with more features.
- Tig – tig is a text-mode interface for Git. It acts as a repository browser that can also act as a pager for various Git commands and manage your index (on diff chunk level).
Well known Open Source projects are using GIT
As you can see it is some of the really large projects that have jumped on the GIT wagon. There are several others but here’s a few you can check out. There’s a good description of GIT on wikipedia if you need more details and you will see that nearly 60 projects are listed to be using GIT.