Git Flow 使用经验总结

Git Flow 工作流目标

1. 规范分支的使用；
2. 处理线上版本修复和新版本开发并行的情况；
3. 降低开发过程中各成员的处理冲突及合并的成本；（本文针对的目标）

Git Flow 分支简介

master 分支

• master分支存放的是随时可供在生产环境中部署的稳定版本代码
• master分支保存官方发布版本历史，release tag标识不同的发布版本
• 一个项目只能有一个master分支
• 仅在发布新的可供部署的代码时才更新master分支上的代码
• 每次更新master，都需对master添加指定格式的tag，用于发布或回滚
• master分支是保护分支，不可直接push到远程仓master分支
• master分支代码只能被release分支或hotfix分支合并

develop 分支

• develop分支是保存当前最新开发成果的分支
• 一个项目只能有一个develop分支
• develop分支衍生出各个feature分支
• develop分支是保护分支，不可直接push到远程仓库develop分支
• develop分支不能与master分支直接交互

feature 分支

• 命名规则：feature/*
• develop分支的功能分支
• feature分支使用develop分支作为它们的父类分支
• 以功能为单位从develop拉一个feature分支
• 每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
• 当其中一个feature分支完成后，它会合并回develop分支
• 当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支
• feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
• feature分支只与develop分支交互，不能与master分支直接交互 　　 如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。

release 分支

• 命名规则：release/，“”以本次发布的版本号为标识
• release分支主要用来为发布新版的测试、修复做准备
• 当需要为发布新版做准备时，从develop衍生出一个release分支
• release分支可以从develop分支上指定commit派生出
• release分支测试通过后，合并到master分支并且给master标记一个版本号
• release分支一旦建立就将独立，不可再从其他分支pull代码
• 必须合并回develop分支和master分支

hotfix 分支

• 命名规则：hotfix/*
• hotfix分支用来快速给已发布产品修复bug或微调功能
• 只能从master分支指定tag版本衍生出来
• 一旦完成修复bug，必须合并回master分支和develop分支
• master被合并后，应该被标记一个新的版本号
• hotfix分支一旦建立就将独立，不可再从其他分支pull代码

SourceTree 工具功能简介

1. 将当前仓库自动初始化 git-flow 规范的结构；
2. 使用git-flow工作流“下一步”菜单进行工作流节点的创建及完结。

团队协作流程

举例说明
feature分支在开发团队中如何更好的工作

需求

1. 项目当前线上版本 v1.0，待修复bug：样式调整；
2. 项目计划下一个版本 v2.0，功能需求：注册登录、支付；
3. 项目需要并行任务：修复线上bug，开发新版本功能。

协作思路

为减少分支间合并代码时的差异，可以通过创建一个专门用来合并用的feature分支，比如ft-merge。其他成员按照自己划分的功能模块，建立对应的feature分支，根据比如ft-login(注册登录相关功能,开发者张三)、ft-pay(支付相关功能，开发者李四、王五)。约定每天的同步代码任务：张三负责ft-login分支的更新，先从ft-mergepull代码到ft-login，解决冲突后merge回ft-merge。李四负责ft-pay，先让王五提交代码到ft-pay，然后从ft-mergepull代码到ft-pay，解决冲突后，然后merge回ft-merge。

项目成员及分工

协作流程

1. 刘备初始化feature分支:

   • feature/ft-v20-merge
   • feature/ft-login
   • feature/ft-pay
2. 开发者关羽、张飞、赵云检出自己负责的分支;
3. 关羽每天上班时 pull ft-v20-merge 分支，下班时 merge 到 ft-v20-merge;
4. 张飞、魏延、黄忠每天上班时 pull ft-pay 分支，下班时 push (这里是 push) 到 ft-pay;
5. 赵云每天上班时 pull ft-v20-merge 分支，下班时 merge 到 ft-v20-merge;
6. 刘备每天上班时 检查 ft-v20-merge 分支分合并记录，同时review代码;
7. 刘备接到线上v1.0 的bug报告，需要修复一个样式问题， 通过SourceTree git-flow 工作流工具“新建修复补丁”，自动从master检出修复分支 hotfix/hf-style，进行代码修改，测试通过后完成 “修复补丁”生命周期，hf-style分支被合并回develop分支，并将develop分支合并到ft-v20-merge;
8. 关羽和赵云第二天上班时，同步代码，将刘备提交的bug修复内容合并到自己的 feature 分支。
9. 当v2.0版本提测前， 刘备确认各开发者代码全部提交，在ft-v20-merge构建提测版本。所有成员跟踪及修复测试bug，完成测试阶段。
10. 刘备通过 SourceTree git-flow 选项“完成功能”，将自动合并ft-v20-merge到develop。
11. 刘备通过 SourceTree git-flow 选项“新建版本”，将自动从develop检出release/r-v2.0（名称自己定义），对版本号等信息等作一些微调后，通过 SourceTree git-flow 选项“完成版本”，自动合并当前分支至master。

流程回放

1. 刘备作为开发组长，可以每天检查代码提交情况。
2. 关羽、赵云作为功能模块负责人，对合并给到刘备的ft-v20-merge代码负责。
3. 张飞、魏延、黄忠作为开发者，不用去关注自己分支和develop分支差异，只需关注每天pull时可能发生的冲突。
4. 刘备作为开发组长，负责线上BUG的修复，合并 hotfix 到 master ，发布修复版本，并将修复代码‘同步’给开发成员。

该流程的特点

1. 减少 feature 分支与 develop 分支交互的频次，从而降低冲突发生次数，普通开发者只需关注知己负责的分支；
2. 从各个feature-xxx分支直接merge回develop分支改为只由feature-v20-merge merge 回develop分支，develop 合并的质量可以更好地控制。
3. 理论上可以很好的支持跨团队协作的项目，例如增加曹操负责的开发队伍加入，只需增加ft-v20-merge-cc（cc表示组长或负责人），操作执行刘备相同的日常操作，等到发布版本前决定刘备主导合并。