Revision as of 04:51, 13 October 2009

Introduction to Git

This guide is aimed at those who are migrating to Git from other version control systems like CVS and SVN, in order to understand some of the differences between the types of SCM system. There are other on-line resources on Git (such as the Pro Git Book and the git tutorial) which this doesn't compete with; rather, it's a summary of the concepts which will be useful to those migrating. Since this is also documentation hosted as part of the EGit project, there will likely be specific call-outs to functionality available in that tool.

This is not meant to be an advocacy piece on using Git over other version control systems; there are other sites (like why git is better than x) that cover that perspective. In addition, Git is not the right choice of tool for everyone; Google Code chose Hg over Git for entirely pragmatic reasons (in part due to Git's heavy HTTP implementation, which is currently being addressed). In any case, it is assumed that you want to use (or learn about) Git in this document rather than attempting to influence your choice.

Distributed version control systems

Distributed version control systems (Git, Hg, Bzr) differ significantly from centralised version control systems (CVS, CVN) in the way that they work and are used. With a centralised VCS, a main 'repository' exists on some server (like dev.eclipse.org) and all changes to the repository go to that one place. This has two immediate repercussions; firstly, you need to be connected to the network in order to be able to do operations, and secondly, if a server failure occurred then there would be a delay until it is restored.

Local copies

Distributed VCS work by holding an entire (local) copy of the repository locally. As such, whereas one CVS or SVN 'repository' might hold many hundreds of projects, with Distributed VCS it's fairly normal for there to be one repository per project (or set of related projects). As a comparison, the EGit and JGit components, whilst logically under the EGit project at Eclipse, are in fact two independent Git repositories, each containing multiple Java projects.

It should be noted that whilst CVS holds very little information locally, Subversion does hold the previous committed copy of the file, which means that it's possible to do (for example) svn diff without having to reach back to the server. However, most commands do not work disconnected from Subversion (e.g. svn log) whereas all commands (other than remote push/pull) in a DVCS will work disconnected.

Tree rather than linear versions

Since everyone has a local copy of a repository, and are able to commit into it, it follows that there are multiple copies of the main branch (CVS=HEAD, SVN=Trunk, Git=master). That's because in a DVCS, there is no concept of a blessed upstream repository to which everyone works through; though conventionally, there may be.

This brings about a couple of interesting points; firstly, unlike linear systems like CVS and SVN, there's no concept of a single, monotonically increasing, version number like CVS's Id or SVN's revision. Secondly, how do you refer to items in a DVCS repository anyway, in a way that makes sense if you move the changes from one repository to another?

Tools

The Git infrastructure actually holds together by using a common on-disk [#Repository] format which tools know how to interact with, rather than there being a specific library (like, for example, libsvn). As a result, whilst most commands are invoked via git, in fact many of these are not actually part of the git executable but rather external programs which are subsequently launched. For example, git add actually ends up invoking git-add to do the work.

Repository

Communication

Terminology

• Plubming
• Porcelain
• Tip
• Tree

See also gitglossary.