Git Flow详细介绍和使用

什么是GitFlow?

Git Flow定义了一个项目发布的分支模型，为管理具有预定发布周期的大型项目提供了一个健壮的框架，是由 Vincent Driessen 提出的一个 git操作流程标准、解决当分支过多时 , 如何有效快速管理这些分支。

使用GitFlow 的优势

并行开发：GitFlow可以很方便的实现并行开发。每个新功能都会建立一个新的 feature分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的feature分支才会合并到主开发分支上（也就是我们经常说的develop分支）。另外，如果你正在开发某个功能，同时又有一个新的功能需要开发，你只需要提交当前 feature 的代码，然后创建另外一个feature 分支并完成新功能开发。然后再切回之前的 feature 分支即可继续完成之前功能的开发。

协作开发：GitFlow 还支持多人协同开发，因为每个 feature 分支上改动的代码都只是为了让某个新的 feature 可以独立运行。同时我们也很容易知道每个人都在干啥。

阶段式发布：当一个新 feature 开发完成的时候，它会被合并到 develop 分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的 feature，我们只需要从 develop 分支创建新分支，即可包含所有已经完成的 feature 。

支持紧急修复：GitFlow 还包含了 hotfix 分支。这种类型的分支是从master上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的 tag，而不会影响到你正在开发的新 feature。

GitFlow基本分支

· master分支存放所有正式发布的版本，可以作为项目历史版本记录分支，不直接提交代码。仅用于保持一个对应线上运行代码的code base。

· develop分支为主开发分支，不直接提交代码

· feature分支为新功能分支，feature分支都是基于develop创建的，开发完成后会合并到develop分支上。同时存在多个

· release分支基于最新develop分支创建，当新功能足够发布一个新版本(或者接近新版本发布的截止日期)，从develop分支创建一个release分支作为新版本的起点，用于测试，所有的测试bug在这个分支改。测试完成后合并到master并打上版本号，同时也合并到develop，更新最新开发分支。(一旦打了release分支之后不要从develop分支上合并新的改动到release分支)，同一时间只有1个，生命周期很短，只是为了发布。

· hotfix分支基于master分支创建，对线上版本的bug进行修复，完成后直接合并到master分支和develop分支，如果当前还有新功能release分支，也同步到release分支上。同一时间只有1个，生命周期较短

Git Flow使用

2、Git Flow常用命令,也可以使用Git命令按照gitflow的流程执行。

gitflow init：初始化一个现有的 git 库,将会设置一些初始的参数，如分支前缀名等，建议用默认值。

git flow feature start [featureBranchName]: 创建一个基于develop的feature分支，并切换到这个分支之下。

git flow feature publish [featureBranchName]：将feature 分支上传至远端，也可以使用git的push命令

git flow feature finish [featureBranchName]: 结束 feature 分支，并 merge 至 develop, 删除本地分支、远程分支(如已推送至仓库), 切换回develop分支。

git flow release start [releaseBranchName]：开始准备release版本，从 develop分支开始创建一个 release 分支。

git flow release publish [releaseBranchName]：将 release 分支上传至远端, 也可以使用git的push命令。

git flow release finish [releaseBranchName]：完成 release 测试，自动将代码 merge 到 master 和develop 分支，用 release 分支名打 Tag，删除本地分支、远程分支(如已推送至仓库)。

git flow hotfix start [hotfixBranchName]：基于 master 分支新建hotfix分支。

git flow hotfix publish [hotfixBranchName]：将hotfix分支上传至远端, 也可以使用git的push命令。

git flow hotfix finish [hotfixBranchName]：结束 hotfix 分支，并 merge 到 master 分支和develop 分支, 自动打tag,删除本地分支、远程分支(如已推送至仓库)。

3、GitFlow 插件,jgitflow-maven-plugin，可以简化整个流程，让很多操作自动化。

官方文档：https://bitbucket.org/atlassian/jgit-flow/wiki/Home

Git Flow基础开发流程和命令

git-flow 命令工具，

◆创建git-flow 分支模型：

a.在一个全新目录下构建 git-flow 模型：git flow init 一路默认Enter键即可

b.在现有的版本库构建（businessno-service）：git flow init

构建成功后自动会切换到develop分支，见上图

◆新功能开发,代号V1.0

任何开发都必须基于develop分支:git flow feature start V1.0

git-flow 基于develop 创建分支feature/V1.0,并自动切换到feature/V1.0.进行此次开发。

推送分支到远程仓库：git flow feature publish V1.0或者

git push --set—upstream origin feature/V1.0

完成功能开发: git flow feature finish V1.0

feature/V1.0 分支的代码会被合并到 develop 里面，然后删除该分支，切换回 develop，此时develop并未推送到远程仓库。需执行git push进行推送。

◆测试/发布上线，代号1.0

基于develop，创建测试/发布分支:git flow release start 1.0

注意：这里不会自动推送release/1.0分支到仓库，需执行git push或者publish，这时进行测试就拿这个分支进行。否则分支只是在本地。测试发现bug在此分支进行修改。

完成release 测试：git flow release finish 1.0

自动将代码 merge 到master 和 develop 分支,将本地和远程仓库的release/1.0删除,自动打包

查看tag：git tag

推送tag至仓库:git push origin --tags发布tag 1.0上线

◆紧急 bug 修正，代号bug1

基于master，开启热修复分支：git flow hotfix start bug1

注意:自动切换到hotfix/bug1分支，只会在本地创建分支，需要执行git push推送至远程仓库，使用此分支进行测试，发现bug在此分支修改。

测试通过: git flow hotfix finish bug1

推送develop/master分支至远程仓库：git push

查看tag:git tag

推送tag至远程仓库：git

push origin ---tags

git-flow 会依次切换到 master develop 分支下合并 hotfix/bug1，然后删掉 hotfix/bug1。hotfix 完成自动打tag为bug1，需要注意需要单独切换到develop和master分支进行手动git push代码才会到远程仓库，生产发布使用bug1即可

总结:

1、git-flow 的 feature release 都是从develop 分支创建，hotfix support 都是从 master 分支创建。

2、最稳定的代码放在 master 分支上，禁止直接在 master 分支上提交代码，只能代码合并操作。

3、我们日常开发需要从 master 分支拉一条 develop 分支出来，禁止直接在该分支上提交代码，只能合并操作。

4、所有的开发任务都是从 develop分支拉出一条 feature 分支，并手动推送至远程仓库(可选),可以按JIRA任务来创建feature分支，finish之后会把代码合并到本地develop分支、删除该分支。

5、当开发完毕后，此时需要从 develop 分支上拉出一条 release 分支并手动推送至远程仓库，随后将针对 release 分支部署测试环境，测试人员在该分支上进行测试，开发人员在该分支上修改 bug。

6、测试通过无bug 时，我们可将该 release 分支部署到预发环境，再次验证以后，均无任何 bug，此时可将 release 分支部署到生产环境。

7、待上线完成后，将 release 分支上的代码同时合并到本地 develop 分支与master 分支，自动打tag、删除该分支(develop\master\tag都需要手动push到远程仓库)。

8、当生产环境发现 bug 时，我们从master拉出一条 hotfix 分支，并在该分支上做 bug 修复。bug 完全修复后，hotfix分支上的代码同时合并到本地develop 分支与 master 分支、自动打tag、删除该分支(develop\master\tag都需要手动push到远程仓库