Git Version Control

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

See http://git-scm.com/

GIT is a "directory content manager" designed to handle absolutely massive projects with speed and efficiency, and the release of the 2.6.12 (and later) versions of the LinuxKernel as well as more and more other projects switching to it would indicate that it does this task well.

GIT was initially written by LinusTorvalds (to replace BitKeeper) with help of a group of hackers 'round the net. It is currently maintained by Junio C Hamano.

Git is tuned to the workflows of large, distributed, multi-branch OpenSource projects.

Other DistributedVersionControl systems include MercurialVersionControl, SvkVersionControl, GnuArch, MonoTone, and DARCS (DavidsAdvancedRevisionControlSystem).

Q. So how does this compare to SubVersion and SvkVersionControl?

A. SubVersion is intended to be an advanced ConcurrentVersionsSystem, with more modern underpinnings. As such, SVN kept the "checkout from a remote repository" paradigm and direct compatibility with most of CVS's commands. However, both SVN and SVK are slow, even compared with CVS. And if you lose your connection to the SVN server, then you are out of luck.

"And if you lose your connection to the SVN server, then you are out of luck." - It goes a bit deeper than that. After all, you can work around an intermittent connection to your SVN or CVS server. (The BestPractice encouraged by modern GnuEmacs installs seems to be that you run your own local VersionControl server and frequently commit all your little minute-by-minute changes and branches to that. Then when you synchronize with the "real" repository the image that you use is drawn from the head of your local server.) The fundamental difference is that Git really is distributed - it has no concept of a "central" or canonical server or version-tree, or even of a hierarchial tree of more and less central repositories. In practice, development does tend to follow those patterns, of course. But in a version-control system that assumes or relies on them, any behaviour that doesn't neatly fit the model is poorly supported and requires extra effort (like setting up a local VC repository as described above). Plausible examples of such behaviour:

You create and try out three or four possible versions of a new function while offline at 12,000m, then land and send the alternatives to some colleagues back home for advice on which to choose. Your friends offer their opinions and suggest some changes, catching a bug in one of the alternatives. Finally you choose and commit one of the versions to a public repository.
Two or more different versions of a piece of software are maintained by different projects. They periodically cooperate by exchanging code. (This is somewhat close to what actually happens in Linux development, which is why the CVS/SVN model fits it poorly.)

Git naturally supports such actions. In a slogan, Git provides MechanismNotPolicy.

SVK is closer in principle to Git, with its mirrored repositories, advanced branching, and CherryPicking. Still much slower than Git, though.

On the other hand, Git has a richer (and totally different) command set, and thus a steeper learning curve. Since Git encourages you to branch and merge a lot, there are more opportunities to screw up your repository and repositories you merge back into. I liken Git to the power/responsibility of the Unix command line. There are also convenience layers for Git, such as Cogito, which make it easier to use.

While git certainly provides plenty of opportunity to screw up your repository, it also makes it easy enough to undo your changes, and provides a handy GUI tool (gitk) so that you can see the structure of your repository. It thus encourages you to CommitEarlyAndOften.

See also http://git.or.cz/course/svn.html (Git for SVN users).

As of 2011, there's MsysGit? to run Git on Windows (you can get Git with CygWin as well).

In 2010 there are now GUI interfaces called gitk git-gui and gitg. There are others including a version of TortoiseSvn.

"And if you lose your connection to the SVN server, then you are out of luck." -- I have never had any problem with this -- just run:

svn cleanup

at the root of your project tree, and retry the operation. It has always worked for me, and it even properly resumes where it left off the last time.

That being said, I love GitVersionControl far more than I like SVN, and strongly advocate its use whenever possible. However, I've had the unfortunate experience of using git-svn on a highly unreliable network. I have discovered this isn't such a good thing. git-svn cannot properly resume after a failed network connection, and as a result, it leaves not only the svn meta-information in a corrupted state, it ALSO leaves the git meta-information in a corrupted state too! In short, don't even think of using git-svn over flakey networks.

I have not yet had the opportunity to test raw git over a flakey connection, so please don't ascribe my git-svn experiences to git proper. I'm just writing a heads-up for those who are thinking of employing git-svn on a network that is potentially unreliable. --SamuelFalvo?

In years of heavy Git use, the only network-related issues I have had have involved git-svn. My experience suggests that although git-svn is not fault-tolerant when dealing with network problems, Git itself is. I wouldn't hesitate to use Git on a flaky network, as long as I didn't have to use git-svn. --MarnenLaibowKoser, 12 Dec 2012