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.1Copy

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 协议》，转载必须注明作者和本文链接