转载
GIT工作流简介
功能驱动开发
"功能驱动式开发"（Feature-driven development，简称FDD）.
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
如果我们开发的内容在功能的角度上就存在不相容,无法合并,则这种工作流未必合适.从项目设计上讲应该尽量避免这种情况的出现,否则,建议分割项目来解决.
Git flow(Git 工作流)
Git工作流比喻项目像流水一样顺畅自然的向前流动,不会发生冲击,对撞,甚至漩涡.
目前用的比较广泛的工作流有三种:
- Git flow
- Github flow
- Gitlab flow
针对目前的项目状况，本文采用的是最早诞生，并得到广泛应用的Git flow。
Git flow
首先，项目存在两个长期分支。
主分支master
开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在三种短期分支。
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）
一旦完成开发，它们就会被合并进develop或master，然后被删除。
主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
对应到目前团队中使用的Gitlab,我们建议使用Master作为主分支并设置分支保护（默认设置）,每次发布打上Tag,如: 0.1, 0.2或0.3
开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消),所以,当需要合并到Master的时候需要在Gitlab里提交合并申请,由项目管理员合并.
功能分支
功能分支属于临时性分支,一般合并完就会删除.
它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
比如我们正在开发分支中开发小宇睿联的需求,这个过程中来了5M微循环的迁移任务,这个时候,就可以从Develop分支中拉出一个5M的功能分支进行开发,避免两个需求开发重叠.
可能大家还会有疑问,开发分支里已经有一部分小宇睿联的内容,拉出来分支会不会有影响,这种情况可以评估下,如果存在冲突的话可以从Develop分支中向上回溯到一个合适的Commit拉出功能分支来.
某些情况下,新功能可能需要在线上的版本保持一致,可以从Master里拉出功能分支,也可以.
实际应用功能分支的时候,存在以下几种情况:
- 正常迭代,周期性的功能需求
- 产品型需求,这种需求的周期很长,需求和项目的主线有很大偏差,同时要求不跟着主板本迭代,如: 本地化部署
第一种情况,按照标准的feature分支工作流开展即可,不再赘述.
产品型需求
这种分支建议以production-分支定义,在功能迭代完成后直接在production-分支上拉出release分支提测,测试完成后,合并回production分支,同时在production分支上打上tag.
由于这种分支并不合并到主干,所以上线的代码都体现在production分支上,如果线上有bug需要修复,在tag上拉出fixbug分支修复即可.
这种分支实际上相当于一个独立的项目进行迭代,和本文阐述的分支管理主旨并不相符.
[图片来不及画]
预发布分支
它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支,合并完后删除分支。
它的命名，可以采用release-*的形式。
比如我们小宇睿联的需求已经开发完成了需要提测,这个时候我们可以从Develop中拉去一个预发布分支,提交测试.测试过程中出现了bug,就在这个分支里修复,当小宇睿联上线后,把分支合并回Develop,同时合并到Master分支,并在Master分支上打上Tag.
修补bug分支
软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
bug分支在提交的时候,如果存在release分支,需要同时合并到release分支,避免release分支上线的时候,合并到master有冲突.
Git合并的命令推荐
|
<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;"> git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
git push origin develop</pre>
|
默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将myfeature分支指向Develop分支。使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。
分支命名规范
<colgroup><col><col><col></colgroup>
| 分支类型 | 命名 | 说明 |
| 主干 | master |
|
| 开发分支 | develop |
|
| 功能分支 | feature-* | 使用禅道的需求编号(如果对应的需求编号过多,也可以使用拼音缩写) |
| 预发布分支 | release-* | 使用日期+版本号 , 如: 20181016-1.2 |
| bug分支 | fixbug-* hotfix-* | 使用禅道的bug工单号,或者根据当前tag版本号增加 |
| 产品分支 | production-* | 产品分支,对于独立进化的分支,如本地化部署 |
新平台开发场景指引
目前新平台开发场景大概有以下几种情形:
- 普通迭代
- 线上bug修复
- 功能提测
- 新的项目功能加入
针对这几种情形,我们依次给出指引
普通迭代
日常的迭代我们一般推荐在Develop下正常开发即可,提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支.如果,暂时不上生产则合并回Develop,暂时保留Release分支,等待发布到生产.
比如我们现在正在开发新能源迁移,这个时候并没有新的功能加入,我们只需要按照普通迭代开发即可.
线上bug修复
在Master分支里拉出bug-xxx分支修复bug,修复完成后提交测试,测试通过,分别合并到Develop和Master,再删除bug分支.
功能提测
提测的时候拉出Release-xxx分支提交测试,测试完了,如果需要上生产则分别合并到Develop和Master,同时在Master上打上Tag(Tag-x.x.x)标记,删除Release分支
新的项目功能加入
普通迭代过程中收到了新的需求开发,为了不造成影响,在Develop分支里拉出Feature分支开发功能需求,开发完成后,合并到Develop.提测的时候,在Develop中拉出Release-xxx分支提交测试,测试完毕参照功能提测.
常见问题
5M微循环作为一个独立分支,是面对客户独立部署,将来可能不希望跟着正常迭代走,在分支上该如何管理?
这种情况,由于存在两个线上环境,实际上等于存在两个Master分支,其中一个是5M的分支,它最终也会作为一个长期分支存在,后续的功能开发,或者Bug修复都在这个分支上拉出功能分支来进行,完成测试后再合并回5M的分支,这个工作流有点像Github flow(详见参考文档).
正常迭代过程中修复了一个bug可能涉及到其他功能分支,如何处理?
保险起见,最好在不同的分支里分别提交,这样做不可避免的会带来一些麻烦,所以,我们在项目的迭代周期上,一定不要太长,否则遗留的功能/测试分支太多,会给开发人员的开发带来麻烦.
新的功能开发完成提交了Release分支,如何保证旧的功能不会收新功能影响?
这个问题本质上并不是工作流的问题,这里也拿出来讲一下,解决这个问题,还是需要从测试着手,而测试分为两块,白盒测试和黑盒测试.对于开发人员,项目中开发的功能都需要有单元测试能够覆盖到,当新的功能开发完成后,完整的执行一遍单元测试,可以检查对旧功能是否造成影响.同样测试人员也会针对上线功能进行完成测试.
新能源迁移的功能分支,由于短期内无法上线,这些分支在测试完后,如何处理?
这些分支在功能开发完成后,就合并到了Develop分支了,提测生成的测试分支,由于暂时无法上线,暂时不要合并到主干,可以先合并回Develop分支.
新能源功能已经开发完成了,这个时候合并到了Develop,这个时候小宇睿联的又有新的需求需要开发,由于新能源短期内无法上线,目前线上的环境是小宇睿联的功能,如何处理?
这种情况,建议从Master里拉出Bug分支进行开发,流程参考Fix-bug.
Github flow工作流简介
Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
流程
它只有一个长期分支，就是master，因此用起来非常简单。
官方推荐的流程如下。
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
扩展讨论
- 如何将现有代码切换过来
- 如何培训推广
GEMINI修改分支样例
迁移前分支状况
master 最新迭代分支
pro 生产环境分支
fat 测试环境分支
5m 5米微循环分支
迁移计划
1.从master新建一个develop分支
|
<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git checkout master
git checkout -b develop</pre>
|
2.把master分支重置到pro分支的分叉处,我的项目里查到的分叉处commit为 af8ac1ef66f3e2c932623eecd71296e19a2c2e9c
|
<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">git.exe reset --hard af8ac1ef66f3e2c932623eecd71296e19a2c2e9c
git.exe merge remotes/origin/pro</pre>
|
最终达到的效果:
- master分支指向到了origin/pro
- develop分支指向到了最新代码
