Git Flow 使用经验总结

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(支付相关功能，开发者李4、王五)。约定天天的同步代码任务：张三负责ft-login分支的更新，先从ft-mergepull代码到ft-login，解决冲突后merge回ft-merge。李四负责ft-pay，先让王五提交代码到ft-pay，而后从ft-mergepull代码到ft-pay，解决冲突后，而后merge回ft-merge。

项目成员及分工

成员	职责	开发分支
刘备	组长，git 分支管理	feature/ft-v20-merge，feature/hotfix-*
关羽	模块责任人，登陆注册	feature/ft-login
赵云	模块责任人，支付模块（支付宝渠道）开发，当前分支代码同步	feature/ft-pay
张飞	支付模块（微信渠道）开发	feature/ft-pay
魏延	支付模块（银联渠道）开发	feature/ft-pay
黄忠	支付模块（支付网关）开发	feature/ft-pay

协做流程

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表示组长或负责人），操做执行刘备相同的平常操做，等到发布版本前决定刘备主导合并。