Git Flow
在使用 Git 的过程中如果没有清晰流程和规划,否则,每个人都提交一堆杂乱无章的 commit,项
目很快就会变得难以协调和维护。
Git 版本管理同样需要一个清晰的流程和规范,Vincent Driessen 为了解决这个问题提出了 A
Successful Git Branching Model
Git Flow 流程图:
分支管理规范
- master/develop 分支:所有在 master 分支上的 Commit 应该打上 Tag,一般情况下 master 不存在 Commit
- develop 分支:develop 分支基于 master 分支创建,feature 分支做完后,必须合并回 develop 分支。由develop再合并到master分支
- test 分支:测试环境分支代码,功能开发完成后部署测试,需要定期从master上进行代码同步
- feature 分支:feature 分支做完后,必须合并回 develop 分支, 合并完分支后一般会删点这个 feature 分支,在需求有依赖的前提下,feature分支可以基于其他需求的feature分支创建
- hotfix 分支:hotfix 分支基于 master 分支创建,hotfix分支也是一个feature分支,只不过可以直接合并到master,开发完后需要合并回 master ,同时在master 上打一个 tag。如果没有合并到develop 分支,则需要将master和develop代码同步
代码开发
- 每位开发人员认领自己的功能需求,分别从 master 分支拉取自己个人分支进行功能编码。敏捷开发强调功能小版本迭代,并行开发。
- 当研发人员每个 feature 分支完成,开发自测和测试人员完成测试之后,提交 merge request,team leader 经过 code review 确定运行无缺陷后合并到 develop 分支。
- 此时测试人员需要从 develop 分支打包最新代码,并部署集成测试环境,同步进行功能、接口测试与其他系统的交互测试。
分支代码管理
- master 分支的每一次更新,都建议打 tag 添加标签,通常为对应版本号,便于管理
- feature分支、hotfix分支在合并后可以删除,避免分支过多管理混乱
- 每次 pull 代码前,提交本地代码到本地库中,否则可能回出现合并代码出错,导致代码丢失
冲突的场景及解决方案如下
- 多 feature 分支并行开发,在提交测试合并至 develop 分支时,容易出现合并冲突。这就要求各研发人员尽量只修改个人功能代码文件。公共配置或公共依赖包应由单独开发人员维护,按需添加,修改合并后推送到各 feature 分支。
- Hotfix 分支修复的同时有 release 分支功能需要发版上线,合并 master 时容易出现合并冲突。这时按功能生产环境紧急性依次发布上线,发版上线后立即合并 master 并合并到develop分支