gitflow
目录
介绍 1
sourcetree演示gitflow使用： 3
1、日常开发使用步骤： 3
2、线上有bug紧急修复： 9
工作中使用经验： 11
建议： 11
介绍
the easy release management workflow
https://nvie.com/posts/a-successful-git-branching-model/ # 源自荷兰程序员Vincent Dressen的一篇博客A successful Git branching model
越往右距离线上环境越近，从右到左分别为：
master，线上，主分支，线上分支（线上的代码就是master的代码）；
hotfixes，线上，热补丁分支，负责线上紧急问题的修复；
release，预上线环境，预上线分支，在准备上线时先把代码放在这个分支提供给测试人员作上线前的最后一次测试；
develop，测试环境，开发分支，所有人基于这个分支进行开发，并基于这个分支进行功能分支的拉取；
feature，开发环境，功能分支，每当要新开发一个新功能的时候，从develop拉取一个新功能的分支，开发完成之后再合并到develop；
master和develop分支是常驻分支，最开始这2个分支内容是一样的；
sourcetree演示gitflow使用：
注：“仓库-->gitflow-->各种操作”，在新版本的右上角有快捷键“Git工作流”；
1、日常开发使用步骤：
仓库-->gitflow-->初始化仓库（本地要有master），初始化后本地会创建develop，并定位到develop；
此时在本地要开发v1.0，仓库-->gitflow-->下个操作，建立新的功能，功能名称（v1.0），确定，分支处出现feature/v1.0，并定位至v1.0；
此时进行代码编写，左上角“提交”；
此时feature/v1.0代码开发完毕，需合并至develop，仓库-->gitflow-->下个操作，完成当前项目，可以“删除分支”（也可以“保留分支”），确定，此时自动定位至develop；
此时需上线，需将develop分支打包至release分支，仓库-->gitflow-->下个操作，建立新的发布版本，发布版本号（v1.0），确定，此时分支处有release/v1.0；
此时release分支经测试通过，需正式上线，仓库-->gitflow-->下个操作，完成当前项目，以此消息打标签（1.0），勾选“推送变更到远程”，确定，本地分支自动定位至develop，在远端查看master代码有无变动；
2、线上有bug紧急修复：
仓库-->gitflow-->下个操作，建立新的修复补丁，修复补丁版本（hotfix_v1.1），确定，分支处有hotfix/hotfix_v1.1，
此时改代码，提交；
此时需将hotfix_v1.1合并至master和develop，仓库-->gitflow-->下个操作，完成当前项目，以此消息打标签（1.1），勾选“推送变更到远程”，确定，并在远端确认；
gitflow相关命令：
git checkout master # git checkout -b develop master
# feature branches
git checkout -b myfeature develop # create a feature branch
git checkout develop # incorporating a finished feature on develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop
# release branches
git checkout -b release-1.2 develop # create a release branch
git commit -a -m "test version number to 1.2"
git checkout master # finishing a release branch
git merge --no-ff release-1.2
git tag -a 1.2
git checkout develop
git merge --no-ff release-1.2
# hotfix branches
git checkout -b hotfix-1.2.1 master # creating the hotfix branch
git commit -a -m "test version number to 1.2.1"
git commit -m "fixed severe production problem"
git checkout master # finishing a hotfix branch
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1
工作中使用经验：
git分支和环境搭配起来才能称为开发流程，gitflow受欢迎的很重要原因是在这个模型中每个分支都独立对应了各自的环境：
feature --> develop --> release --> master；
开发环境-->测试环境-->预上线环境-->线上环境；
如果每个环境都经过严格测试，那么代码上线的bug率一定会变得很低；
gitflow是否能简化？gitflow是一套严格的开发模型，但不是每个细节都适用于每个团队，可按团队规模和实际情况进行裁剪：
如小团队通常会把release分支省略，预发布环境直接使用master；
更小的团队甚至预发布环境直接不存在；
有的团队测试资源丰富，要求测试人员介入到feature分支来测试；
所有调整的前提是必须深刻理解gitflow模型，且要知道你的调整对团队带来的好处和坏处；
建议：
1、保持develop分支和feature分支的同步，我们开发功能的时候需要从develop拉取feature分支，这个时候别人也在往develop分支合并代码，经常在最后合并develop时发现有很多冲突，解决冲突的工作量可能会占用你几个小时甚至更长的时间，所以要时刻保持develop分支和feature分支的差距不能太大，如果你的团队develop分支变动比较频繁，每天上班前把develop分支的代码合并到当前你开发的feature分支，这是一个很好的习惯，这样能保证最后把代码提交到develop时冲突基本已经解决了；
2、feature分支也要记得时刻提交代码，有的人觉得自己在feature分支只有自己在用，这是很不好的习惯，突发的事件可能有很多，一旦有突发事件，一天甚至几天的工作都会付诸东流，所以每天甚至一个小功能开发完成，提交代码到feature分支是个很好的习惯；