Git-flow 工作流使用

背景

要解决的问题：
疯狂的分支合并操作

两个开发分支和一个master分支之间相互merge代码，易产生代码冲突、代码覆盖，导致生产环境上出现bug。

解决的问题

1.让现有的分支命名更加规范。
2.让每个分支的作用更加明确
3.减少代码合并的冲突，代码覆盖，导致生产环境产生bug

什么是Gitflow

Gitflow 工作流定义了一个围绕项目发布的严格分支模型。体现了工作流的经验和精髓。随着项目过程复杂化，会感受到这个工作流中深思熟虑和威力！Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。
优点是清晰可控，使多人项目协作开发更加规范；
缺点是相对复杂，需要同时维护两个长期分支。

两种核心分支

主分支(Master)：代码库有且仅有一个主分支。用于部署生产环境的分支，需确保master分支稳定性master分支存储了正式发布的历史属于只读唯一分支，新功能提交应该从不直接与master分支交互，只能从其它分支（如develop，hotfix）合并，不能在这个分支上直接修改。需要注意的是，所有在master上的提交应该标记tag。方便追溯
开发主分支(Develop)：基于master分支检出的平行分支develop分支始终保持最新完成以及bug修复后的代码属于只读唯一分支，只能从master以外的分支（如feature，hotfix）合并，不能直接在此修改。如果有新的需求应该拉出一个feature分支。

三种临时（辅助）分支

预发布(release)分支：基于develop分支检出，这个分支由测试开发等同学共同参与。该分支只能做一些优化，Bug测试及修复，文档生成和其它面向发布任务的临时分支。完成Release后，最终会先被合并到master（发布新版本），打TAG标签，再被合并到develop，最后可选删除命名规则：推荐为release
补丁分支(hotfix)分支：，基于master分支检出，用于对线上发布的版本进行BUG修复。我们需要创建一个Hotfix, 属于临时分支，完成Hotfix后，我们合并回Master和Develop分支。打TAG标签，可选删除。命名规则：推荐为hotfix-或hotfix/，如hotfix-1.0.1

功能(feature)分支：这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有master和develop。

分支发布

一旦develop分支上有了做一次发布的足够功能或者说快到了既定的发布日，就从develop分支上fork一个发布分支（Release）。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。(最后再删除Release分支)
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段

Git Flow流程示例代码

1，创建develop分支
#从master拉出develop分支
#可选，获取最新版本。git pull origin master
git checkout -b develop master
#发布develop分支
git push -u origin develop
2，创建feature分支
#从develop拉出feature_v1.0功能分支
#可选，获取最新版本。git pull origin develop
git checkout -b feature_v1.0 develop
#发布feature_v1.0分支
git push -u origin feature_v1.0
#在feature_v1.0上开发一些功能
3，完成feature，合并到develop分支
#develop分支获取最新
git pull origin develop
#切换到develop分支
git checkout develop
#从feature分支合并到develop分支
git merge --no-ff feature_v1.0
#删除feature分支，也可以不删除
git branch -d feature_v1.0
4，开始release
#从develop拉出一个release分支
#可选，获取最新版本。git pull origin develop
git checkout -b release_v1.0 develop
#fix bugs
5，完成release，合并到master分支和develop分支，在master打上tag标记
#合并到master
git checkout master
git merge --no-ff release_v1.0
#在master打tag标记
git tag release1.0 master
git push --tags
#合并到develop
git checkout develop
git merge --no-ff release_v1.0
6，开始hotfix
#从主线master拉出一个hotfix分支
#可选，获取最新版本。git pull origin master
git checkout -b hotfix_v1.0.1 master
7，完成hotfix，合并到master和develop，并在master上打tag。
#合并hotfix_v1.0.1到master
git checkout master
git merge --no-ff hotfix_v1.0.1
#在master打上tag
git tag hotfix1.0.1 master
git push --tags
#合并hotfix_v1.0.1到develop
git checkout develop
git merge --no-ff hotfix_v1.0.1

Git Flow工具

SourceTree
Tower

使用SourceTree创建工作流

切到develop分支。点击git工作流，选择建立新的功能

输入功能名（特性分支名）点击确定即可

如果下图，我们就创建好了featrue。并从develop分支切到了feature。至此用sourcetree工具就创建好了一个feature支。我们就可以在这个分支上愉快的开发了。

使用Tower创建工作流

1，点击菜单栏上的git-flow —->configure git-flow在弹出图中直接点击configure按钮即可
2，再次点击菜单栏上的git-flow按钮弹出如下图。选择start feature

输入特性分支名feature_1 点击start feature即可

如下图，最终我们用sourcetree创建的feature 和tower创建的feature_1都已创建。

分支命名规范
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
命名都统一采用小写。

合并代码
merge这里不展开详细讲解，简要讲解一下rebase 使用
rebase 和 merge 的基本原则：
1下游分支更新上游分支内容的时候使用 rebase
2上游分支合并下游分支内容的时候使用 merge
3更新当前分支的内容时一定要使用 –rebase 参数
例如现有上游分支 master，基于 master 分支拉出来一个开发分支 develop，在 develop 上开发了一段时间后要把 master 分支提交的新内容更新到 develop 分支。此时切换到 develop 分支，使用 git rebase master等 develop分支开发完成了之后，要合并到上游分支 master 上的时候，切换到 master 分支，使用 git merge develop 。
feature分支和并develop分支也同样应该如此操作。下面给出Git Flow工具演示。

Tower使用。

feature_1分支和并develop分支，切到feature_1分支，选中develo分.点击菜单栏上的Rebase按钮即可

注意:

不要在公共分支使用rebase（如在master分支上rebase develop分支的代码，或rebase分支featrue的代码）
本地和远端对应同一条分支,优先使用rebase,而不是merge

抛出问题:

为什么不要再公共分支使用rebase?
因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再 rebase,相当于你 rebase 东西进来，就都是新的 commit 了
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行变基操作。
因为不管是git rebase 还是git rebase ,都重置了提交的SHA-1校验和，当你将本地变基后的提交推送到远端后，别人从服务器同步代码时，由于相同的内容却有不同的SHA-1校验值，因此会再此进行一次合并，于是就会有两个作者、commit信息完全相同的提交，但是SHA-1校验值不同，这无疑会带来麻烦。
因此，如果把变基当成一种在推送之前清理提交历史的手段，而且仅仅变基那些尚未公开的提交对象，就没问题。如果变基那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。

合并多次commit操作:

1 git rebase -i develop
2 修改最后几次commit记录中的pick 为squash
3 保存退出,弹出修改文件,修改commit记录再次保存退出(删除多余的change-id 只保留一个)
4 git add .
5 git rebase –continue
遴选：
将2分支上的某些commit提交到3分支上：

1. 切到3分支上
2. 选中2分支上需要抽取的commit，按shift可以多选
3. 点击遴选
4. 如果遇到冲突，解决冲突，并标记已解决即可
5. 提交

   注意：

   一次遴选过后，想要继续遴选，需要打开终端，执行git cherry-pick –quit 命令才可继续遴选
   k按Enter即可。

参考及扩展阅读

https://www.cnblogs.com/wish123/p/9785101....
http://danielkummer.github.io/git-flow-che...

本作品采用《CC 协议》，转载必须注明作者和本文链接