Gitlab flow

简介

我们的工作流工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。

长期分支

相对使用仅有的一个master分支，我们的工作流使用2个分支来记录项目的历史。online分支存储了正式发布的历史，而master分支作为功能的集成分支。这样也方便online分支上的所有提交分配一个版本号。

online分支

online分支作为上线分支, 包含了正式发布的全部代码, 其中, 每次上线都会标记上以版本号命名的tag.

master分支

master分支作为功能集成分支, 包含了全部开发完毕的最新代码.

功能分支

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出新分支，而是使用online分支作为父分支。当新功能完成时，在功能分支本身完成基础的测试工作，测试通过后合并到master分支，在master分支上，完成模拟线上环境测试的工作。注意：测试分为基础功能测试以及模拟线上环境测试两个步骤，在完成每个步骤之前，不应该将代码pull到其他分支。当两轮测试完成后，功能分支上的代码再被同步到online分支上，完成最终部署。

维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从online分支fork出来的分支。修复完成，修改应该马上合并回online分支和master分支（当前的发布分支），online分支应该用新的版本号打好Tag。

为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把维护分支想成是一个直接在online分支上处理的临时功能。

一些约定

用于新建发布分支的分支: master
用于合并的分支: online
开发分支命名: feature/*
维护分支命名: hotfix/*

示例

下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。

创建开发分支

第一步为master分支配套一个online分支。简单来做可以本地创建一个空的online分支，push到服务器上：

1
2

git branch online
git push -u origin online

以后这个分支将会包含了项目的发布历史，而master分支将则包含了全部历史。其它开发者这时应该克隆中央仓库，建好online分支的跟踪分支：

1
2

git clone ssh://user@host/path/to/repo.git
git checkout -b online origin/online

现在每个开发都有了这些历史分支的本地拷贝。

开发小红和开发小明开始开发新功能

这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于online分支：

git checkout -b some-feature online

他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：
git status
git add
git commit

开发小红完成功能开发，测试小黑指定测试计划并介入测试

添加了提交后，小红觉得她的功能OK了，这个时候，她通知了测试小黑，小黑和她讨论完测试范围后，制定了测试计划，之后小红将她的代码推送到中央仓库，中央仓库通过CI系统发布到功能测试环境，小黑在这个环境中完成功能测试，功能测试，提交bug等。同样，小红也在这个分支上做相应的bugfix。

1
2

git pull origin some-feature
git push

测试小黑完成测试全部流程，开发小红修复全部的bug

如果团队使用Pull Requests，这时候可以发起一个用于合并到master分支。否则她可以直接合并到她本地的master分支后push到中央仓库：

1
2
3
4

git pull origin master
git checkout master
git merge some-feature
git push

第一条命令在合并功能前确保master分支是最新的。注意，功能决不应该直接合并到online分支。冲突解决方法和集中式工作流一样。

产品小汪评估上线时间，指定上线计划并完成模拟线上环境测试

这个时候小明正在实现他的功能，小红将master上的代码部署到模拟线上环境，同样，小黑需要在这个环境中完成最后的待上线测试流程，在这个阶段中，bug的修复流程是先提交到some-feature分支上，然后再发起Pull Request到master分支上，小黑在master上完成bug的验证。

开发小红完成发布

一旦准备好了对外发布，小红将some-feature的代码合并到online上，并删除功能分支。另外，如果小红的团队要求Code Review，这是一个发起Pull Request的理想时机。

1
2
3
4

git checkout online
git merge some-feature
git push
git branch -d some-feature

只要有合并到online分支，就应该打好Tag以方便跟踪。

1
2

git tag -a 0.1 -m "Initial public release" online
git push --tags

Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。可以配置一个勾子，在你push中央仓库的master分支时，自动构建好对外发布。

最终用户小作发现Bug

对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有最终用户开了一个Ticket抱怨当前版本的一个Bug。为了处理Bug，小红（或小明）从online分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回online分支：

1
2
3
4
5
6
7

git checkout -b issue-#001 online

Fix the bug

git checkout online
git merge issue-#001
git push

就像发布分支，维护分支中新加这些重要修改需要包含到master分支中，所以小红要执行一个合并操作。然后就可以安全地删除这个分支了：

1
2
3
4

git checkout master
git merge issue-#001
git push
git branch -d issue-#001