一个成功的Git分支模型

  • 时间:
  • 浏览:1
  • 来源:uu快3手机版ios_uu快3app邀请码_在线官网

简单及易重复性带来的好处全都,分支及合并变得不再可怕。版本控制工具本该帮助大伙方便的进行和分支及合并操作。

紧接着主要分支master和develop,大伙的开发模型使用多种支持性分支来帮助团队成员间实现并行开发、追踪产品型态、准备产品版本发布、以及快速修复产品问题。与主要分支不同的是,什么分支的寿命是有限的,它们最终都有被删除。

提醒:你将会一同也会你还还可以用 -s 将会 -u 来对标签进行签名。

本文使用Git作为所有源码的版本控制工具。

都要合并回:develop和master

首先,更新master分支并打上标签。

git checkout develop

Switch to branch ‘develop’

$ git merge –no-ff myfeature Updating ea1b82a..05e9557

上述每种分支都有特定的用途,它们所有人关于源自什么分支、合并回什么分支,都有严格的规定。稍后大伙逐个进行介绍。

每个Git用于都应该熟悉origin上的master分支。与master分支平行趋于稳定的,是另外有好几个 名为develop的分支。

在类事 分支模型中大伙使用的,且被证实工作得很好的仓库配置,其核心是有好几个 中心“真理”仓库。注意只有该仓库才被认为是中心库(将会Git是DVCS [分布式版本控制系统],在技术层面那么 中心库类事 东西)。可是大伙用origin指代该仓库,将会大多数Git用户都熟悉类事 名称。

使用热补丁分支的主要作用是(develop分支上的)团队成员可不都要继续工作,而另外的人可不都要在热补丁分支上进行快速的产品bug修复。

为了能保留发布分支上的变更,大伙还都要将分支合并回develop。在Git中:

创建新分支并转到该分支可是,大伙设定版本号。这里的bump-version.sh是有好几个 虚构的shell脚本,它修改其他本地工作区的文件以体现新的版本号。(当然这也可不都要手动完成——这里全都说要有其他文件变更)接着,提交新版本号。

上述代码中的–no-ff标记会使合并永远创建有好几个 新的commit对象,即使该合不能以fast-forward的最好的办法 进行。那么 做可不都要外理丢失型态分支趋于稳定的历史信息,一同不能清晰的展现一组commit一同构成有好几个 型态。比较下面的图:

大伙认为origin/develop分支上的HEAD源码反映了开发过程中最新的提交变更。许多人会称之为“集成分支”。该分支是自动化每日构建的代码源。

正是在发布分支创建的可是,对应的版本发布才获得有好几个 版本号——只有更早。在该时刻可是,develop分支反映的是“下一版本”的相关变更,但告诉我这“下一版本”到底会成为0.3还是1.0,直到发布分支被创建。版本号是在发布分支创建时,基于项目版本号规则取舍的。

本文中我会展示一种 开发模型,一年前该模型就将会被我用在所有的项目中(包括工作中的项目和私有项目),结果是非常成功的。我早就想为此写点东西,可直到现在才有时间。本文不需要讲述任何项目的细节,只会涉及到分支策略和发布管理。

怎么让,每次有变化被合并到master分支时,根据定义这全都一次新的产品版本发布。大伙趋向于严格遵守该规范,全都理论上来说,每次master有提交时,大伙都可不都要使用有好几个 Git钩子(hook)脚从前自动构建并部署软件至产品环境服务器。

$ git checkout master

Switched to branch ‘master’

$ git merge –no-ff hotfix-1.2.1 Merge made by recursive.

接着,将修复代码合并到develop:

分支命名约定:release-*

发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外,它还允许你修复小bug以及准备版本发布的元数据(类事版本号,构建日期等等)。在发布分支做什么事情可是,develop分支就会显得比较干净,也方便为下一大版本发布接受型态。

都要合并回:develop和master

将会的分支来源:master

每个开发者都对origin做push和pull操作。不过除了类事 中心化的push-pull关系外,每个开发者还可不都要从其他开发者将会小组处pull变更。类事,将会有好几个 或更多的开发者一同开发有好几个 大的型态,在往origin永久性的push工作代码可是,大伙之间可不都要执行其他去中心化的操作。在上图中,分别有Alice和Bob、Alice和David、Clair和David什么小组。

大伙会用到的分支有这几类:

$ git commit -a -m “Bumped version number to 1.2.1″ [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1

简单介绍下工具后,让大伙来看开发模型。我讲介绍的模型本质上全都一组步骤,每个团队成员都都要遵循什么步骤以形成有好几个 可靠管理的软件开发过程。

$ git commit -m “Fixed severe production problem”

[hotfix-1.2.1 abbe5d6] Fixed severe production problem

5 files changed, 32 insertions(+), 17 deletions(-)

现在工作才算真正完成了,最后一步是删除发布分支,将会大伙已不再都要它:

git-branch-4

现在版本发布完成了,怎么让为未来的查阅提供了标签。

前两步在Git中的操作:

当发布分支达到有好几个 可不都要正式发布的清况 时,大伙就都要执行其他操作。首先,将发布分支合并至master(记住,大伙可是定义master分支上的每有好几个 commit都对应有好几个 新版本)。接着,master分支上的commit都要被打上标签(tag),以方便将来寻找历史版本。最后,发布分支上的变更都要合并回develop,从前将来的版本不能蕴藏相关的bug修复。

新的发布分支将会趋于稳定一段时间,直到该版本明确对外交付。这段时间内,该分支上将会会有其他bug的修复(而都有在develop分支上)。在该分支加进进新型态是严格禁止的。新型态都要合并到develop分支,怎么让等待的图片 下有好几个 版本发布。

完成的型态应该被合并回develop分支以将型态加入到下有好几个 发布版本中:

将会的分支来源:develop

将会的分支来源:develop

这里还有个例外清况 ,将会类事 可是有发布分支趋于稳定,热补丁分支的变更则应该合并至发布分支,而都有develop。将热补丁合并到发布分支,也原因当发布分支刚开始英文了了的可是,变更最终会被合并到develop。(将会develop上的开发工作急需热补丁并无法等待的图片 发布分支完成,这时你也将会可不都要安全地将热补丁合并到develop分支。)

git-branch-5

$ git branch -d hotfix-1.2.1

Deleted branch hotfix-1.2.1 (was abbe5d6).

提醒:你将会一同也会你还还可以用 -s 将会 -u 来对标签进行签名。

怎么让,修复bug并使用有好几个 将会多个单独的commit提交。

是的,那么 做会造成其他(空的)commit对象,但那么 做是利大于弊的。

$ git checkout master

Switched to branch ‘master’

$ git merge –no-ff release-1.2 Merge made by recursive.

刚开始英文了了开发新型态的可是,从develop分支创建型态分支。

此开发模型的核心主要受现有的模型启发。中心仓库蕴藏了有好几个 主要分支,类事 有好几个 分支的寿命是无限的:

分支命名约定:hotfix-*

人太好类事 分支模型中那么 什么特别新鲜的东西,但本文起始处的“全景图”事实上在大伙的项目中起到了非常大的作用。它帮助建立了优雅的,易理解的概念模型,使得团队成员不能快速建立并理解有好几个 公用的分支和发布过程。

git-branch-6

$ git branch -d myfeature Deleted branch myfeature (was 05e9557).

$ git checkout -b releases-1.2 develop

Switched to a new branch “release-1.2”

$ ./bump-version.sh 1.2 Files modified successfully. version bumped to 1.2.

git-branch-3

类事 操作将会会原因合并冲突(将会性还很大,将会大伙改变了版本号)。将会发现,则修复之并提交。

发布分支从develop分支创建。类事,假设1.1.5是当前的产品版本,一同大伙即将发布下个版本。develop分支的清况 将会是准备好“下一版本”发布了,大伙也决定下个版本是1.2(而都有1.1.6将会2.0)。怎么让大伙创建发布分支,怎么让为其赋予有好几个 能体现新版本号的名称:

分支命令约定:任何除master, develop, release-*, 或 hotfix-*以外的名称

最后,删除临时的热补丁分支:

修复完成后,热补丁分支都要合并回master,但一同它还都要被合并回develop,从前相关的修复代码才会一同被蕴藏在下个版本中。这与大伙完成发布分支很类事。

$ git checkout develop

Switched to branch ‘develop’

$ git merge –no-ff release-1.2 Merge made by recursive.

热补丁分支从master分支创建。类事,假设1.2是当前正在被使用的产品版本,将会有好几个 严重的bug,产品引起了全都问题。一同,develop分支还趋于稳定不稳定清况 ,无法发布新的版本。这时大伙可不都要创建有好几个 热补丁分支,并在该分支上修复问题:

型态分支(有时也被称作topic分支)是用来为下一发布版本开发新型态。当刚开始英文了了开发有好几个 型态的可是,该型态会成为哪个发布版本的一每种,往往还告诉我。型态分支的重点是,假若型态还在开发,该分支就会突然趋于稳定,不过它最终会被合并回develop分支(将该型态加入到发布版本中),将会被丢弃(将会试验的结果令人失望)。

从develop分支创建发布分支的时间通常是develop分支(差太多)能反映新版本所期望清况 的可是。相当于说,这是可是版本发布所计划的型态都将会合并回了develop分支。而未来其它版本发布计划的型态则不应该合并,它们都要等到当前的版本分支创建好可是不能合并。

可惜的是,我没能找到最好的办法 让–no-diff成为默认的git merge行为参数,但人太好应该那么 做。

从技术深度来说,什么分支其他都有“特殊”。分支按照大伙对其的使用最好的办法 进行分类。技术深度它们都一样是平常的Git分支。

 原文发布时间为:2013-10-07

要全面了解Git与其它集中式版本控制系统相比的优劣,可不都要参考类事 页面。这方面的争论可谓是硝烟弥漫。作为有好几个 开发者,所有什么工具中我最钟情于Git。Git的的确确改变了大伙考虑合并及分支的最好的办法 。在我可是趋于稳定的经典CVS/Subversion世界中,合并/分支突然被认为是特别可怕的事情(“小心合并冲突,丫会恶心到你”),怎么你还还可以只应偶尔干类事 事情。

$ git checkout develop

Switched to branch ‘develop’

$ git merge –no-ff hotfix-1.2.1 Merge made by recursive.

$ git commit -a -m “Bumped version number to 1.2” [release-1.2 74d9424] Bumped version number to 1.2

git-branch-2

git-branch-1

当develop分支上的源码到达有好几个 稳定的清况 时,就可不都要发布版本。所有develop上的变更都应该以一种 最好的办法 合并回master分支,怎么让使用发布版本号打上标签。稍后大伙会讨论具体操作细节。

本文来自云栖社区商务商务合作伙伴“Linux中国”

型态分支往往只趋于稳定于开发者的仓库中,而不需要老出在origin。

都要合并回:develop

$ git checkout -b myfeature develop

Switch to a new branch “myfeature”

$ git checkout -b hotfix-1.2.1 master

Switched to a new branch “hotfix-1.2.1″

$ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1.

$ git branch -d release-1.2

Deleted branch release-1.2 (was ff452fe).

从技术上来说,这仅仅是Alice定义有好几个 Git remote,名字为bob,指向Bob的仓库,反过来也一样。

不言而喻忘了在创建热补丁分可是设定有好几个 新的版本号!

在第2张图中,将会无法一眼从Git历史中看后什么commit对象构成了有好几个 型态——你都要阅读日志以获得该信息。在类事 清况 下,回退(revert)整个型态(一组commit)就会比较麻烦,而将会使用了–no-diff就会简单全都。

但有了Git,同类事情就变得非常简单,分支及合并甚至被认为有了你日常版本控制操作的核心之一。类事,在CVS/Subversion的书中,分支及合并往往在上方的章节才被介绍(针对高级用户),但在每一本Git的书中,该内容将会在前3章中介绍(基础)。

热补丁分支和发布分支十分类事,它的目的也是发布有好几个 新的产品版本,尽管是什么都那么 计划中的版本发布。当产品版本发现未预期的问题的可是,就都要理解着手外理,类事 可是就要用到热补丁分支。当产品版本的重大bug都要立即外理的可是,大伙从对应版本的标签创建出有好几个 热补丁分支。