当前位置:K88软件开发文章中心编程工具Git → 文章内容

Git 分支策略

减小字体 增大字体 作者:佚名  来源:网上搜集  发布时间:2019-1-24 10:27:31

由 一水寒 创建,Loen 最后一次修改 2018-02-07 Git 分支策略本文将展示我一年前在自己的项目中成功运用的开发模型。我一直打算把这些东西写出来,但总是没有抽出时间,现在终于写好了。这里介绍的不是任何项目的细节,而是有关分支的策略以及对发布的管理。在我的演示中,所有的操作都是通过 git 完成的。为什么选择 git ?为了了断 git 和中心源代码控制系统的比较和争论,请移步这里看看 链接1 链接2。作为一个开发者,我喜欢 git 超过其它任何现有的工具。Git 真正改变了开发者对于合并和分支的认识。在传统的 CVS/SVN 里,合并/分支总是有点令人害怕的(“注意合并冲突,它们会搞死你的”)。但是 git 中的这些操作是如此的简单有效,它们真正作为你每天工作流程的一部分。比如,在 CVS/SVN 的书籍里,分支和合并总是最后一个章节的讨论重点(对于高级用户),而在每一本 git 的书里 链接1 链接2 链接3,这些内容已经被包含在第三章(基础)里了。因为它的简单直接和重复性,分支和合并不再令人害怕。版本控制工具比其它任何东西都支持分支/合并。有关工具就介绍到这里,我们现在进入开发模型这个正题。我要展现的模型本质上无外乎是一个流程的集合,每个团队成员都有必要遵守这些流程,来达到管理软件开发流程的目的。分散但也集中我们的分支模型中使用良好的代码库的设置方式,是围绕一个真实的中心代码库的。注意,这里的代码库仅仅被看做是一个中心代码库(因为 git 是 DVCS,即分散版本控制系统,从技术层面看,是没有所谓的中心代码库的)。我们习惯于把这个中心代码库命名为 origin,这同时也是所有 git 用户的习惯。每一位开发者都向 origin 这个中心结点 pull 和 push。但是除此之外,每一位开发者也可以向其它结点 pull 改变形成子团队。比如,对于两个以上开发者同时开发一项大的新特性来说,为了不必过早向 origin 推送开发进度,这就非常有用。在上面的这个例子中,Alice 和 Bob、Alice 和 David、Clair 和 David 都是这样的子团队。从技术角度,这无非意味着 Alice 定义一个名为 Bob 的 git remote,指向 Bob 的代码库,反之亦然。主分支该开发模型的核心基本和现有的模型是一样的。中心代码库永远维持着两个主要的分支:masterdevelop在 origin 上的 master 分支和每个 git 用户的保持一致。而和 master 分支并行的另一个分支叫做 develop。我们认为 origin/master 是其 HEAD 源代码总是代表了生产环境准备就绪的状态的主分支。我们认为 origin/develop 是其 HEAD 源代码总是代表了最后一次交付的可以赶上下一次发布的状态的主分支。有人也把它叫做“集成分支”。该源代码还被作为了 nightly build 自动化任务的来源。每当 develop 分支到达一个稳定的阶段,可以对外发布时,所有的改变都会被合并到master 分支,并打一个发布版本的 tag。具体操作方法我们稍后讨论。因此,每次改动被合并到 master 的时候,这就是一个真正的新的发布产品。我们建议对此进行严格的控制,因此理论上我们可以为每次 master 分支的提交都挂一个钩子脚本,向生产环境自动化构建并发布我们的软件。支持型分支我们的开发模型里,紧接着 master 和 develop 主分支的,是多种多样的支持型分支。它们的目的是帮助团队成员并行处理每次追踪特性、准备发布、快速修复线上问题等开发任务。和之前的主分支不同,这些分支的生命周期都是有限的,它们最终都会被删除掉。我们可能会用到的不同类型的分支有:feature 分支release 分支hotfix 分支每一种分支都有一个特别的目的,并且有严格的规则,诸如哪些分支是它们的起始分支、哪些分支必须是它们合并的目标等。我们快速把它们过一遍。这些“特殊”的分支在技术上是没有任何特殊的。分支的类型取决于我们如何运用它们。它们完完全全都是普通而又平凡的 git 分支。feature 分支可能派发自:develop必须合并回:develop分支命名规范:除了 master、develop、release-* 或 hotfix-* 的任何名字Feature 分支(有时也被称作 topic 分支)用来开发包括即将发布或远期发布的新的特性。当我们开始开发一个特性的时候,发布合并的目标可能还不太确定。Feature 分支的生命周期会和新特性的开发周期保持同步,但是最终会合并回 develop (恩,下次发布的时候把这个新特性带上)或被抛弃(真是一次杯具的尝试啊)。Feature 分支通常仅存在于开发者的代码库中,并不出现在 origin 里。创建一个 feature 分支当开始一个新特性的时候,从 develop 分支派发出一个分支$ git checkout -b myfeature developSwitched to a new branch "myfeature"把完成的特性合并回 develop完成的特性可以合并回 develop 分支并赶上下一次发布:$ git checkout developSwitched to a new branch "develop"$ git merge --no-ff myfeatureUpdating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeatureDeleted branch myfeature (was 05e9557)$ git push origin develop-no-ff 标记使得合并操作总是产生一次新的提交,哪怕合并操作可以快速完成。这个标记避免将 feature 分支和团队协作的所有提交的历史信息混在主分支的其它提交之后。比较一下:在右边的例子里,我们不可能从 git 的历史记录中看出来哪些提交实现了这一特性——你可能不得不查看每一笔提交日志。恢复一个完整的特性(比如通过一组提交)在右边变成了一个头疼事情,而如果使用了 --no-ff 之后,就变得简单了。是的,这会创造一些没有必要的(空的)提交记录,但是得到的是大量的好处。不幸的是,我还没有找到一个在 git merge 时默认就把 --no-ff 标记打上的办法,但这很重要。release 分支可能派发自:develop必须合并回:develop 和 master分支命名规范:release-*Release 分支用来支持新的生产环境发布的准备工作。允许在最后阶段产生提交点(dotting i's)和交汇点(crossing t's)。而且允许小幅度的问题修复以及准备发布时的meta数据(比如版本号、发布日期等)。在 release 分支做了上述这些工作之后,develop 分支会被“翻篇儿”,开始接收下一次发布的新特性。我们选择(几近)完成所有预期的开发的时候,作为从 develop 派发出 release 分支的时机。最起码所有准备构建发布的功能都已经及时合并到了 develop 分支。而往后才会发布的功能则不应该合并到 develop 分支——

[1] [2]  下一页


Git 分支策略