和即将用到Git的人们谈谈“Git工作流程”

团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。

Git 的一般工作流程如下：

一、克隆 Git 资源作为工作目录；

二、在克隆的资源上添加或修改文件；

三、如果其他人修改了，你可以更新资源；

四、在提交前查看修改；

五、提交修改；

六、在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

分布式工作流程

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

集中式工作流程

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

如果在公司或者团队中，你已经习惯了使用这种集中式工作流程，完全可以继续采用这种简单的模式。只需要搭建好一个中心仓库，并给开发团队中的每个人推送数据的权限，就可以开展工作了。Git 不会让用户覆盖彼此的修改。

例如 Lucy 和 Lily 同时开始工作。Lucy 完成了他的修改并推送到服务器。接着 Lily 尝试提交她自己的修改，却遭到服务器拒绝。她被告知她的修改正通过非快进式（non-fast-forward）的方式推送，只有将数据抓取下来并且合并后方能推送。这种模式的工作流程的使用非常广泛，因为大多数人对其很熟悉也很习惯。

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

主管与副主管工作流程

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

普通开发者在自己的主题分支上工作，并根据 master 分支进行变更。这里是主管推送的参考仓库的 master 分支。

工作流程总结

上面介绍了在 Git 等分布式系统中经常使用的工作流程，但是在实际的开发中，你会遇到许多可能适合你的特定工作流程的变种。现在你也许已经清楚哪种工作流程组合可能比较适合你了。