一个成功的Git分支模型

一个成功的Git分支模型

通过文森特Driessen
星期二,2010年1月5日

在这篇文章中我目前的发展模式,介绍了我的一些项目(在工作和私人)大约一年前,和已被证明是非常成功的。我一直想写一段时间了,但我从来没有真正找到时间做sothoroughly,直到现在。我不会谈论任何项目的细节,只是分支策略和发布管理。



它把重点放在Git作为版本控制工具的我们所有的源代码。(顺便说一下,如果你有兴趣在Git中,我们公司GitPrime提供了一些很棒的实时数据分析软件工程性能。)

为什么git ?

深入讨论利弊的Git源代码集中控制系统相比,看到的网络。有大量的火焰战争。作为一名开发人员,我喜欢今天Git高于所有其他工具。Git真的改变了开发者认为合并和分支。从经典的世界我来自CVS或Subversion,合并/分支一直被认为是有点���怕的(“谨防合并冲突,他们咬你!”)和你只做每隔一段时间的东西。

但由于Git,这些行为是非常便宜和简单的,他们被认为是日常工作流的核心部分之一,真的。例如,在CVS或Subversion书分支和合并,首先讨论了在之后的章节中(对于高级用户),而在每一个Git书,它已经在第三章(基本)。

由于它的简单性和重复性的性质、分支和合并不再害怕。版本控制工具应该协助分支/合并胜过一切。

足够的工具,让我们在发展模式。这里的模型,我要礼物是不超过一组程序,每个团队成员都必须遵循以管理软件开发过程。

分散但集中

我们使用存储库设置,能够很好地处理这个分支模型、与中央“真相”回购。注意,这个repois onlyconsidered中央一个(由于Git是一个DVCS,没有所谓的中央回购技术水平)。我们会参考这个回购

origin

,因为这个名字是熟悉所有Git用户。



每个开发人员拉和推动。但除了集中推拉的关系,每个开发人员也可能将改变从其他同行形成子团队。例如,这可能是有用的与两个或两个以上的开发人员一起工作在一个大的新功能,推动工作进展

origin

过早。在上图中,有分队的爱丽丝和鲍勃,爱丽丝和大卫,克莱尔和大卫。

只不过从技术上讲,这意味着,爱丽丝已经定义了一个Git远程,命名

 bob

指着鲍勃的存储库,反之亦然。

的主要分支

核心,发展模式极大地受到现有的模型。中央回购与无限一生拥有两个主要分支:

master

develop

的

 master

分支

 origin

应该熟悉每一个Git用户。平行于

master

分支,另一个分支的存在

 develop

.

我们考虑

 origin/master

主要分支的源代码

 HEAD

总是反映了生产就绪状态。

我们考虑

 origin/develop

主要分支的源代码

 HEAD

总是反映了一个国家的最新发展变化下一个版本。有些人可能会称之为“集成分支”。这是在自动构建。

当源代码

 develop

线达到稳定的一个点,愿被释放,所有的变化都应该合并回

 master

然后标记版本号码。这是如何实现的细节将进一步讨论。

因此,每次当更改合并回

 master

,这是一个新产品发布的定义。我们往往是非常严格的,因此,从理论上说,我们可以使用Git钩子脚本自动构建和推广我们的软件生产服务器每次有一个承诺

 master

.

支持分支

下一个主要分支

 master

和

 develop

,我们的发展模式使用多种支持分支并行开发团队成员之间的援助,轻松跟踪特性,准备生产版本和协助快速解决现场生产问题。不同于主要分支,这些分支总是有一个有限的生命时间,因为他们最终将被删除。

我们可能使用的不同类型的分支:
特性分支
发布分支
热修复补丁分支

每个分支有一个特定的目的和注定要严格规定哪些分支可能他们原始的分支,分支机构必须合并的目标。我们也会通过它们而走。

绝不是“特殊”从技术的角度来看这些分支。分支类型分类,我们如何使用它们。他们当然是普通Git分支。

特性分支

可能分支:

develop

必须合并回:

develop

分支命名约定:除了

master

,

 develop

,

 release-*

,或

 hotfix-*

特性分支(或有时被称为主题分支)是用于开发为即将到来的新特性或遥远的未来版本。当开始发展的特性,这个特性的目标释放将合并可能是未知的。分支的本质特性是它的存在只要功能正在开发中,但最终将合并回

 develop

(绝对添加新功能即将发布)或丢弃(令人失望的实验)。

特性分支通常只存在于开发者回购,而不是

 origin

.

创建一个特性分支

当开始一个新特性,从分支

 develop

分支。

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

将开发完成的功能

完成功能可以合并成

 develop

部门肯定将它们添加到即将发布:

$ git checkout develop
Switched to branch 'develop'$ git merge --no-ff myfeature
Updating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).$ git push origin develop

的

 --no-ff

国旗导致合并总是创建一个新的提交对象,即使合并可以进行快进。这可以避免失去信息的历史存在一个特性分支和团体一起提交,添加功能。比较:



在后一种情况下,是不可能从Git看到历史的提交对象一起实现了一个功能,你将不得不手动阅读所有的日志消息。恢复一个整体特性(即一组提交),是一个真正的头痛在后者的情况下,而如果它很容易完成

--no-ff

标志使用。

是的,它将创建一个多(空的)的提交对象,但获得远远大于成本。

发布分支

可能分支:

develop

必须合并回:

develop

和

 master

分支命名约定:

release-*

发布分支支持新产品发布的准备。他们允许我最后的点缀和穿越t。此外,他们允许小bug修复和准备发布元数据(版本号,建立日期,等等)。通过所有这些工作发布分支,

 develop

分支是清除接收功能,为下一个版本。

关键时刻分支新版本分支

 develop

当开发(几乎)反映了新版本的期望状态。至少所有功能针对release-to-be-built必须合并

 develop

在这个时间点上。所有功能针对未来版本可能不是他们必须等到发布分支后支。

正是在即将发布的发布分支被分配一个数字不是任何更早的版本。直到那一刻,

 develop

分公司反映变化的“下一版本”,但目前尚不清楚,“下一个版本”最终将成为0.3或1.0,直到发布分支开始。这一决定是由开始的���布分支,由项目的版本号规则碰撞。

创建一个发布分支

发布分支的创建

 develop

分支。例如,假设1.1.5版本是我们当前的产品版本和一个即将到来的大释放。的状态

 develop

准备“下一版本”,我们已经决定,这将成为1.2版本(而不是1.1.6或2.0)。所以我们分支给发布���支名称反映了新版本号:

$ git checkout -b release-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 commit -a -m "Bumped version number to 1.2"[release-1.2 74d9424] Bumped version number to 1.21 files changed, 1 insertions(+), 1 deletions(-)

在创建一个新的分支和切换,我们撞版本号。在这里,

bump-version.sh

是afictionalshell脚本,修改一些文件的工作副本以反映新的版本。(这当然可以手动的变化——点是一些文件变化。)然后,提交版本号。

这个新的分支可能存在一段时间,直到释放可能推出了肯定。在此期间,bug修复可以应用在这个分支(而不是

 develop

分支)。添加大量新特性是严格禁止的。他们必须被并入

 develop

,因此,等待下一个版本。

完成一个发布分支

当发布分支的状态准备成为一个真正的释放,需要进行一些操作。首先,发布分支合并到

 master

(因为每一个承诺

 master

通过定义一个新版本,切记)。接下来,提交

 master

必须标记,以方便以后参考这一历史版本。最后,发布分支上的更改需要合并回

 develop

,所以将来的版本中也含有这些bug修复。

Git的前两个步骤:

$ git checkout master
Switched to branch 'master'$ git merge --no-ff release-1.2
Merge made by recursive.(Summary of changes)$ git tag -a 1.2

释放现在完成,和标记以供将来参考。

编辑:你可能想要使用

 -s

或

 -u
<key>

旗帜密码地签上你的标签。

继续发布分支的更改,我们需要合并回

 develop

,虽然。在Git中:

$ git checkout develop
Switched to branch 'develop'$ git merge --no-ff release-1.2
Merge made by recursive.(Summary of changes)

这一步可能会导致一个合并冲突(可能甚至,因为我们已经改变了版本号)。如果是这样,修理和提交。

现在我们真的完成和发布分支可能会被删除,因为我们不需要它了,

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

热修复补丁分支

可能分支:

master

必须合并回:

develop

和

 master

分支命名约定:

hotfix-*

热修复补丁的树枝很像释放,他们也要准备一个新的产品版本,尽管意外。它们源自立即行动的必要性在一个不受欢迎的国家生产版本。当一个关键错误在生产版本必须立即解决,一次分支可能支从相应的标签在主分支上,标志着生产版本。

工作的本质是团队成员(

 develop

分支机构)可以继续,而另一个人���准备快速生产修复。

创建热修复补丁分支

热修复补丁分支的创建

master

分支。例如,假设1.2版本运行是当前生产释放生活和导致问题由于严重的错误。但变化

 develop

还不稳定。我们可能会分支一次分支并开始修复存在的问题:

$ 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 commit -a -m "Bumped version number to 1.2.1"[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.11 files changed, 1 insertions(+), 1 deletions(-)

别忘了撞版本号后分支!

然后,修复bug并提交修复在一个或多个单独提交。

$ git commit -m "Fixed severe production problem"[hotfix-1.2.1 abbe5d6] Fixed severe production problem5 files changed, 32 insertions(+), 17 deletions(-)

完成一次分支

当完成时,需要合并回错误修复

 master

,但也需要合并回

 develop

,tosafeguardthat在下一个版本中包含错误修复。这是完全类似于发布分支是如何完成的。

首先,更新

 master

和标记��

$ git checkout master
Switched to branch 'master'$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.(Summary of changes)$ git tag -a 1.2.1

编辑:你可能想要使用

 -s

或

 -u
<key>

旗帜密码地签上你的标签。

接下来,包括错误修复

 develop

:

$ git checkout develop
Switched to branch 'develop'$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.(Summary of changes)

规则的一个例外是,发布分支目前存在时,热修复补丁修改需要合并成发布分支,而不是

 develop

。Back-merging错误修复到发布分支最终将被合并到导致错误修复

 develop

发布分支完成后。(如果工作

 develop

立即需要这个错误修复和等待发布分支不能完成,你可以安全地合并错误修复

 develop

现在已经。)

最后,删除临时分支:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

总结

虽然没有真正令人震惊的新分支模型,这篇文章的“大局”图开始已经被证明是非常有用的在我们的项目。它形成一个优雅的心智模型,很容易理解,允许团队成员开发分支的共同理解和释放过程。

提供一个高质量的PDF版本的图。继续,把它挂在墙上的快速参考。

更新:并对那些要求:这是gitflow-model.src.key主图的图像(苹果主题)。




Git-branching-model.pdf

如果你想联系我@nvie在Twitter上。