Git 学习笔记：5 分布式工作流程

分布式工作流程

同传统的集中式版本控制系统（CVCS）不同，Git 的分布式特性使得开发者间的协作变得更加灵活多样。在集中式系统中，每个开发者就像是连接在集线器上的节点，彼此的工作当时大体相像。而在 Git 中，每一个开发者同时扮演着节点和集线器的角色——也就是说，每个开发者既可以将自己的代码贡献到其他的仓库中，同时也能维护自己的公开仓库，让其他人可以在其基础上工作并贡献代码。由此，Git 的分布式协作可以为你的项目和团队衍生出种种不同的工作流程，接下来的章节会介绍几种利用了 GIt 的这种灵活性的常见应用方式。我们将讨论每种方式的优点以及可能的缺点；你可以选择使用其中的某一种，或者将它们的特性混合搭配使用。

集中式工作流

集中式系统中通常使用的是单点协作模型——集中式工作流。一个中心集线器，或者说仓库，可以接受代码，所有人将自己的工作与之同步。若干个开发者则作为节点——也就是中心仓库的消费者——并且与其进行同步。

这意味着如果两个开发者从中心仓库克隆代码下来，同时做了一些修改，那么只有第一个开发者可以顺利地把数据推送回共享服务器。第二个开发者在推送修改之前，必须先将第一个人的工作合并进来，这样才不会覆盖第一个人的修改。这和Subversion（或任何CVCS）中的概念一样，而且这个模式也可以很好地运用到Git中。

如果在公司或者团队中，你已经习惯了使用这种集中式工作流，完全可以继续采用这种简单的模式。只需要搭建好一个中心仓库，并给开发团队中的每个人推送数据的权限，既可以开展工作了。Git 不会让用户覆盖彼此的修改。例如 John 和 Jessica 同时开始工作。John 完成了他 的修改并推送到服务器。接着 Jessica 尝试提交她自己的修改，却遭到了服务器拒绝。她被告知她的修改正通过非快进式（non-fast-forward）的方式推送，只有将数据抓取下来并且合并后方能推送。这种模式的工作流程的使用非常广泛，因为大多数人对其很熟悉也很习惯。

当然这并不局限于小团队。利用 GIt 的分支模型，通过同时在多个分支上工作的方式，即使是上百人的开发团队也可以很好地在单个项目上协作。

集成管理员工作流

Git 允许多个远程仓库存在，使得这样一种工作流成为可能：每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。这种情形下通常会有个代表“官方”项目的权威的仓库。要为这个项目做贡献，你需要从该项目克隆出一个自己的公开仓库，然后将自己的修改推送上去。接着你可以请求官方仓库的维护者拉取更新合并到主项目。维护者可以将你的仓库作为远程仓库拉取更新合并到主项目。维护者可以将你的仓库作为远程仓库添加进来，在本地测试你的变更，将其合并入他们的分支并推送回官方仓库。这一流程的工作方式如下所示（见 集成管理者工作流）：

1. 项目维护着推送到主仓库。
2. 贡献者克隆此仓库，做出修改。
3. 贡献者将数据推动到自己的公开仓库。
4. 贡献者给维护者发送邮件，请求拉取自己的更新。
5. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
6. 维护者将合并后的修改推送到主仓库。

这是GitHub 和 GitLab 等集线器式（hub-based）工具最常用的工作流程。人们可以容易地将某个项目派生成自己的工作仓库，向这个仓库推送自己的修改，并为每个人所见。这么做最主要的优点之一是你可以持续地工作，而主仓库的维护者可以随时拉取你的修改。贡献者不必等待维护者处理完提交的更新——每一方都可以按照自己节奏工作。

司令官与副官工作流

这其实是多仓库工作流的变种。一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式，例如著名的 Linux 内核 项目。被称为副官（lieutenant）的各个集成管理者分别负责集成项目中的特定部分。所有这些副官头上好有一位称为司令官（dictator）的总集成管理员负责统筹。司令官维护的仓库作为参考仓库，为所有协作者提供他们需要拉取的项目代码。这个流程看起来是这样的：

1. 普通开发者在自己的特性分支上工作，并根据 master 分支进行变基。这里是司令官的 master 分支。
2. 副官将普通开发者的特性分支合并到自己的master 分支中。
3. 司令官将所有副官的 master 分支并入自己的 master 分支中。
4. 司令官将集成后的 master 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。

这种工作流程并不常用，只有当项目极为庞杂，或者需要多级管理时，才会体现出又是。利用这种方式，项目总负责人（即司令官）可以把大量分散的集成工作委托给不同的小组负责人分别处理，然后在不同时刻将大块的代码子集统筹起来，用于之后的整合。

工作流程总结

上面介绍了在 Git 等分布式系统中的经常使用的工作流程，但是在实际的开发中，你会遇到许多可能适合你的特定工作流程的变种。现在你应该已经清楚哪种工作流程组合可能比较适合你了，我们会给出一些如何扮演不同工作流程中主要角色的更具体的例子。下一节我们将会学习为项目做贡献的一些常用模式。

向一个项目贡献

描述如何向一个项目贡献的主要困难在于完成贡献有很多不同的方式。以为 Git 非常灵活，人们可以通过不同的方式来一起工作，所以描述应该如何贡献并不是非常准确——每一个项目都有一点儿不同。影响因素包括活跃贡献者的数量、选择的工作流程、提交权限与可能包含的外部贡献方法。

第一个影响因素是活跃贡献者的数量——积极地向这个项目贡献代码的用户数量以及他们的贡献频率。在许多情况下，你可能会有两三个开发者以提案提交几次，对于不活跃的项目可能更少。对于大一些的公司或项目，开发者的数量可能会是上千，每天都有成百上千次提交。这很重要，因为随着开发者越来越多，在确保你的代码能干净地应用或轻松地合并时会遇到更多的问题。提交的改动可能表现为过时的，也可能在你正在做改动或者等待改动被批准应用时被合并入的工作严重损坏。如何保证代码始终是有效的？

下一个影响的因素是项目使用的工作流程。他是中心化的吗，即每个开发者都对主线代码有相同的写入权限？项目是否有一个检查所有补丁的维护者或整合者？是否所有的补丁是同行评审后批准的？你是否参与了那个过程？是否存在副官系统，你必须先将你的工作提交到上面？

下一个问题是提交权限。是否有项目的写权限会使向项目贡献所需的流程有极大的不同。如果没有写权限，项目会选择何种方式接受贡献的工作？是否甚至有一个如何贡献的规范？你一次贡献多少工作？你多久贡献一次？

所有这些问题都会影响实际如何向一个项目贡献，以及对你来说哪些工作流程更加适合或者可用。我们将会由浅入深，通过一系列用例来讲述其中的每一个方面；从这些离子应该能够建立实际中你需要的特定工作流程。

提交准则

在我们开始查看特定的用例前，这里有一个关于提交信息的快说说明。有一个好的创建提交的准则并且坚持使用会让与Git 工作和其他人写作更容易。Git 项目提供了一个文档，其中列举了关于 创建提交到提交补丁的若干好的提示——可以在 Git 源代码中的 Documentation/SubmittingPaches 文件中阅读它。

首先，你不会想要把空白错误（根据 git help diff的描述，结合下面给出的图片，空白错误是指行尾的空格、Tab制表符，和行首空格后跟Tab制表符的行为）提交上去。Git 提供一个简单的方式来检查这点——在提交前，运行 git diff --check， 它将会找到可能的空白错误并将它们为你列出来。

如果在提交之前运行那个命令，可以知道提交中是否包含可能会使其他开发者愤怒的空白问题。

接下来，尝试让每一个提交成为一个逻辑上的独立变更集。如果可以，尝试让改动可以理解——不要在整个周末编码解决五个问题，然后在周一时将它们提交为一个巨大的提交。即使在周末期间你无法提交，在周一时使用暂存区域将你的工作量最少拆分为每个问题一个提交，并且为每一个提交附带一个有用的信息。如果其中一些改动修改了同一个文件，尝试使用 git add --patch 来部分暂存文件。不管你做一个或五个提交，只要所有的改动实在同一个时刻添加的，项目分支末端的快照就是独立的，使同事开发者必须审查你的改动时尽量让事情容易些。当你之后需要时这个方法也会使拉出或还原一个变更集更容易一些。 重写历史 描述了重写历史与交互式暂存文件的若干有用的 Git 技巧——在将工作发送给其他人前使用这些工具来帮助生成一个干净又易懂的历史。

最后一件要牢记的事是提交信息。有一个创建优质提交信息的习惯会使 Git 的使用与协作容易的多。一般情况下，信息应当以少于50个字符（25个汉字）的单行开始且简要地描述变更，接着是一个空白行，在接着是一个更详细的解释。 Git 项目要求一个更详细的的解释，包括做改动的动机和它的实现与之前行为的对比——这是一个值得遵循的好规则。在这些信息中使现在时态祈使语气也是一个好想法。换句话说，使用命令。使用 “Add tests for”而不是 “Iadded tests for”。这里是一个最初由 Tim Pope些的模板：

修改的摘要（50 个字符或更少）

如果必要的话，加入更详细的解释文字。在
大概 72 个字符的时候换行。在某些情形下，
第一行被当作一封电子邮件的标题，剩下的
文本作为正文。分隔摘要与正文的空行是
必须的（除非你完全省略正文）；如果你将
两者混在一起，那么类似变基等工具无法
正常工作。

空行接着更进一步的段落。

  - 句号也是可以的。

  - 项目符号可以使用典型的连字符或星号
    前面一个空格，之间用空行隔开，
    但是可以依据不同的惯例有所不同。

如果你所有的提交信息看起来都像这样，对你与跟你工作在一起的其他开发者来说事情会变得非常容易。 Git 项目有一个良好格式化的提交信息——尝试在那儿运行 git log --no-merges 来看看漂亮的格式化的项目提交历史。

私有小型团队

你可能会遇到的最简单的配置是有一两个其他成员的私有项目。“私有”在这个上下文中，意味着闭源——不可以从外面的世界中访问到。你和其他的开发者都有仓库的推动权限。

在这个环境下，可以盗用一个类似使用 Subversion 或其他集中式的系统时会使用的工作流程。依然可以得到像离线提交、非常容易地新建分支与合并分支等高级功能，但是工作流程可以使很简单的；只要的区别是合并发生在客户端这边而不是在提交时发生在服务器那边。让我们看看当两个开发者在一个共享仓库中一起工作时会是什么样子。第一个开发者，John ，克隆了仓库，做了改动，然后本地提交。

# John's Machine
$ git clone john@githost:simplegit.git
Initialized empty Git repository in /home/john/simplegit/.git/
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'removed invalid default value'
[master 738ee87] removed invalid default value
 1 files changed, 1 insertions(+), 1 deletions(-)

第二个开发者，Jessica，做了同样的事情——克隆了仓库并且提交了一个改动：

# Jessica's Machine
$ git clone jessica@githost:simplegit.git
Initialized empty Git repository in /home/jessica/simplegit/.git/
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'add reset task'
[master fbff5bc] add reset task
 1 files changed, 1 insertions(+), 0 deletions(-)

现在，Jessica 把她的工作推送到服务器上：

# Jessica's Machine
$ git push origin master
...
To jessica