你选择合适的git workflow了吗？

前言

之前和大家介绍过测试同学在工作工程中常用到的git命令，今天想和大家谈谈git workflow方式，同时基于项目实际情况，我们的最后选择。

工作流程重要性

工作流程规范会让大家感到束缚，但是大家还是都愿意遵守，因为大家知道一个真理：如果没有严谨规范的项目工作流程，无法成功创建一款优秀的产品。在使用git对项目版本进行管理，就需要了解git常用的工作流形式，并依据自己的实际情况选择适合的方式。 Git workflow常见的形式有：

• Centralized Workflow，集中式工作流
• Feature Branching Workflow，分支工作流
• Gitflow Workflow，Gitflow工作流
• Forking Workflow，ForKing工作流

Centralized Workflow

Centralized Workflow和subversion一样，将中央仓库作为项目中所有修改的唯一入口。和svn中的trunk不同，默认的开发分支叫做master，所有更改都被提交到这个分支。这种工作流不需要master之外的其它分支。开发过程快速简单。

优点：

• Centralized Workflow整体过程快速简单；
• 对于从SVN方式轻易过来的团队可以减少适应时间和成本；

缺点：

• 不熟悉的新手加入团队就可能是代码库频繁搞乱出现问题；

适用场景：

• 团队人数少
• 开发不是很频繁
• 团队沟通方便
• 不需同时维护多个版本

Feature Branching Workflow

Feature Branch Workflow和Centralized Workflow相比，在开发每个功能时都会重新创建一个独立的分支而不只是使用master分支。由于每个分支是独立且互不影响，任何推向master 分支的 feature-branch 都经过代码审核和验证。这就意味着主分支不会包含broken code，对持续集成环境是很有帮助的。

优点：

• 添加code review,代码质量有一定保障；
• 可以同时多个功能需求进行同步开发；
• 问题响应速度快捷；

缺点：

• 不利于配合团队工作，无法对分支分配分配明确的目的；

适用场景：

• 开发团队相对固定，而且有一定规模
• 多个功能，多个问题并行开发
• 对code review有较高要求
• 更注重团队效率

Gitflow Workflow

与Feature Branch Workflow比起来，Gitflow workflow并没有增加任何新的概念或命令。其特征在于为建立不同的分支并明确的角色，并且定义了使用场景和用法。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护。 这套工作流讲究的是平稳，有序，Git-flow工作流在 Git 分支标签等概念的基础上，添加了Feature，Release，Hotfix 等概念，用以精确描述代码版本控制的一些流程，所有协作者在放弃一些个人效率的基础上，统一开发流程，最终带来的是整体的规模化的团队的整体效率提升。

优点：

• 添加code review,代码质量有一定保障；
• 可以同时多个功能需求进行同步开发；
• 每个分支的角色更为明确；

缺点：

• 上手较难一点，需要一些基础知识培训；

适用场景：

• 接受额外学习Git-Flow的成本
• 有专门的代码仓库管理员
• 开发团队相对固定，而且有一定规模
• 常常有并行开发需求
• 团队对于Release，Bug，Feature这些概念有统一定义标准的

Forking Workflow

Forking Workflow与以上讨论的工作流很不同，一个很重要的区别就是它不只是多个开发共享一个远程仓库(central repository)，而是每个开发者都拥有一个独立的服务端仓库。也就是说每个contributor都有两个仓库：本地私有的仓库和远程共享的仓库。

优点：

• 任意开发者均可以参与项目，而不需要每个人都推送到单一的中央仓库。而管理者选择性的接受任何开发者的提交，却不需要给他们中央仓库的权限。

缺点：

• 对于职能分工明确且不对外开源的团队暂无很好的优势；

适用场景：

• 适用于开源项目
• 开发者有衍生出自己的衍生版的需求
• 开发者不固定，可能是任意一个自由开发者

我们的选择

上述不同的工作流方式各有利弊，大家可以根据项目实际的需要作出符合自己的选择。 以小编负责的其中两个项目为例： 项目一： server端新项目，开发人数2人，测试1人，完成开发上线后预测未来逻辑变更频率较低。负责的团队之前使用SVN进行版本控制。 我们的选择： 基于项目的现状和投入收益的考量，该项目我们采用CentralizedWorkflow的方式。 项目二： 内核相关项目，开发人数较多，工作流需要同时满足QA，shell层开发，内核开发，线上业务的需求，codereview执行规范，开发需求量大且团队成员均对git工作流程有熟练经验。 我们的选择： 基于项目业务的需求，我们采用Gitflow workflow的方式。同时将工作流尽可能的简化，提高核心工作的效率。在分支的管理上，我们建立三个分支：dev、beta和release，并明确相关的代码提交流程规范。工作流参考示意图如下：

备注：示例图参考rubygarage.org，项目二中dev,beta,release分支分别对应图中的development,release, master分支。

最后

基于项目实际情况，目前我们选择的工作流方式均符合我们当前的需求。在后期如果存在项目形态的变化，可以相应的调整变更工作流方式。