首先感谢这位大神-mcgrady,博客基本上是copy这位大神的。
Git-flow流程图
git flow是Vincent Driessen提出了一个分支管理的策略,非常值得借鉴。它可以使得版本库的演进保持简洁,主干清晰,各个分支各司其职、井井有条。
先看下Vincent Driessen提出的分支管理模型图,以便对git flow有个大概的了解。
中文版的git-flow流程图
此流程图是自己画的(英文的翻译版)
流程图说明:
1. 开始是一个主分支maser
2. 拉取一个开分支develop(简称dev),优化、修改等
3. 一旦线上版本有了紧急bug,拉取一个热补丁分支(hotfix),解决bug
① 合并到主分支master
② 打一个tag
③ 合并到开发分支dev
④ 删除hotfix分支
4. 一旦有了新的需求
① 从开发分支拉取一个feature特征分支
② 需求做完,合并到开发分支dev,然后删除feature分支
③ 从develop拉取一个发布分支release,用于修改测试测出来的bug
④ 在release修改bug的同时,每次提交要相应的合并到dev分支
⑤ 关键点: 此时如果又有新的需求怎么办? (正在修第一个需求的bug,还未发布,新需求又来了)
1. 先要将release分支合并到dev分支
2. 然后再从dev分支拉取一个feature分支(之前的那个feature分支早删除了)
3. 在新的feature分支进行新需求的开发
⑥ release分支测试通过
1. 合并到分支master
2. 打一个tag
3. 合并到开发分支dev
4. 删除release分支
在此流程图中未说明如果在1.0版本发布上线之前,出现一个紧急版本0.3该怎么处理?
在feature_1X分支进行开发,开发完成后,直接从feature_1X分支打release_0.3版本,测试通过后,合并到master分支tag3.0,和dev分支。
两种核心分支
主分支(Master):代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。这个分支只能从其它分支合并,不能在这个分支上直接修改。需要注意的是,所有在master上的提交应该标记tag。
开发主分支(Develop):这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支。该分支应该只是进行一些优化和升级开发,如果有新的需求应该拉出一个feature分支。
三种临时分支
功能(feature)分支:这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release。
预发布(release)分支:当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到Master和Develop分支。
修补bug(hotfix)分支:当我们在Production发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release。
Git Flow工具
- SourceTree (目前自己公司使用这个)
- GitFlow for Visual Studio
分支命名规范
- feature分支:以”feature_“开头,如feature_v1.1
- release分支:以”release_“开头,如release_v1.1
- hotfix分支:以”hotfix_“开头,如hotfix_20160112
- tag标记:如果是release分支合并,则以"release_"开头。如果是hotfix分支合并,则以”hotfix_“开头。
- master分支每次提交都要打tag,release tag:如release_v1.1,hotfix tag:如hotfix_20160112
- 命名都统一采用小写。
总结
- 一定要按git flow的流程去管理分支,如feature分支开发完要合并到develop,如果要发布版本到test环境,则从develop拉出一个release分支,release完成后要合并回master和develop分支,修复生产环境问题需要从master拉出一个hotfix分支,hotfix完成后要合并回master和develop分支,并且在master打上tag。
- 一定要按分支命名规范来命名,便于管理和维护。
- 了解了git flow工作流程后,可以不使用git flow GUI工具,手动操作即可,可以是原生git命令+vs配合操作,比如给master打tag就要用git命令,这在vs里操作不了的,比如合并分支,虽然也可以使用git命令实现,但在vs里操作更方便直观。
- 一定要保持分支的纯净,不要随便污染分支。比如,develop分支只包含要发布到下一个release的代码,在没有拉出release分支前不要合并新的feature分支进来。release分支基于develop分支创建,拉出release分支后,我们可以在这个release分支上测试和修复bug,但是,一旦打了release分支后不要从develop分支合并新的改动过来。develop拉出release分支的同时,也意味着develop分支可以开始下一个release的准备工作了。
- 如果多个版本并行到test环境,怎么解决这个问题?如下图。