工作流简介

功能驱动开发

"功能驱动式开发"（Feature-driven development，简称FDD）.

它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。

如果我们开发的内容在功能的角度上就存在不相容，无法合并，则这种工作流未必合适。从项目设计上讲应该尽量避免这种情况的出现，否则，建议分割项目来解决。

Git flow(Git 工作流)

Git工作流比喻项目像流水一样顺畅自然的向前流动,不会发生冲击，对撞，甚至漩涡。

image.png

目前用的比较广泛的工作流有三种:

• Git flow
• Github flow
• Gitlab flow

针对目前的项目状况，本文采用的是最早诞生，并得到广泛应用的Git flow和功能驱动开发（FDD）以及带问题追踪的功能分支管理的GitLab flow结合。

Git flow

首先，项目存在两个长期分支。

主分支master
开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

image.png

其次，项目存在三种短期分支。

功能分支（feature branch）
补丁分支（hotfix branch）
预发布分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。

GIT Flow总览

image.png

主分支Master

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

对应到目前团队中使用的Gitlab,我们建议使用Master作为主分支并设置分支保护（默认设置）,每次发布打上Tag,如: 0.1, 0.2或0.3

image.png

开发分支Develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

image.png

如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消),所以,当需要合并到Master的时候需要在Gitlab里提交合并申请,由项目管理员合并.

功能分支Feature

功能分支属于临时性分支,一般合并完就会删除.

它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。

某些情况下,新功能可能需要在线上的版本保持一致,可以从Master里拉出功能分支,也可以.

image.png

实际应用功能分支的时候,存在以下几种情况:

1、正常迭代,周期性的功能需求
2、公共模块更新，所有feature分支都需要同步更新
3、产品型需求,这种需求的周期很长，需求和项目的主线有很大偏差，同时要求不跟着主板本迭代

第一种情况，按照标准的feature分支工作流开展即可,不再赘述。

第二种情况，需要分别关注两种情况的处理。
1、作为公共模块更新提交者，在本地分支commit后，不在develop分支需要切换到develop分支并pull request，然后修改公共模块，最后提交到remote（单次commit的代码只能包含修改公共模块的代码，不能包含UI、其他feature分支代码）。
2、作为公共模块拉取者，在本地分支commit后，fetch更新remote提交记录，然后cherry-pick对应的commit记录。

image.png

image.png

产品型需求

这种分支建议以production-分支定义,在功能迭代完成后直接在production-分支上拉出release分支提测,测试完成后,合并回production分支,同时在production分支上打上tag.

由于这种分支并不合并到主干,所以上线的代码都体现在production分支上,如果线上有bug需要修复,在tag上拉出fixbug分支修复即可.

这种分支实际上相当于一个独立的项目进行迭代,和本文阐述的分支管理主旨并不相符.

预发布分支

它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支,合并完后删除分支。

它的命名，可以采用release-*的形式。

hotfix分支

软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修复。

hotfix分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用hotfix-*的形式。

image.png

hotfix分支在提交的时候,如果存在release分支,需要同时合并到release分支,避免release分支上线的时候,合并到master有冲突.

分支命名规范

受保护的分支

默认情况下，受保护的分支执行以下四个简单的操作：

• 它会阻止除具有“主”权限的用户之外的所有用户创建（如果尚未创建）
• 它可以防止除具有“主”权限的用户以外的其他任何人推送
• 它可以防止任何人强制推送分支
• 它阻止任何人删除分支

版本迭代管理

为了适应高速迭代开发节奏，我们会以一个月两个版本迭代开发，每个版本需要安排主程序员和开发人员，在单次版本开发中，主程序员的职责是统筹开发人员，负责主要开发任务，收集bug并反馈到开发人员手里，以及feature分支合并申请审核。而开发人员只需要完成开发任务和bug修复。下一个版本主程序员和开发人员轮换。

扩展讨论

如何将现有的工作流切换过来？

若手头还有工作，需要在你当前分支处理的话，可以按照以前的工作流提交你的代码，并且提交完代码后，需要每一位开发者同步一下代码，之后按照功能驱动式开发即可。

参考文档

Git工作流程

A successful Git branching model

Understanding the GitHub flow

GitHub Flow