Git

一、Git（维基百科,https://git-scm.com/book/en/v1/）

　　git（是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。应注意的是，这与GNU Interactive Tools一个类似Norton Commander界面的文件管理器）有所不同。

　　git最初的开发动力来自于BitKeeper和Monotone。git最初只是作为一个可以被其他前端（比如Cogito或Stgit）包装的后端而开发的，但后来git内核已经成熟到可以独立地用作版本控制。很多著名的软件都使用git进行版本控制，其中包括Linux内核、X.Org服务器和OLPC内核等项目的开发流程。

　　与生活中的许多伟大事物一样，Git开始时会有一些创造性的破坏和激烈的争议。 Linux内核是一个范围相当大的开源软件项目。 在Linux内核维护（1991-2002）的大部分生命周期中，对软件的更改都作为补丁和归档文件传递。 2002年，Linux内核项目开始使用名为BitKeeper的专有DVCS系统。

2005年，开发Linux内核的社区与开发BitKeeper的商业公司之间的关系破裂，该工具的免费状态被撤销。这促使Linux开发社区（尤其是Linus Torvalds，Linux的创建者）根据他们在使用BitKeeper时学到的一些经验来开发自己的工具。 新系统的一些目标如下：

• 速度
• 设计简单
• 对非线性开发的强大支持（数千个并行分支）
• 完全分布
• 能够有效地处理Linux内核等大型项目（速度和数据大小）

自2005年诞生以来，Git已经发展成熟，易于使用，并保留了这些初始品质。 它非常快，对于大型项目非常有效，并且它具有用于非线性开发的令人难以置信的分支系统（

二、Git功能

　　git是用于Linux内核开发的版本控制工具。与CVS、Subversion一类的集中式版本控制工具不同，它采用了分布式版本库的作法，不需要服务器端软件，就可以运作版本控制，使得源代码的发布和交流极其方便。git的速度很快，这对于诸如Linux内核这样的大项目来说自然很重要。git最为出色的是它的合并追踪（merge tracing）能力。

　　实际上内核开发团队决定开始开发和使用git来作为内核开发的版本控制系统的时候，世界上开源社群的反对声音不少，最大的理由是git太艰涩难懂，从git的内部工作机制来说，的确是这样。但是随着开发的深入，git的正常使用都由一些友善的命令来执行，使git变得非常好用。现在，越来越多的著名项目采用git来管理项目开发，例如：wine、U-boot等。

　　作为开源自由原教旨主义项目，git没有对版本库的浏览和修改做任何的权限限制，通过其他工具也可以达到有限的权限控制，比如：gitosis、CodeBeamer MR。原本git的使用范围只适用于Linux/Unix平台，但在Windows平台下的使用也日渐成熟，这主要归功于Cygwin、msysgit环境，以及TortoiseGit这样易用的GUI工具。git的源代码中也已经加入了对Cygwin与MinGW编译环境的支持且逐渐完善，为Windows用户带来福音。

三、Git&version Control

关于版本控制

　　什么是版本控制，为什么要关心？ 版本控制是一种记录文件或文件集随时间变化的系统，以便您以后可以调用特定版本。 尽管本书中的示例将软件源代码显示为版本控制下的文件，但实际上计算机上的任何类型的文件都可以置于版本控制之下。

　　如果您是图形或Web设计人员并希望保留图像或布局的每个版本（您当然会这样），那么使用版本控制系统（VCS）是非常明智的。 VCS允许您：将文件恢复到以前的状态，将整个项目恢复到以前的状态，查看随时间推移所做的更改，查看最后修改了可能导致问题的内容，谁引入了问题以及何时，以及更多。 使用VCS还意味着如果您搞砸了或丢失文件，通常可以轻松恢复。 此外，您只需很少的开销即可获得所有这些。

本地版本控制系统

　　很多人选择的版本控制方法是将文件复制到另一个目录（如果它们很聪明，可能是带时间戳的目录）。 这种方法很常见，因为它非常简单，但也非常容易出错。 很容易忘记你所在的目录并意外写入错误的文件或复制你不想要的文件。

　　为了解决这个问题，程序员很久以前就开发了一个本地VCS，它有一个简单的数据库，可以对文件的所有更改进行修订控制（见图1-1）。

 

图1-1。 本地版本控制图。

 

　　一种比较流行的VCS工具是一个名为rcs的系统，它现在仍然与许多计算机一起分发。 即使是流行的Mac OS X操作系统，在安装开发人员工具时也会包含rcs命令。 这个工具基本上是通过在磁盘上以特殊格式将补丁集（即文件之间的差异）从一个版本保持到另一个版本来实现的。 然后，它可以通过添加所有补丁来重新创建任何文件在任何时间点的样子。

集中版本控制系统

　　人们遇到的下一个主要问题是他们需要与其他系统上的开发人员协作。 为了解决这个问题，开发了集中版本控制系统（CVCS）。 这些系统（如CVS，Subversion和Perforce）具有包含所有版本化文件的单个服务器，以及从该中心位置检出文件的许多客户端。 多年来，这一直是版本控制的标准（见图1-2）。

 

图1-2。 集中版本控制图。

 　　此设置提供了许多优势，尤其是在本地VCS上。 例如，每个人都知道项目中的其他人正在做什么。 管理员可以对谁可以做什么进行细致的控制; 管理CVCS要比处理每个客户端上的本地数据库容易得多。

　　但是，这种设置也有一些严重的缺点。 最明显的是集中式服务器所代表的单点故障。 如果该服务器停机一小时，那么在那个小时内，任何人都无法进行协作或将版本化更改保存到他们正在处理的任何内容中。 如果中央数据库所在的硬盘损坏，并且没有保留适当的备份，那么除了人们碰巧在本地计算机上发生的任何单个快照之外，您绝对会丢失所有内容 - 项目的整个历史记录。 本地VCS系统也遇到同样的问题 - 只要您将项目的整个历史记录放在一个地方，就有可能失去一切。

分布式版本控制系统

　　这就是分布式版本控制系统（DVCS）介入的地方。在DVCS（例如Git，Mercurial，Bazaar或Darcs）中，客户端不只是查看文件的最新快照：它们完全镜像存储库。 因此，如果任何服务器死亡，并且这些系统通过它进行协作，则可以将任何客户端存​​储库复制回服务器以恢复它。 每次结账都是所有数据的完整备份（参见图1-3）。

 

图1-3。 分布式版本控制图。

 　　此外，许多这些系统可以很好地处理他们可以使用的多个远程存储库，因此您可以在同一个项目中以不同的方式与不同的人群进行协作。 这允许您设置在集中式系统中不可能的多种类型的工作流，例如分层模型。