作者：[美]乔恩·罗力格（Jon Loeliger）,马修·麦卡洛（Matthew McCullough）著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Git版本控制管理(第2版)试读：
前言
本书读者如果读者有一定的版本控制系统使用经验，再阅读本书是最好不过，当然，如果读者之前没有接触过任何版本控制系统，也可以通过本书在短时间内学会Git的基本操作，从而提升工作效率。水平更高的读者通过本书可以洞悉Git的内部设计机制，从而掌握更强大的Git使用技术。
本书假定读者熟悉并使用过UNIX shell、基本的shell命令，以及通用的编程概念。假定的框架
本书所有的示例和讨论都假定读者拥有一个带有命令行界面的类UNIX系统。本书作者是在Debian和Ubuntu Linux环境下开发的这些示例。这些示例在其他环境下（比如，Mac OS X或Solaris）应该也可以运行，但是可能需要做出微调。
书中有少量示例需要用到root权限，此时，你自然应该能清楚理解root权限的职责。本书结构
本书是按照一系列渐进式主题进行组织编排的，每一个主题都建立在之前介绍的概念之上。本书前11章讲解的是与一个版本库相关的概念和操作，这些内容是在多个版本库上进行复杂操作（将在本书后10章涉及）的基础。
如果你已经安装了Git，甚至曾经简单使用过，那么你可能用不到前两章中Git相关的介绍性知识和安装信息，第3章的知识对你来说也是可有可无。
第4章介绍的概念是深入掌握Git对象模型的基础，读者可以通过第4章清楚理解Git更为复杂的操作。
第5章～第11章更为详细地讲解了Git的各个主题。第5章讲解了索引和文件管理。第6章～第10章讨论了生成提交和使用提交来形成坚实的开发路线的基础。第7章介绍了分支，你可以在一个本地版本库中使用分支操作多条不同的开发路线。第8章解释了diff的来历和使用。
Git提供了丰富、强大的功能来加入到开发的不同分支。第9章介绍了合并分支和解决分支冲突的基础。对Git模型的一个关键洞察力是意识到Git执行的所有合并是发生在当前工作目录上下文的本地版本库中的。第10章和第11章讲解了在开发版本库内进行更改、储藏、跟踪和恢复日常开发的操作。
第 12 章讲解了命名数据以及与另外一个远程版本库交换数据的基础知识。一旦掌握了合并的基础知识，与多个版本库进行交互就变成了一个交换步骤加一个合并步骤的简单组合。交换步骤是第 12 章中新出现的概念，而合并步骤则是在第 9 章讲解的。
第13章则从哲学角度对全局的版本库管理提供了抽象的讲解。它还为第14章建立了一个环境，使得使用Git原生的传输协议无法直接交换版本库信息时，能够打补丁。
接下来的4章则涵盖了一些有意思的高级主题：使用钩子（第15章）、将项目和多个版本库合并到一个超级项目中（第16章），以及与SVN版本库进行交互（第17章、第18章）。
第19章和第20章提供了一些更为高级的示例和提示、技巧、技术，从而使你成为真正的Git大师。
最后，第21章介绍了GitHub，并解释了Git如何围绕着版本控制开启了一个有创造力的社会发展进程。
Git仍然在快速发展，因为当前存在一个活跃的开发团体。这并不是Git很不成熟，你无法用它来进行开发；相反，对Git的持续改进和用户界面问题正在不断增强。甚至在本书写作的时候，Git就在不停发展中。因此，如果我不能保持Git的准确性，还请谅解。
本书没有完整地覆盖gitk命令，尽管本书应该这样做。如果你喜欢以图形方式来呈现版本库中的历史，建议你自行探索gitk命令。当前也存在其他历史可视化工具，这些也没有在本书中介绍。本书甚至不能完全涵盖Git自带的核心命令和选项。再次向读者道歉！
但是，我仍然希望读者能够从本书中找到足够的线索、提示和方向，从而激励读者自行研究、积极探索Git。本书约定 提示这个图标用来强调一个提示、建议或一般说明。
警告这个图标用来说明一个警告或注意事项。
此外，读者应该熟悉基本的shell命令，以用来操作文件和目录。许多示例会包含一些命令，来完成添加/删除目录、复制文件和创建简单的文件等操作。$ cp file.txt copy-of-file.txt$ mkdir newdirectory$ rm file$ rmdir somedir$ echo "Test line" > file$ echo "Another line" >> file
需要使用root权限来执行的命令会作为一个sudo操作出现。# Install the Git core package$ sudo apt-get install git-core
如何在工作目录中编辑文件或效果如何改变则完全取决于你。你应该熟悉一款文本编辑器的用法。本书会通过直接注释或者伪代码的方式来表示文件的编辑过程。# edit file.c to have some new text$ edit index.html代码示例的使用
本书的目的是为了帮助读者完成工作。一般而言，你可以在你的程序和文档中使用本书中的代码，而且也没有必要取得我们的许可。但是，如果你要复制的是核心代码，则需要和我们打个招呼。例如，你可以在无须获取我们许可的情况下，在程序中使用本书中的多个代码块。但是，销售或分发O’Reilly图书中的代码光盘则需要取得我们的许可。通过引用本书中的示例代码来回答问题时，不需要事先获得我们的许可。但是，如果你的产品文档中融合了本书中的大量示例代码，则需要取得我们的许可。
在引用本书中的代码示例时，如果能列出本书的属性信息是最好不过。一个属性信息通常包括书名、作者、出版社和ISBN。例如：“Version Control with Git by Jon Loeliger and Matthew McCullough. Copyright 2012 Jon Loeliger, 978-1-449-31638-9.”
在使用书中的代码时，如果不确定是否属于正常使用，或是否超出了我们的许可，请通过permissions@oreilly.com与我们联系。联系方式
如果你想就本书发表评论或有任何疑问，敬请联系出版社：
美国：
O’Reilly Media Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
关于本书的技术性问题或建议，请发邮件到：
bookquestions@oreilly.com
欢迎登录我们的网站（http://www.oreilly.com
），查看更多我们的书籍、课程、会议和最新动态等信息。
Facebook: http://facebook.com/oreilly
Twitter: http://twitter.com/oreillymedia
YouTube: http://www.youtube.com/oreillymedia致谢
没有众多人士的帮助，本书根本不可能问世。我要感谢Avery Pennarun为第15章、第16章和第18章贡献了大量资料，他还贡献了第4章和第9章的部分内容。感谢他的付出！感谢Matthew McCullough对第17章和第21章贡献的资料，此外还提供了大量的建议和意见。Martin Langhoff对第13章的一些版本库发布建议进行了阐述。Bart Massey的无须跟踪来保存文件的技巧也出现在了本书中。我要公开感谢在各个阶段花费时间来审阅本书的所有人：Robert P. J. Day、Alan Hasty、Paul Jimenez、Barton Massey、Tom Rix、Jamey Sharp、Sarah Sharp、Larry Streepy、Andy Wilcox和Andy Wingo。重点感谢Robert P. J. Day，他参与审阅了本书的所有版本。
我还要感谢爱妻Rhonda和爱女Brandi、Heather，她们提供了各种支持，包括黑皮诺葡萄酒以及偶尔在语法上给予提示。还要感谢我的长矛猎犬Mylo，在我写作期间，它一直温柔地蜷缩在我的怀中。
最后，感谢O’Reilly的全体工作人员以及编辑Andy Oram和Martin Streicher。第1章介绍1.1 背景
现如今，难以想象有创意的人会在没有备份策略的情况下启动一个项目。数据是短暂的，且容易丢失——例如，通过一次错误的代码变更或者一次灾难性的磁盘崩溃。所以说，在整个工作中持续性地备份和存档是非常明智的。
对于文本和代码项目，备份策略通常包括版本控制，或者叫“对变更进行追踪管理”。每个开发人员每天都会进行若干个变更。这些持续增长的变更，加在一起可以构成一个版本库，用于项目描述，团队沟通和产品管理。版本控制具有举足轻重的作用，只要定制好工作流和项目目标，版本控制是最高效的组织管理方式。
一个可以管理和追踪软件代码或其他类似内容的不同版本的工具，通常称为：版本控制系统（VCS），或者源代码管理器（SCM），或者修订控制系统（RCS），或者其他各种和“修订”、“代码”、“内容”、“版本”、“控制”、“管理”和“系统”等相关的叫法。尽管各个工具的作者和用户常常争论得喋喋不休，但是其实每个工具都出于同样的目的：开发以及维护开发出来的代码、方便读取代码的历史版本、记录所有的修改。在本书中，“版本控制系统”（VCS）一词就是泛指一切这样的工具。
本书主要介绍Git这款功能强大、灵活而且低开销的VCS，它可以让协同开发成为一种乐趣。Git由Linus Torvalds发明，起初是为了①方便管理Linux内核的开发工作。如今，Git已经在大量的项目中得到了非常成功的应用。1.2 Git的诞生
通常来说，当工具跟不上项目需求时，开发人员就会开发一个新的工具。实际上，在软件领域里，创造新工具经常看似简单和诱人。然而，鉴于市面上已经有了相当多的VCS，决定再创造一个却应该是要深思熟虑的。不过，如果有着充分的需求、理性的洞察以及良好的动机，则完全可以创造一个新的VCS。
Git就是这样一个VCS。它被它的创造者（Linus，一个脾气急躁又经常爆出冷幽默的人）称作“从地狱来的信息管理工具”。尽管Linux社区内部政治性的争论已经淹没了关于Git诞生的情形和时机的记忆，但是毋庸置疑，这个从烈火中诞生的VCS着实设计优良，能够胜任世界范围内大规模的软件开发工程。
在Git诞生之前，Linux内核开发过程中使用BitKeeper来作为VCS。BitKeeper提供当时的一些开源VCS（如RCS、CVS）所不能提供的高级操作。然而，在2005年春天，当BitKeeper的所有方对他们的免费版BitKeeper加入了额外的限制时，Linux社区意识到，使用BitKeeper不再是一个长期可行的解决方案。
Linus本人开始寻找替代品。这次，他回避使用商业解决方案，在自由软件包中寻找。然而，他却发现，在现有的自由软件解决方案中，那些在选择BitKeeper之前曾经发现的，导致他放弃自由软件解决方案的一些限制和缺陷如今依然存在。那么，这些已经存在的VCS到底存在什么缺陷？Linus没能在现有VCS中找到的有关特性到底是哪些？让我们来看看。有助于分布式开发
分布式开发有很多方面，Linus希望有一个新的VCS能够尽可能覆盖这些方面。它必须允许并行开发，各人可以在自己的版本库中独立且同时地开发，而不需要与一个中心版本库时刻同步（因为这样会造成开发瓶颈）。它必须允许许多开发人员在不同的地方，甚至是离线的情况下，无障碍地开发，能够胜任上千开发人员的规模
仅仅支持分布式开发模型还是不够的。Linus深知，每个Linux版本都凝聚了数以千计开发人员的心血。所以新的VCS必须能够很好地支持非常多的开发人员，无论这些开发人员工作在整个项目相同还是不同的部分。当然，新的VCS也必须能够可靠地将这些工作整合起来。性能优异
Linus决心要确保新的VCS能够快速并且高效地执行。为了支持Linux内核开发中大量的更新操作，他知道不管是个人的更新操作，还是网络传输操作，都需要保证执行速度。为了节约存储空间，从而节约传输时间，需要使用“压缩”和“差异比较”技术。另外，使用分布式开发模型，而非集中式模型，同样也确保了网络的不确定因素不会影响到日常开发的效率。保持完整性和可靠性
因为Git是一个分布式版本控制系统，所以非常需要能够绝对保证数据的完整性和不会被意外修改。那如何确定，在从一个开发人员到另一个开发人员的过程中，或者从一个版本库到另一个版本库的过程中，数据没有被意外修改呢？又如何确定版本库中的实际数据就是认为的那样？
Git使用一个叫做“安全散列函数”（SHA1）的通用加密散列函数，来命名和识别数据库中的对象。虽然也许理论上不是绝对的，但是在实践中，已经证实这是足够可靠的方式。强化责任
版本控制系统的一个关键方面，就包括能够定位谁改动了文件，甚至改动的原因。Git对每一个有文件改动的提交（Git把一个历史版本叫做一个“提交”）强制使用“改动日志”。“改动日志”中存储的信息由开发人员、项目需求、管理策略等决定。Git确保被VCS管理的文件不会被莫名地修改，因为Git可以对所有的改动进行责任追踪。不可变性
Git版本库中存储的数据对象均为不可变的。这意味着，一旦创建数据对象并把它们存放到数据库中，它们便不可修改。当然，它们可以重新创建，但是重新创建只是产生新的数据对象，原始数据对象并不会被替换。Git数据库的设计同时也意味着存储在版本数据库中的整个历史也是不可变的。使用不可变的对象有诸多优势，包括快速比较相同性。原子事务
有了原子事务，可以让一系列不同但是相关的操作要么全部执行要么一个都不执行。这个特性可以确保在进行更新或者提交操作时，版本数据库不会陷入部分改变或者破损的状态。Git通过记录完整、离散的版本库状态来实现原子事务。而这些版本库状态都无法再分解成更小的独立状态。支持并且鼓励基于分支的开发
几乎所有的VCS都支持在同一个项目中存在多个“支线”。例如，代码变更的一条支线叫做“开发”，而同时又存在另一条支线叫做“测试”。每个VCS同样可以将一条支线分叉为多条支线，在以后再将差异化后的支线合并。就像大多数VCS一样，Git把这样的支线叫做“分支”，并且给每个分支都命名。
伴随着分支的就是合并。Linus 不仅希望通过简单的分支功能来促进丰富的开发分支，还希望这些分支的合并可以变得简单容易。因为通常来说，分支的合并是各VCS使用中最为困难和痛苦的操作，所以，能够提供一个简单、清晰、快速的合并功能，是非常必要的。完整的版本库
为了让各个开发人员不需要查询中心服务器就可以得到历史修订信息，每个人的版本库中都有一份关于每个文件的完整历史修订信息就非常重要。一个清晰的内部设计
即使最终用户也许并不关心是否有一个清晰的内部设计，对于Linus以及其他Git开发人员来说，这确实非常重要。Git的对象模型拥有者简单的结构，并且能够保存原始数据最基本的部分和目录结构，能够记录变更内容等。再将这个对象模型和全局唯一标识符技术相结合，便可以得到一个用于分布式开发环境中的清晰数据对象。免费自由（Be free, as in freedom）
——Nuff曾说过。
有了创造一个新VCS的清晰理由后，许多天才软件工程师一起创作出了Git。需求是创新之母！1.3 先例
VCS的完整历史已经超出了本书的讨论范围。然而，有一些具有里程碑、革新意义的系统值得一提。这些系统对Git的开发或者有重要的铺垫意义，或者有引导意义。（本节为可选章节，希望能够记录那些新特性出现的时间，以及在自由软件社区变得流行的时间。）
源代码控制系统（Source Code Control System, SCCS）是UNIX②上最初的几个系统之一，由M. J. Rochkind于20世纪70年代早期开发。[“The Source Code Control System,” IEEE Transactions on Software Engineering 1(4) (1975): 364-370.]这是有证可查的可以运行在UNIX系统上的最早的VCS。
SCCS提供的数据存储中心称为“版本库”（repository），而这个基本概念一直沿用至今。SCCS同样提供了一个简单的锁模型来保证开发过程有序。如果一个开发人员需要运行或者测试一个程序，他需要将该程序解锁并检出。然而，如果他想修改某个文件，他则需要锁定并检出（通过UNIX文件系统执行的转换）。当编辑完成以后，他又可以将文件检入到版本库中并解锁它。
修订控制系统（Revision Control System，RCS）由Walter F. Tichy于20世纪80年代早期引入[“RCS: A System for Version Control,”Software Practice and Experience 15(7) (1985): 637-654.]。RCS引入了双向差异的概念，来提高文件不同版本的存储效率。
并行版本系统（Concurrent Version System，CVS）由Dick Grune于1986年设计并最初实现。4年后又被Berliner和他的团队融入RCS模型重新实现，这次实现非常成功。CVS变得非常流行，并且成为开源社（http:www.opensource.org）区许多年的事实标准。CVS相对RCS有多项优势，包括分布式开发和版本库范围内对整个“模块”的更改集。
此外，CVS引入了一个关于“锁”的新范式。而之前的系统需要开发人员在修改某个文件之前先锁定它，一个文件同时只允许一个开发人员进行修改，所有需要修改这个文件的开发人员需要有序等候。CVS给予每个开发人员对于自己的私有版本写的权限。因此，不同开发人员的改动可以自动合并，除非两个开发人员尝试修改同一行。如果出现修改同一行的情况，那这一行将会作为“冲突”被标记出来，由开发人员手动去解决。这个关于“锁”的新规则使得多个开发人员可以并行地编写代码。
就像经常发生的那样，对CVS短处和缺点的改进，促进了新VCS的诞生：Subversion（SVN）。SVN于2001年问世，迅速风靡了开源社区。不像CVS，SVN以原子方式提交改动部分，并且更好地支持分支。
BitKeeper和Mercurial则彻底抛弃了上述所有解决方案。它们淘汰了中心版本库的概念，取而代之的，数据的存储是分布式的，每个开发人员都拥有自己可共享的版本库副本。Git则是从这种端点对端点（Peer to Peer）的模型继承而来。
最后，Mercurial和Monotone首创了用散列指纹来唯一标识文件的内容，而文件名只是个“绰号”，旨在方便用户操作，再没有别的作用。Git沿用了这个概念。从内部实现上来说，Git的文件标识符基于文件的内容，这是一个叫做“内容可寻址文件存储”（Content Addressable File Store，CAFS）的概念。这不是一个新概念。［见“The Venti Filesystem,” (Plan 9), Bell Labs, http://www.usenix.org/events/fast02/quinlan/quinlan_html/index.html.③
］ 据Linus的说法，Git直接从Monotone借用了这个概念。Mercurial也同时实现了这个概念。1.4 时间线
有了应用场景，有了一点额外的动力，再加上对新VCS的需求迫在眉睫，Git于2005年4月诞生了。
4月7日，Git从以下提交起，正式成为自托管项目。commit e83c5163316f89bfbde7d9ab23ca2e25604af29Author: Linus Torvalds
不久之后，Linux内核的第一个提交也诞生了。commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2Author: Linus Torvalds
这一次提交将整个Linux内核导入Git版本库中。这次提交的统计信息如下：17291 files changed, 6718755 insertions(+), 0 deletions(-)
是的，这次提交足足引入了670万行代码！
仅仅过了3个小时，Linux内核第一次用Git打上了补丁。Linus在2005年4月20日向Linux内核邮件列表正式宣布，用上Git了！
Linus非常清楚自己想回到Linux内核的开发中去，所以，在2005年7月25日，Linus将Git代码维护工作交接给Junio Hamano。并声称，Junio是显而易见的选择。
大概两个月以后，版本号为2.6.12的Linux内核正式发布，所用VCS正是Git。1.5 名字有何含义
据Linus宣称，命名为Git，是因为“我是一个自私的混蛋，我照⑤着自己命名我所有的项目，先是Linux，现在是git”。倘若，Linux这个名字是Linus和Minix的某种结合。那么反用一个表示愚蠢无用之人的英语词汇也不是没可能。
那之后，也有人曾建议，使用一些其他也许更让人舒服的解释。其中最受欢迎的一个就是：全局信息追踪器（Global Information Tracker）。① Linux是Linus Torvalds在美国和其他国家的注册商标。——原注② UNIX是Open Group在美国和其他国家的注册商标。——原注③ 私人电子邮件。——原注④ 关于旧的Bitkeeper日志如何导入Git版本库（2.5之前）的悠久历史的起点，参见http://kerneltrap.org/node/13996。——原注⑤ 参见http://www.infoworld.com/article/05/04/19/HNtorvaldswork_1.html。——原注第2章安装Git
在本书撰写期间，Git（似乎）没有被默认安装在任何GNU/Linux发行版或者任何其他操作系统上。所以，在能使用Git之前，必须先安装它。安装Git的步骤会因为操作系统供应商和版本的不同，而有很大的不一样。本章将介绍如何在Linux、Microsoft Windows和Cygwin里安装Git。2.1 使用Linux上的二进制发行版
很多Linux厂商提供预编译的二进制包，以便于安装新的应用程序、工具和实用程序。每个二进制包都指定了其依赖关系，而且发行版的包管理器通常一步（精心策划和自动地）就安装完成需要和想要的软件包。2.1.1 Debian/Ubuntu
在大多数Debian和Ubuntu系统中，Git是很多包的集合，其中的每个包都可以根据需要独立安装。在12.04版本前，Git的主要包称为git-core。当12.04版本时，则简称为git，而且相关文档则存在git-doc中。当然还有其他不同的包可使用。git-archgit-cvsgit-svn
如果你需要将一个项目从Arch、CVS或者SVN转变为Git，或者反过来，则需要安装一个或多个以上这些包。git-guigitkgitweb
如果你更倾向于在图形界面的应用程序或者Web浏览器上浏览你的版本库，那就适当安装这些包。git-gui是Git的一种基于Tcl/Tk的图形用户界面；gitk是另一种用Tcl/Tk编写的但更侧重于项目历史可视化的Git浏览器。gitweb则是用Perl写的，用于在浏览器里显示Git版本库。git-email
通过电子邮件发送Git补丁在一些项目中非常常见。如果你想这么做，这个包是必不可少的组成部分。git-daemon-run
安装这个包，就能共享你的版本库。它建立了一个守护进程服务，使你能够通过接受匿名下载请求的方式来共享你的版本库。
因为发行版之间差别很大，所以最好去搜索你的发行版的包仓库来找到Git依赖的完整包列表。强烈推荐使用git-doc和git-email。 警告Debian和Ubuntu提供了一个叫git的包，但它并属于本
书讨论的Git版本控制系统。git是一个完全不同的程序，称
为GNU交互工具（GNU Interactive Tools）。小心不要意外
安装了错误的包！
下面的命令通过以root权限执行apt-get来安装重要的Git包：$ sudo apt-get install git git-doc gitweb \ git-gui gitk git-email git-svn2.1.2 其他发行版
为了在其他Linux发行版上安装Git，要找到合适的包，并用该发行版原生的包管理器来安装。
例如，在Gentoo系统中，使用emerge命令。$ sudo emerge dev-util/git
在Fedora中，使用yum命令。$ sudo yum install git
Fedora的git大致上相当于Debian的git。其他i386 Fedora软件包包括以下几个。git.i386：
Git的核心工具。git-all.i386：
用来获取其他Git工具的元软件包。git-arch.i386：
用来导入Arch库的Git工具。git-cvs.1386：
用来导入CVS库的Git工具。git-daemon.i386：
Git协议守护进程。git-debuginfo.i386：
git包的调试信息。git-email.i386：
用来发送电子邮件的Git工具。git-gui.i386：
Git的GUI工具。git-svn.i386：
用来导入SVN库的Git工具。gitk.i386：
Git版本树可视化工具。
再次提醒一下，要注意到一些发布版，如Debian。有的发行版可能把Git拆分成许多不同的包。如果系统缺少特定的Git命令，可能需要安装额外的软件包。
一定要确认发行版的Git包是足够新的。在Git安装到系统上后，执行git --version命令。如果你的协作者使用的是更新版本的Git，你可能需要自己构建一个Git来替换掉发行版预编译好的Git软件包。通过查看你的包管理器文档，可以知道如何移除以前安装的软件包；下一节将学习如何从源码构建Git。2.2 获取源代码
如果你想从官方来源下载Git代码，或者想要最新版本的Git，可以访问Git的主版本库。在此书撰写期间，Git的主版本库在http://git.kernel.org
的pub/software/scm目录中。
这本书里描述的Git的版本大约为1.7.9，但你可能想要下载最新版本的git的源。可以在http://code.google.com/p/git-core/downloads/list
找到所有可用版本的列表。
要开始构建，先下载1.7.9版本（或更新）的源代码并解压缩。$ wget http://git-core.googlecode.com/files/git-1.7.9.tar.gz$ tar xzf git-1.7.9.tar.gz$ cd git-1.7.92.3 构建和安装
Git和其他开源软件很像，只要配置它，输入make，然后安装。小事一桩，不是吗？也许吧。
如果你的系统有合适的库和健壮的编译环境，而且如果你不需要自定义Git，那么编译代码可以说是小菜一碟。相反，如果你的机器没有编译器或一组服务器和软件开发库，或者你从来没有从源代码开始编译过一个复杂的应用程序，那么建议你把从头开始构建Git作为最后的手段。Git是高度可配置的，构建它时不应该掉以轻心。
接着继续构建，在git源码包里查看INSTALL文件。这个文件列出了一些外部依赖关系，包括zlib、openssl和libcurl库。
有些必需的库和包有点不明确，或者属于更大的包。这里有3个针对Debian稳定发行版的小贴士。● curl-config，这是一个用来提取关于本地curl的安装信息的小工
具，位于libcurl4- openssl-dev包里。● 头文件expat.h来自libexpat1-dev包。● msgfmt工具属于gettext包。
编译源代码被认为是“开发”工作，因此已经安装的普通二进制版本的库是不够用的。相反，你需要-dev版本的。因为开发版本提供了编译过程中需要的头文件。
如果这些包无法定位，或者在系统中必需的库无法找到，Makefile和配置参数提供了替代方案。例如，如果你没有expat库，你可以在Makefile中设置NO_EXPAT选项。但这样，你的构建版本会缺少某些功能，就像在Makefile中指出的那样。例如，你将不能通过HTTP和HTTPS传输把修改推送到远程库中。
其他Makefile配置选项支持适配到不同的平台和发行版。例如，一些标识适用于Mac OS X的Darwin操作系统。无论是手动修改并选择适当的选项，或者找到在顶层的INSTALL文件中自动设置的参数。
一旦你的系统和编译选项都准备好了，剩下的工作就很简单了。默认情况下，Git安装在主目录的子目录～/bin/、～/lib/和～/share/。在一般情况下，只在你是个人使用Git并且不与其他用户共用的情况下，默认选项才是有用的。
下述命令用来构建和安装Git到主目录中。$cd git-1.7.9$./configure$make all$make install
如果你想要在其他位置安装Git，如安装在/usr/local/中以供通用的访问，你可以在./configure命令中加入--prefix=/ur/local。接着，以普通用户权限执行make命令，但要以root权限运行make install命令。$cd git-1.7.9$./comfigure -- prefix=/usr/local$make all $sudo make install
要安装Git文档，在make和make install命令中加入相应的doc与install-doc目标。$cd git-1.7/9$make all doc$sudo make install install-doc
为了完整地构建文档，还需要另外几个库。作为替代方案，预编译的手册和HTML页面是可选的而且可以单独安装；如果你选择走这条路，需要小心避免版本不匹配的问题。
从源代码开始的编译包括所有Git的子包和命令，如git-email和gitk。没有必要单独安装或编译这些工具。2.4 在Windows上安装Git
Windows上有两种互相竞争的Git包：基于Cygwin的Git和称为“原生”版本的msysGit。
最初，只支持Cygwin版本的Git，而msysGit是实验版而且不稳定。但是在本书出版之时，两种版本都已经可以很好地运行并支持几乎同样的功能。但是Git1.6.0版本中，有个非常重要的例外：msysGit尚未完全正确支持git-svn功能。如果需要在Git和SVN之间交互操作，那么必须使用Cygwin版本的Git。除此之外，可以按个人的偏好选择所用①的版本。
如果你不确定该选哪个好，这里有一些经验之谈。● 如果你已经在Windows上使用Cygwin了，就使用Cygwin版本的
Git，因为这样它可以与Cygwin的设置的交互操作得更好。比如，
所有Cygwin风格的文件名会适用于Git，重定向程序的输入、输
出会始终完全按预期工作。● 如果没有使用Cygwin，那么msysGit的安装更加容易，因为它有
自己的独立安装程序。● 如果想让Git集成在Windows资源管理器shell中（比如，在一个文
件夹右击并选择Git GUI Here或Git Bash Here命令），就安装
msysGit。如果你想要这个功能但是更喜欢使用Cygwin，那你可
以两个都安装，这不会造成损害。
如果你仍然对选择安装包存有疑惑，就安装msysGit。确保你获取的是最新版本（1.7.10或者更高），因为Git对Windows的支持程度在后续版本中稳步提升。2.4.1 安装Cygwin版本的Git
顾名思义，Cygwin的Git包是Cygwin系统本身的一个包。运行Cygwin的setup.exe程序就可以进行安装。程序可以从http://cygwin.com
上下载到。
setup.exe启动后，直到你到了安装软件包列表那步，程序对于大多数选项使用默认设置。Git包在devel类别下，如图2-1所示。图2-1 安装Cygwin
选择要安装的软件包后，单击几次Next按钮直到Cygwin安装完成。然后，可以从Start菜单启动Cygwin Bash Shell，现在菜单应该包括git命令了（见图2-2）。
作为一种替代方案，如果你的Cygwin配置包括各种编译工具，如gcc和make，那你可以按照跟在Linux上一样的指令在Windows上构建你自己的Git副本了。图2-2 Cygwin shell2.4.2 安装独立的Git（msysGit）
在Windows系统上很容易安装msysGit，因为该安装包已包含它所有的依赖关系。它甚至有Secure Shell（SSH）命令来生成版本库维护者需要的控制访问权限的密钥。msysGit能很好地与Windows风格的原生应用程序（如Windows资源管理器shell）集成。
首先，从它首页http://code.google.com/p/msysgit
下载最新版本的安装程序。该文件名通常类似Git-1.5.6.1-pre-view20080701.exe。
下载完成后，运行安装程序。你应该看到一个如图2-3所示的界面。图2-3 安装msysGit
根据实际安装的版本，你可能需要单击Next按钮跳过兼容性通知，如图2-4所示。该通知涉及Windows风格和UNIX风格的换行符（即CRLF和LF）之间的不兼容性。图2-4 msysGit通知
单击几次Next按钮直到你看到图2-5所示的界面。因为日常运行msysGit的最好方式是通过Windows资源管理器，所以勾选如图2-5所示那两个相关的复选框。图2-5 msysGit选项
此外，启动Git Bash（可以使用git命令的命令提示符）的图标安装在Start菜单中的Git下。因为本书中大多数例子使用命令行，所以我们从使用Git Bash开始。
本书中的所有例子在Linux和Windows上都能同样正常工作，有一点需要注意：Windows的msysGit使用在3.1节提到的旧的Git命令名。②如果用msysGit运行例子，使用git-add替换git add。① 这在最新版本的msysGit中已经修复。——译者注② 新版本已经使用现代的Git命令名。——译者注第3章起步
Git负责管理变化。鉴于这一意图，Git与其他版本控制系统有许多共同点。许多原则——提交的概念、变更日志、版本库——是一样的，工作流在概念上也是相似的。不过，Git还提供了许多新奇事物。其他版本控制系统的观念和做法可能在Git上有所不同，甚至可能根本不能用。但无论你经验多少，本书会介绍Git是怎样工作的并使你精通此道。
让我们开始吧。3.1 Git命令行
Git简单易用。只要输入git，Git就会不带任何参数地列出它的选项和最常用的子命令。$ gitgit [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]The most commonly used git commands are: add Add file contents to the index bisect Find the change that introduced a bug by binary search branch List, create, or delete branches checkout Checkout and switch to a branch clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, the commit and working trees, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete, or verify a tag object signed with GPG
要得到一个完整（有点让人生畏）的git子命令列表，可以输入git help --all。
正如你可以从使用提示中看到的，只有极少数的选项适用于git。大多数选项，以[ARGS]的形式显示在提示中，适用于特定的子命令。
例如，--version选项影响git命令，并显示版本号。$ git --versiongit version 1.6.0
相似的例子有，--amend是专门适用于git子命令commit的选项。$ git commit –amend
有些调用同时要求这两种选项（在这里，命令行中多余的空格仅仅是在视觉上将子命令和基础命令分离，而不是必需的）。$ git --git-dir=project.git repack –d
为方便起见，每个git子命令的文档都可以通过使用git help subcommand、git --help subcommand或者git subcommand --help来查看。
从历史上来看，Git是作为一套简单的、独特的、独立的命令提供的，并按照“UNIX工具包”的哲学来开发的：打造小的、可互操作的工具。每条命令都留有一个带连字符的名字，如git-commit和git-log。而现在开发人员之间的趋势是使用一条简单的可执行的git命令并附加上子命令。但话虽如此，git commit和git-commit形式上是相同的。 提示可以访问http://www.kernel.org/pub/software/scm/git/
docs/来在线阅读完整的Git文档。
试读结束[说明：试读内容隐藏了图片]