关于GitFlow工作流一些总结

前任老大一直都是推荐使用 Git Flow 工作流 可是好多同事不喜欢这么干,每次都是自己合并分支 没有备注 乱打 tag 因为这个鬼事情 出错了好几次 头疼,最近自己又补了相关知识 下面主要讲下 Git Flow 工作流 的一些命令都干了什么


WorkFlow

一般我们都是使用 Git 来做代码管理的 中间大家都在操作 为了方便协作 减少不必要的混乱 都会有一个工作流程 这个就是 WorkFlow

常用的 一般有

Git Flow
Github Flow
Gitlab Flow

Git Flow

最早诞生、并得到广泛采用的一种工作流程,就是Git flow

主要讲下 git flow 工作流 他会同时维护 2长期分支

一个是 主干分支 master 用来存放稳定发布版本

一个是 开发分支 develop 用来存放日常开发版本

建议:每次 创建分支合并分支 的时候 先 fetch 一下 developmaster 分支 有更新的话直接更新最新代码,保持同步

初始化

一般高版本的git工具都内置了 git flow 命名 在检出项目分支后直接运行 git flow init 进行初始化 中间会询问你一些确定的分支名称 如果你没有异议 直接一路回车搞定

1
2
3
4
5
6
7
8
9
10
$ git flow init
...
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [.git/hooks]

执行完毕 他会帮你生成2个长期分支 分别是 developmaster

功能分支

创建功能分支

一般我们需要开发新功能的时候 需要创建一个 功能分支(feature branch) 可以执行命令 git flow feature start barnach_name

1
2
3
4
5
6
7
8
$ git flow feature start test
...
Summary of actions:
- A new branch 'feature/test' was created, based on 'develop'
- You are now on branch 'feature/test'
When done, use:
git flow feature finish test

通过输出信息可以看到 git flow 他会帮你基于 develop 分支创建了 功能分支 feature/test 给你 然后并帮你切换到了 feature/test 分支上, 并且告诉你在你开发完成后需要合并分支的时候可以 使用命令 git flow feature finish test 来合并分支

完成功能分支

在我们确定完成了新功能准备合并的时候 可以通过命令 git flow feature finish test

1
2
3
4
5
6
$ git flow feature finish test
...
Summary of actions:
- The feature branch 'feature/test' was merged into 'develop'
- Feature branch 'feature/test' has been locally deleted
- You are now on branch 'develop'

通过上面显示信息 我们可以看到 执行这个命令的时候 git flow 他进行了3步操作 先是吧当前的 feature/test 分支合并进了 develop 分支 然后删除了本地的 feature/test 分支 最后帮你切换到了 develop 分支上

预发布分支

创建预发布分支

在我们完成了功能分支后 一般要创建一个 预发布分支(release branch) 然后进行提测 给测试人员来测试 可以执行命令 git flow release start 版本号

1
2
3
4
5
6
7
8
$ git flow release start v1.0.0
...
Summary of actions:
- A new branch 'release/v1.0.0' was created, based on 'develop'
- You are now on branch 'release/v1.0.0'
...
- When done, run:
git flow release finish 'v1.0.0'

可以看到他是基于 develop 分支帮我们创建了 release/v1.0.0 分支 并且帮你自动切换过去 并且告诉你当你完成了后准备合并的时候可以执行 git flow release finish 'v1.0.0' 来合并预发布分支

完成预发布分支

当各种验收通过 准备合并当前的 预发布分支 发布线上的时候 可以执行 git flow release finish 'v1.0.0' (这里的名字是你上面创建的)

1
2
git flow release finish 'v1.0.0'
....

这个时候他会让你打上2个备注 第一个备注是你合并分支 Merge branch 'relese/v1.0.0' 需要的备注信息 记录本次合并分支需要

第二次备注是让你给 tag 标签打一个备注 输入保存退出即可

最后会有个信息 他会合并 tag v1.0.0develop 分支中 直接退出保存

1
2
3
4
5
6
7
8
$ git flow release finish 'v1.0.0'
...
Summary of actions:
- Release branch 'release/v1.0.0' has been merged into 'master'
- The release was tagged 'v1.0.0'
- Release tag 'v1.0.0' has been back-merged into 'develop'
- Release branch 'release/v1.0.0' has been locally deleted
- You are now on branch 'develop'

可以看到他后面的操作是帮你把 release/v1.0.0 分支合并到了 master 然后打上了 tag 同时合并到了 develop 最后把本地的 release/v1.0.0 分支删除 然后切换到了 develop 分支

后面需要发布的话(如果有权限) 只需要

  1. git push origin 'v1.0.0' 推送tag
  2. git push origin develop 推送 develop 分支
  3. 切换到 master 分支 git push origin master 推送master分支

补丁分支

创建补丁分支

一般我们遇到线上有些 bug 需要紧急修复的时候就可以创建一个 补丁分支(hotfix branch) 执行命令 git flow hotfix start branch_name 这里我随便写的名字 不要纠结

1
2
3
4
5
6
7
8
$ git flow hotfix start v1.0.0.1
...
Summary of actions:
- A new branch 'hotfix/v1.0.0.1' was created, based on 'master'
- You are now on branch 'hotfix/v1.0.0.1'
...
- When done, run:
git flow hotfix finish 'v1.0.0.1'

可以看到他类似 功能分支 只不过他是基于 master 分支创建的 并且帮你自动切换到 hotfix/v1.0.0.1 分支上

完成补丁分支

当我们修改完bug 并且验收完毕的时候就可以合并分支 准备发布了

1
2
3
4
5
6
7
8
$ git flow hotfix finish 'v1.0.0.1'
...
Summary of actions:
- Hotfix branch 'hotfix/v1.0.0.1' has been merged into 'master'
- The hotfix was tagged 'v1.0.0.1'
- Hotfix tag 'v1.0.0.1' has been back-merged into 'develop'
- Hotfix branch 'hotfix/v1.0.0.1' has been locally deleted
- You are now on branch 'develop'

他的过程和合并 预发布分支 是一样的 都需要打2次备注 帮你合并master 打tag 同步develop 删除本地分支 切换分支

总结

其实使用 git flow 通过简单的命令 他帮我们处理的操作就是些依赖不同 长期分支 检出分支 然后帮你合并分支 添加备注 添加tag 并帮你自动切换分支 完全可以自己手动用基础 git 命令 操作 但是他简化了这个过程 不是挺好的么 还能防止中间手误

不足的地方,引用下 阮一峰大神 的话:

Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。

更大问题在于,这个模式是基于”版本发布”的,目标是一段时间以后产出一个新版本。但是,很多网站项目是”持续发布”,代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支

参考

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

http://www.ruanyifeng.com/blog/2012/07/git.html

http://www.ruanyifeng.com/blog/2015/08/git-use-process.html


-------------The End-------------