git flow与分支管理

git flow与分支管理

  • 一、git flow是什么
  • 二、分支管理
    • 1、主分支Master
    • 2、开发分支Develop
    • 3、临时性分支
      • 功能分支
      • 预发布分支
      • 修补bug分支
  • 三、分支管理最佳实践
    • 1、分支名义规划
    • 2、环境与分支
    • 3、分支图
  • 四、git flow缺点

一、git flow是什么

Git 作为一个源码管理系统,不可避免涉及到多人协作。

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。“工作流程"在英语里,叫做"workflow"或者"flow”,原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

git flow与分支管理_第1张图片
最早诞生、并得到广泛采用的一种工作流程,就是 Git flow 。

首先,项目存在两个长期分支。

  • 主分支master
  • 开发分支develop
    git flow与分支管理_第2张图片

前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。

其次,项目存在三种短期分支。

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

一旦完成开发,它们就会被合并进develop或master,然后被删除。
git flow与分支管理_第3张图片

二、分支管理

Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用。但是,太方便了也会产生副作用。如果你不加注意,很可能会留下一个枝节蔓生、四处开放的版本库,到处都是分支,完全看不出主干发展的脉络。

git flow与分支管理_第4张图片
Vincent Driessen提出了一个分支管理的策略,非常值得借鉴。它可以使得版本库的演进保持简洁,主干清晰,各个分支各司其职、井井有条。理论上,这些策略对所有的版本管理系统都适用,下文中Git只是用来举例而已,如果你不熟悉Git,跳过举例部分即可。

1、主分支Master

首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。
git flow与分支管理_第5张图片
Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。

2、开发分支Develop

主分支只用来发布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。
git flow与分支管理_第6张图片
这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就需要切换到Master分支上对Develop分支进行"合并"(merge)。

// Git创建Develop分支的命令:
git checkout -b develop master

// 将Develop分支发布到Master分支的命令
# 切换到Master分支  
git checkout master

# 对Develop分支进行合并  
git merge --no-ff develop

这里稍微解释一下,上一条命令的–no-ff参数是什么意思。默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将Master分支指向Develop分支。

fast-farward merge –no-ff
git flow与分支管理_第7张图片 git flow与分支管理_第8张图片

使用–no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。关于合并的更多解释,请参考Benjamin Sandofsky的《Understanding the Git Workflow》。

3、临时性分支

前面讲到版本库的两条主要分支:Master和Develop。前者用于正式发布,后者用于日常开发。其实,常设分支只需要这两条就够了,不需要其他了。

但是,除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:

  • 功能(feature)分支
  • 预发布(release)分支
  • 修补bug(fixbug)分支

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

功能分支

第一种是功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。
git flow与分支管理_第9张图片
功能分支的名字,可以采用feature-*的形式命名。

// 创建一个功能分支:
git checkout -b feature-x develop

// 开发完成后,将功能分支合并到develop分支:
git checkout develop
git merge --no-ff feature-x

// 删除feature分支:
git branch -d feature-x

预发布分支

第二种是预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-*的形式。

// 创建一个预发布分支:
git checkout -b release-1.2 develop

// 确认没有问题后,合并到master分支:
git checkout master
git merge --no-ff release-1.2

// 对合并生成的新节点,做一个标签  
git tag -a 1.2

// 再合并到develop分支:
git checkout develop
git merge --no-ff release-1.2

// 最后,删除预发布分支:
git branch -d release-1.2

修补bug分支

最后一种是修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。
git flow与分支管理_第10张图片

// 创建一个修补bug分支:
git checkout -b fixbug-0.1 master

// 修补结束后,合并到master分支:
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

// 再合并到develop分支:
git checkout develop
git merge --no-ff fixbug-0.1

// 最后,删除"修补bug分支":
git branch -d fixbug-0.1

三、分支管理最佳实践

1、分支名义规划

分支/tag名 命名规则 描述
master分支
主分支
master,固定不变 永远是可用的、稳定的、可直接发布的版本,不能直接在该分支上开发。
用于迁移feature和hotfix分支,也用于打上线快照r_tag,用于上线
feature-xxx
功能开发分支
feature-{name},以开发功能模块命名
不能有大写字母,多个单词之间用下划线替代
由RD从master分支迁出,开发完成后合并到dev分支,提测的时候合并到qa分支,上线集成的时候需要合并到release分支。用于新需求或功能的开发也用于dev环境泳道1的部署(非主干泳道的部署,主干泳道只能用master部署)
qa
测试主分支
qa,固定不变 提测分支,qa分支只能由feature做merge合并,不能直接在该分支上开发,用于QA测试
release-xxx
发布分支
release-${yyyyMMdd},以yyyyMMdd格式命名,如果一天有多个分支后面增加24单位的双位小时时间yyMMddHH release分支是测试完成后,由RD或QA创建,从master迁,并将feature分支merge到release分支。主要是用在预发环境集成测试。
release-xxx-bug
功能bug修复分支
release-${yyyyMMdd}-bug,参考release-xx分支的命名 在release上创建分支修复,修复好提测的bug之后合并回release分支
hotfix-xxx
紧急bug修改分支
hotfix-{name},以修复bug的名称命名。不能有大写字母,多个单词之间用下划线替代 项目上线之后可能会遇到一些环境问题需要紧急修复,流程跟release分支相似,修复完成要上线的时候合并master分支
b-tag TAG b-{yyyyMMdd}-{name},不能有大写字母,多个单词之间用下划线替代 b-tag从release分支打出,用于灰度上线验证
r-tag TAG r-{yyyyMMdd}-{name},不能有大写字母,多个单词之间用下划线替代 r-tag用于上线的tag,由QA同学创建。灰度上线验证通过,会将release合并到master分支,从master打出r-tag
hotfix分支 hotfix/{yyyyMMdd}-{bug},不能有大写字母,多个单词之间用下划线替代 用于线上bug的修复,从master分支迁出

2、环境与分支

固定代码分支与服务部署环境的关联关系如下表所示。

环境 代码分支 tag 备注
prod master rtag 生产环境,即线上服务,上线应使用从master分支打出的r_tag上线
staging release btag staging环境,用master代码分支和配置进行验证,上线前的最后检查
test qa 测试环境,用于支持QA同事做功能测试,部署权限需联系接口QA。
dev feature 开发环境,用于研发同事之间做接口联调、功能测试。

3、分支图

git flow与分支管理_第11张图片

四、git flow缺点

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

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

分支太多,所以会出现 git log 混乱的局面。具体来说,主要是 git-flow 使用git merge --no-ff来合并分支,在 git-flow 这样多个分支的环境下会让你的分支管理的 log 变得很难看。如下所示,左边是使用–no-ff 参数在多个分支下的问题。
git flow与分支管理_第12张图片
所谓–no-ff参数的意思是——no fast forward的意思。也就是说,合并的方法不要把这个分支的提交以前置合并的方式,而是留下一个 merge 的提交。这是把双刃剑,我们希望我们的–no-ff能像右边那样,而不是像左边那样。对此的建议是:只有 feature 合并到 developer 分支时,使用–no-ff 参数,其他的合并都不使用–no-ff参数来做合并。另外,还有一个问题就是,在开发得足够快的时候,你会觉得同时维护 Master 和 Developer 两个分支是一件很无聊的事,因为这两个分支在大多数情况下都是一样的。包括 Release 分支,你会觉得创建的这些分支太无聊。而你的整个开发过程也会因为这么复杂的管理变得非常复杂。尤其当你想回滚某些人的提交时,你就会发现这事似乎有点儿不好干了。而且在工作过程中,你会来来回回地切换工作的分支,有时候一不小心没有切换,就提交到了不正确的分支上,你还要回滚和重新提交,等等。

Git Flow 抛弃了 rebase如果你要使用 Git Flow,就得放弃 rebase。rebase 取消了合并提交——也就是可以看到两个分支合并的地方。由于 Git Flow 的复杂性,你需要可视化跟踪分支,这意味着如果你想要看到来龙去脉,就不能使用 rebase。


  1. 泳道环境是什么? ↩︎

你可能感兴趣的:(git&github,git)