Git工作流

Git工作流概述

什么是Git工作流？你可以理解为代码管理的分支策略，它不仅仅是版本管理范畴，更服务于项目流程管理和团队协同开发。所以，有必要制定适合自己研发场景的工作流。

下面介绍四种工作流的工作方式、优缺点，以及使用中的一些注意事项。

• 集中式工作流
• 功能分支工作流
• Gitflow工作流
• Forking工作流

研发团队可以根据实际研发场景制定合理的工作流，能有效提高项目管理水平和团队协同开发能力， 并通过代码管理平台，高效、安全的管理代码资产，将更多的精力集中在业务开发上，实现持续集成、持续交付和快速迭代的目标。

集中式工作流

集中式工作流适合5人左右小开发团队，或是刚从SVN工具转型为Git的团队，它只有一个默认的maste分支（相当于svn的trunk主分支），所有人的修改都是在master分支上进行的。但是，这种工作流无法充分发挥git优势和多人协同，不推荐使用。

工作方式

开发人员将master分支从中央仓库克隆到本地，修改完成后再推送回中央仓库master分支。

优点

不涉及分支交互操作。

缺点

• 不适合人员较多的团队，当人员10+时，解决开发人员之间的代码冲突会耗费很多时间。
• master分支提交频繁。
• master分支不稳定，不利于集成测试。

Tips：如何尽量避免产生冲突和不合理的提交历史？

开发人员在开发一个新功能之前，一定要在本地同步中央仓库最新代码，使自己的工作基于最新的代码之上；开发完成后，在提交新功能到中央仓库前，需要先fetch中央库的新增提交，并rebase自己的提交。这样做的目的是，把自己的修改加到中央仓别人已经提交的修改之上，使最终的提交记录是一个完美的线性历史，而不是环形，工作流举例如下图所示。

img

1. 开发人员A和开发人员B同时在某个时间拉取了中央仓库的代码。
2. 开发人员A先完成了自己的工作，并提交到中央仓库。
3. 开发人员B需要在本地执行git pull –rebase中央仓库的新提交，这时开发人员B的本地仓库就包含了开发人员A修改的内容，并在A的基础上增加了自己的修改。
4. 开发人员B将代码推送到中央仓库。

功能分支工作流

通过新建几个功能分支，增加开发者的交流和协作，它的理念是所有的功能开发都应该在master分支外的一个独立分支进行，这种方式隔离了开发者的工作空间不被互相干扰，保证了master分支的稳定性。

工作方式

开发人员每次在开始新功能开发前，需要在master分支上拉取一个新分支，并起个有描述性的名字，比如video-output或issue-#1061，这样可以让分支用途明确。功能分支不但存在开发人员本地仓库，也应该推送到中央仓库，这样就可以在代码不合入master分支的情况下与其他开发人员分享代码。

优点

• 分支合并前可以使用pull request进行code review。
• 降低了master分支的提交频率。

缺点

只有一个master分支作为集成，仍然不是很稳定，不适合大型开发。

Gitflow工作流

Gitflow一般用于管理大型项目，它为不同的分支分配一个很明确的工作角色，并定义分支之间什么时候进行交互，如Gitflow工作流如下图所示。

点击放大

工作方式

• master分支：

  生产分支，最稳定的版本，一直是ready to deploy状态。不接受开发人员直接commit，只接受从其他分支merge操作。在很多企业中，这个分支被默认开启分支保护，只有维护者可以操作。

• hotfix分支：

  从master分支拉取的临时修复分支，用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号，这个修改也需要同时合入develop分支。

• develop分支：

  从master分支拉取的开发分支，用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。

• release分支：

  临近既定的发布日，就从develop分支上拉取一个release分支，任何不在当前分支中的新功能都推到下个发布中。release分支用于发布，所以从当前时间点之后新的功能不能再加到这个分支上，这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了，release分支合并到master分支并分配一个版本号打好Tag；另外，这些从release分支新做的修改要反向合并回develop分支。

• feature分支：

  开发者使用的特性分支，父分支是develop分支，当新功能完成时，合入develop分支。新功能提交从不直接与master分支交互。

开发人员提交新功能的两种途径：

• 团队有专人review审核新功能
  1. 开发人员将feature分支推送到代码托管平台（中央仓库）。
  2. 发起一个从feature分支合并到develop分支的合并请求，并指给review专员。
  3. review专员审核。如果通过，将feature分支的新功能合并到develop分支，并删除feature分支；如果未通过，拒绝该请求并注明拒绝原因。
• 开发人员自审核新功能
  1. 开发人员在本地仓库将feature分支合并到develop分支，并删除feature分支。
  2. 将本地develop分支的修改推送到软件开发云代码托管平台（中央仓库）。

优点

• 使用一个用于发布准备的专门分支（release分支），使得一个团队可以在完善当前的发布版本的同时，可以在develop分支并行继续开发下个版本的功能。这也打造了可视化的发布阶段，团队成员都可以在仓库网状结构中可以看到发布状态。
• 使用紧急修复分支（hotfix分支）让团队可以处理紧急问题的同时而不打断其它工作或是等待下一个发布再合入hotfix修改。我们可以把hotfix分支想成是一个直接在master分支上处理的临时发布。
• 大型项目人员协作频繁，流程较多，合理的多角色分支帮助研发有条不紊进行。
• 更符合devops理念。

缺点

• 学习成本较高。
• 如果团队不遵守使用约定，带来的影响更大。

Forking工作流

Forking工作流区别于前三种工作流的最大特点是每个开发人员都有一个从公共仓库fork出来的属于自己的公共仓。Forking工作流适合外包、众包以及众创和开源场景。接包方的开发人员从项目公共仓fork自己的公共仓库进行操作，并不需要被项目公共仓直接授权，Forking工作流如下图所示。

点击放大

工作方式

1. 将“项目公共仓”fork出一个“个人公共仓”。
2. 将“个人公共仓”clone到“本地仓库”。
3. 操作“本地仓库”，修改完成后提交到“个人公共仓”。
4. 为“个人公共仓”提交一个pull request给项目维护者，申请代码合入“项目公共仓”。
5. 项目维护者在本地review、验证本地提交，审核通过后push进入“项目公共仓”。

优点

• 开发人员之间若需要代码协作，可以直接从其他人的“个人公共仓”拉取，无需等到代码提交到项目公共仓。
• “项目公共仓”无需为每个代码贡献者授权。
• 项目维护者通过审核pull request成为代码安全的重要防线。
• 仓库分支的选择可以根据项目实际情况综合使用前三种工作流。

缺点

提交开发人员代码到最终版本库的周期较长，步骤繁琐。

文章参考华为云
https://support.huaweicloud.com/bestpractice-codehub/codehub_practice_1005.html