在现代软件开发项目中，要成为一个有效的软件开发人员，我们必须能够与其他项目贡献者并行进行开发。源代码管理（SCM）系统不是什么新思想。为了编写一些能够更快速、简单地开发以后软件项目的软件，已经进行了很多尝试。最新的源代码解决方案都包含了版本控制系统，它可以对源代码的修改进行回滚，从而将有害的代码剔除出项目之外，或者简单地跟踪哪些人修改了代码的哪些行的内容。版本控制系统试图解决开发人员在试图同时对某个文件进行修改时所出现的冲突问题，可以防止用户覆盖其他人所作的修改。源代码管理使用的很多流行解决方案都试图解决以前 SCM 解决方案中的失效问题。
集中化的版本控制系统通常采用两种方式：
- 有些提供了文件锁来防止多个用户的并行访问。这些系统对文件进行加锁，这样在某个时间只有一个开发人员对中心仓库具有写入权限。
- 另外一些工具，例如 CVS，允许多个开发人员同时对相同的文件进行编辑，并提供了一些机制稍后合并这些修改。
流行的版本控制系统包括：
- CVS
- Subversion
- Arch
- Bazaar
- BitKeeper
非常简单地说，Git 是 Linus Torvalds 最近实现的源代码管理软件。正如所提供的文档中说的一样，“Git 是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。”
Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如，X.org 最近就迁移到 Git 上来了，很多 Freedesktop.org 的项目也迁移到了 Git 上。
Git 目前主要由寻找 CVS 或专有代码管理解决方案替代物的软件开发人员所使用。Git 与 CVS 有很多区别：
- 分支更快、更容易。
- 支持离线工作；本地提交可以稍后提交到服务器上。
- Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
- Git 中的每个工作树都包含一个具有完整项目历史的仓库。
- 没有哪一个 Git 仓库会天生比其他仓库更重要。
要安装当前版本的 Git，我们可以使用供应商在 Linux 发行版中提供的包，或者从最新的稳定快照开始手工进行编译。我建议下载包含最新 Git 源代码稳定快照的 tarball；截止到撰写本文时这个版本是 v1.4.0。我们可以在下面的 参考资料 一节中找到链接。
有了这个 tarball 之后，请确保初始安装所依赖的包都已经安装了。系统中必须包含以下包，以及相应的开发头文件：
- zlib
- libcurl
- libcrypto（OpenSSL）
- rsync（2.6.0 或更高版本）
这些条件满足之后，我们就可以开始编译初始的 Git 安装系统了。这个过程对于大部分一直使用 Linux 的开发人员来说应该非常熟悉了。首先使用对应下载的包格式的命令将包展开：
$ tar -jxvf git-1.4.0.tar.bz2 |
或
$ tar -zxvf git-1.4.0.tar.gz |
然后切换到适当的目录中，并执行 make 命令。（注意目录名取决于我们下载的快照的日期。）
$ cd git-1.4.0/ $ make prefix=/usr/local install $ sudo make prefix=/usr/local install |
您会被提示输入 sudo 密码才能继续安装。现在就已经准备好使用 Git 工具了。
在使用 Git 管理源代码仓库时，我们可以使用两种方法开始我们的工作。我们可以使用现有代码的一个本地目录，然后从中生成一个仓库；也可以映射其他人发布的仓库。
对于本文的目的来说，我们将获得 Torvalds 发布的 Git 仓库的一个镜像。下面的命令将创建一个名为 linux-2.6 的 Git 仓库。这个目录包含了一个隐藏目录 .git/ 。
$ git-clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ linux-2.6 |
这个步骤会执行很长时间，因为 Git 正在将内核源代码（这有数百兆大）从 kernel.org 传输到本地机器上。输出结果可能有些晦涩难懂，但是如果您有一个快速的 Internet 链接，卷屏的速度应该相当快。输出结果应该类似于图 1 所示。
图 1. 在下载内核源代码树过程中产生的输出
现在切换到包含新下载的内核的目录中：
$ cd linux-2.6 |
现在，我们应该在本地机器上有一个可以工作的 Linux 2.6 仓库了！此时我们就可以对这个仓库进行一些基本的操作了。
在使用 Git 时，我们通常可以假设自己的仓库可能比 kernel.org 的仓库有些滞后。因此我们通常都是首先将自己的仓库更新成最新的上游内核树。这个过程有时称为快速合并（fast-forward merge）。严格来说，我们现在并不需要执行这个过程，因为我们刚刚安装了自己的仓库，它应该还没有过期。但是检查一下毕竟没有坏处：
$ cd linux-2.6 $ git-pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ... |
如果成功，我们就应该会看到类似于下面的输出结果：
receiving file list ... done sent 130 bytes received 21677 bytes 14538.00 bytes/sec total size is 127865858 speedup is 5863.52 Already up-to-date. $> |
如果我们的仓库不是最新的，就会看到有些内容通过网络传输到本地机器上了。
我们需要将文件从 Git 仓库（隐藏目录中的那些文件）中导出到工作目录中才能开始自己的 hack 过程。下面的命令会在当前目录中写入没有隐藏的目录，其中包含了 Linux 的源代码：
$ git-checkout |
如果您希望覆盖本地修改，可以使用 -f 选项导出文件，这样就可以将您带回到一个干净的状态：
$ git-checkout -f |
现在在当前工作目录中，我们应该就可以看到熟悉的 Linux 源代码目录结构了，然后我们可以对这些源代码任意进行修改。
我们现在可以修改所选择的任何文件。举一个简单的例子来说，我们将修改 docs 目录中的一些内容：添加一条以后可以很容易识别的信息。为了让我的例子更容易试验，我没有选择修改源代码；不过只要您希望，欢迎继续重写整个内核的子系统。
首先，让我们在编辑器中打开一个文件：
$ vi ./Documentation/ManagementStyle |
显然，我使用的是 vi；不过您当然可以使用自己喜欢的任何编辑器来完成这项工作。在编辑文件时，我在第一段前面添加了一行：“Eli shall be in charge of managing sandwich consumption. See Documentation/Sandwiches for more.”
如果您对自己所做的修改非常满意，并且觉得自己已经准备好将其作为仓库的一个永久部分了，就需要使用下面的命令导入您的修改：
$ git-commit Documentation/ManagementStyle |
您会被提示说要求提供一个提交消息，它是一个用户生成的注释，用来帮助其他开发人员（也可能是您自己以后）理解刚才的实现到底进行了哪些修改。在我们的例子中，提交消息是一个描述刚才对文档所做修改的短句。
如果您希望检查一下到目前为止工作的状态，可以执行 git-log 来查看本地仓库的历史（它继承了所克隆的仓库的信息）。您的提交消息应该在日志的最上面。
但是请等一下！我们还没有添加 Documentation/Sandwiches 文件呢，因此我们需要将其添加到工作目录中，并告诉 Git 何时这个文件已经准备好了。我使用 echo 命令创建了想要添加的文件，因为这只是一个简单的例子而已。同样，您也可以使用自己喜欢的工具。
$ echo "Turkey is superior" > Documentation/Sandwiches |
现在我们已经添加了一个文件，接下来需要将这个文件添加到 Git 中，从而让 Git 了解这种变化，然后才能提交这个版本。我们可以通过执行下面的命令来完成这些任务：
$ git-add Documentation/Sandwiches $ git-commit Documentation/Sandwiches |
如果您添加了多个文件，可以在同一行中的 git-add 命令后面列出这些文件，不过您也不必一次将它们全部添加到仓库中去。如果要删除某个文件，并且没有 git-add 之类的特殊命令；您只需要删除这个文件，然后提交就可以了。
现在应该查看一下 git-log，从而确保到现在为止所做的事情都是正确的。这一次，我们将使用 -p 选项来以单独的补丁格式查看日志。
$git-log -p |
最后，我们希望生成一个包含您修改后的文件和原文件之间区别的文本文件。这个文件通常是使用 diff 工具创建的，因此就称为diff 文件。diff 可以帮助我们创建补丁文件（patch file），后者是我们向很多开放源码软件项目发送代码提交时通常使用的方法。有关 diff 的更多内容，请参看下面 参考资料 部分中有关 Kernel.org 的链接。
我们可以使用 Git 来管理本地仓库，而不用镜像其他人的工作。例如，如果我们喜欢使用 Git 来管理自己个人对某个开放源码项目贡献的文件，就可以从项目快照中生成一个 Git 仓库。
假设我们已经有了一个名为 release.tar.gz 的标准 release tarball，可以执行下面的命令来创建一个本地的 Git 仓库：
$ tar -zxvf release.tar.gz $ cd release $ git init-db |
我们可以看到消息说 Git 是 “默认于本地存储区域的”。这些消息都是正常的，说明我们有一个 Git 仓库。
现在我们已经对工作目录进行了初始化，接下来在项目目录中应该会看到一个新目录 .git。为了告诉 Git 我们希望对这个项目中的每个文件都进行跟踪，请执行下面的命令：
$ git add . |
最后，使用下面的命令将所监视的文件提交到仓库中：
$ git commit -a |
同样，系统会提示我们输入提交消息。从现在开始，我们就可以在自己的 Git 仓库中使用 Git 所提供的完整功能了，例如对实验特性进行分支，为了追踪回归测试问题而将代码一分为二，并使用常见的版本历史功能。
有关 Git 的分支管理和其他有趣特性的更多信息，请参看 Kernel.org 上给出的 Git 的优秀教程（参见 参考资料 中的链接）。
现在我们已经知道如何使用 Git 来获取 Linux 内核源代码和其他 Git 管理的项目了，接下来可以选择使用 Git 来管理下一个开发项目。 Git 仍然相对较新，仍然处于不断开发中。其他脚本和工具正在实现用来简化 Git 的使用；请参看 参考资料 中给出的例子。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- Kernel.org 上有很多很好的入门资源：
- Kernel Hackers' Guide to git 是一份开始入门的参考资料。
- 学习更多有关版本控制系统的知识：
- “开发者和爱好者的 CVS”（developerWorks，2001 年 3 月）
- “Subversion 简介：三千年版本控制”（developerWorks，2006 年 6 月）
- “StatCVS 提供了对 CVS 储存库活动的深入观察”（developerWorks，2005 年 2 月）
- Linux for IBM System z9 and IBM zSeries 是有关 Linux 在大型机系统上的 IBM 红皮书。
- 在 developerWorks Linux 专区 可以找到为 Linux 开发人员准备的更多资源。
- 随时关注 developerWorks 技术事件和网络广播。
获得产品和技术
- 下载 Git 源代码。
- QGit 是一个基于 QT 的 Git GUI。
- 订购免费的 SEK for Linux，这有两张 DVD，包括最新的 IBM for Linux 的试用软件，包括 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere®。
- 在您的下一个开发项目中采用 IBM 试用软件，这可以从 developerWorks 上直接下载。
讨论
- 通过参与 developerWorks blogs 加入 developerWorks 社区。