Git工程开发实践（五）——Git分布式工做流程

Git工程开发实践（五）——Git分布式工做流程

1、Git分布式工做流程简介

与集中式版本控制系统(CVCS)不一样，Git的分布式特性使得开发者间的协做变得更加灵活多样。在集中式系统中，每一个开发者就像是链接在集线器上的节点，彼此的工做方式大致相同。 而在Git中，每一个开发者同时扮演着节点和集线器的角色，即每一个开发者既能够将本身的代码贡献到其它的仓库中，同时也能维护本身的公开仓库，让其余人能够在其基础上工做并贡献代码。 所以，Git的分布式协做能够为项目和团队衍生出各类不一样的工做流程。常见的Git分布式工做流程有集中式工做流程、集成管理者工做流程、司令官与副官工做流程。

2、Git集中式工做流程

集中式工做流很好地借鉴了集中式版本控制系统的工做模式。集中式工做流一般包含一个中央服务器，能够接受代码；每一个开发者做为一个节点，将本身的工做与中央服务器同步。若是两个开发者从中心仓库克隆代码下来，同时做了一些修改，那么只有第一个开发者能够顺利地把数据推送回中央服务器。 第二个开发者在推送修改前，必须先将第一我的的工做合并进来，才不会覆盖第一我的的修改。

集中式工做流程只须要搭建好一个中心仓库，并给开发团队中的每一个人推送数据的权限，就能够开展工做。Git不会让用户覆盖彼此的修改。 例如John和Jessica同时开始工做。 John完成了本身的修改并推送到服务器。 接着Jessica尝试提交本身的修改，却遭到服务器拒绝。Jessica会被告知她的修改正经过非快进式(non-fast-forward)的方式推送，只有将数据抓取下来而且合并后方能推送。
集中式工做流程使用很是普遍，大多数人对其很熟悉也很习惯。但集中式工做流程并不局限于小团队，经过利用Git分支模型管理，经过同时在多个分支上工做的方式，即便上百人的开发团队也能够很好地在单个项目上协做。

3、集成管理者工做流程

Git容许多个远程仓库存在，每一个开发者拥有本身仓库的写权限和其余全部人仓库的读权限。集成管理者工做流程中，一般会有个官方项目的权威仓库。若是要为项目作贡献，须要从官方项目克隆（Fork）出一个本身的公开仓库，而后将本身的修改推送到本身的公开仓库；而后能够请求官方仓库的维护者拉取本身公开仓库的更新合并到主项目。维护者能够将贡献者的公开仓库做为远程仓库添加进来，在本地测试贡献者的变动，将其合并入维护者的本地仓库分支并推送到官方仓库。

集成管理者工做流程工做方式以下：
A、贡献者克隆官方主仓库到本身本地。
B、贡献者在本身本地仓库进行修改，并推送到本身公开仓库。
C、贡献者给维护者发送邮件，请求拉取本身的更新。
D、维护者在本身本地的仓库中，将贡献者的公开仓库加为远程仓库并合并修改。
E、维护者将合并后的修改推送到官方主仓库。
集成管理者工做流程是GitHub和GitLab等在线代码托管工具最经常使用的工做流程，很是适合社区开源项目的开发。Pull Request和Merge Request就是集成管理者工做流程的最佳工程实践。
贡献者能够容易地将某个项目派生成为本身的公开仓库，向本身的公开仓库推送本身的修改，并为每一个人所见。贡献者能够持续地工做，而主仓库的维护者能够随时拉取贡献者的修改。贡献者没必要等待维护者处理完提交的更新，每一方均可以按照本身节奏工做 。

4、司令官与副官工做流程

司令官与副官工做流程是多仓库工做流程的变种，一般拥有数百位协做开发者的超大型项目才会使用，例如著名的Linux 内核项目。被称为副官(lieutenant)的各个集成管理者分别负责集成项目中的特定部分。全部副官还有一位上级称为司令官(dictator)的总集成管理者负责统筹。司令官维护的仓库做为参考仓库，为全部协做者提供须要拉取的项目代码。

司令官与副官工做流程以下：
A、普通开发者在本身的特性分支上工做，并根据司令官的master分支进行变基。
B、副官将普通开发者的特性分支合并到本身master分支中。
C、司令官将全部副官的master分支并入本身master分支中。
D、司令官将集成后的master分支推送到参考仓库中，以便全部其余开发者以此为基础进行变基。
司令官与副官工做流程并不经常使用，只有当项目极为庞杂或者须要多级别管理时才会体现出优点。利用司令官与副官工做流程，项目总负责人(司令官)能够把大量分散的集成工做委托给不一样小组负责人分别处理，而后在不一样时刻将大块的代码子集统筹起来，用于后续整合。