设计一个git工作流

分支结构

首先基于 master 分支创建 release 分支，fixbug 分支，以及 feature-* 分支（该分支是否创建视情况而定），然后基于 release 分支创建 dev 分支。

工作流程

开发阶段将在 dev 分支上进行。

开发完进入测试阶段，需要将 dev 分支合并到 release 分支。

测试阶段将在 release 分支上进行。日常打测试包也将在该分支上进行。

测试结束后进入预上线阶段，需要将 release 代码合并到 master 分支，并打上版本 tag。

预发布阶段，打发布包将在 master 上进行，并准备发布。（对于iOS应用来说，预发布阶段也就是提交应用并等待苹果审核阶段）

在预发布阶段如果发现漏测的bug需要修复，则删除刚才的版本 tag，将 master 分支代码合并到 fixbug 分支，并在该分支上进行bug修复。bug修复之后打测试包也在这个分支上进行。测试通过之后，将 fixbug 代码合并到 master 分支，并打上版本 tag，重新进入预发布阶段。

如果一切OK，则上线应用进入发布阶段。

发布阶段如果发现bug，对于iOS来说，一般情况下需要发一个小版本。这个时候需要将 master 分支代码合并到 fixbug 分支，并在该分支上进行bug修复。bug修复之后打测试包也在这个分支上进行。测试通过之后，将 fixbug 代码合并到 master 分支，并打上版本 tag，进入预发布阶段。

Feature分支

如果有独立于当前正在进行版本的新需求需要开发，假如这个新需求叫“合规”，则基于 master 分支或者某一个版本tag创建一个 feature-hegui 分支（注意命名规范）。这个分支非常类似于 fixbug 分支，开发、测试和日常打包都在同一个分支上进行。

分支状态说明

测试阶段，release 分支处于活跃状态，只能接受来自 master 分支的合并，不能接受 dev 分支和其他分支的合并。

预发布阶段，master 分支处于活跃状态，不能接受任何分支的合并。

如果 fixbug 分支处于活跃状态，则 master 分支被锁定，一般只能接受来自 fixbug 分支的合并。

权限管理和代码审核

master、release、fixbug、dev 以及 feature-* 分支对任何人都不开放 push 权限，但是对主程序员（Masters）有 merge 权限。

所以不能直接向这些分支 push 代码，首先需要创建一个临时的远程分支如：dev-xxx（xxx为名字缩写，注意分支命名规范），然后创建 merge request，指定一个小组成员进行代码审核。需要注意的是，这个临时的远程分支在 merge 成功之后可能会被删除。

特别说明

在预发布阶段，dev 分支上可能正在进行一个版本的开发，release 分支上可能正在进行另一个版本的测试，fixbug 分支上可能正在进行对当前预发布版本或者线上版本的bug修复。

如果不考虑 feature 分支，一般情况下会有两个版本同时进行：一个正在测试或者等待发布，另一个正在开发；或者一个正在等待发布，另一个正在开发或者测试。

比较极端的情况，可能会有三个版本同时进行：一个正在等待发布，一个正在测试，还有一个正在开发。

如果考虑 feature 分支，则可以并行开发更多的版本，当然这种情况非常少见。

可以看到，这种工作流设计能容纳多个版本并行开发，并且有很强的扩展性。

注意事项

每次打包测试之前，下层分支需要拉取上层分支的代码进行合并，从而保证下层分支是基于上层分支的最新代码进行开发，这样可以避免漏测，也可以避免最后一次性合并引入过多的冲突代码。

比如，当一个版本正在 release 分支上进行开发，另一个版本正在 fixbug 分支上修复预发布阶段或者线上版本的bug，bug修复之后，fixbug 分支上的代码会合并到 master 分支。在 release 分支上打包之前，就需要先拉取 master 分支上的最新代码，和 release 分支进行合并。