开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
介绍一个成功的 Git 分支模型 - 技术翻译 - 开源中国社区

介绍一个成功的 Git 分支模型 【已翻译100%】

标签: Git
Joe Guo 推荐于 4年前 (共 15 段, 翻译完成于 03-01) 评论 20
收藏  
288
推荐标签: Git 待读

完成一个release分支

当一个release分支准备好成为一个真正的发行版的时候,有一些工作必须完成。首先,release分支要合并到master上(因为每一次提交到master上的都是一个新定义的发行版,记住)。然后,提交到master上必须打一个标签,以便以后更加方便的引用这个历史版本。最后,在release分支上的修改必须合并到develop分支上,以便未来发行版也包含这些bugs的修复。

在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

发行版现在已经完成,为以后引用打上标签。

编辑:你可能也想使用the-sor-u <key>flags来标记你的标签。

为了是修改保持在release分支上,我们需要合并这些到develop分支上去,在Git上:

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

这个步骤可能会导致合并冲突(可能由于改变版本号更是如此)。如果是这样,修复它然后提交。

现在我们真正的完成了,这个release分支将被删除,因为我们不再需要它了。

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

FGQ
 翻译得不错哦!
热修复分支

可以基于master分支,必须合并回develop和master分支。
分支名约定:hotfix-*

热修复分支与发布分支很相似,他们都为新的生成环境发布做准备,尽管这是未经计划的。他们来自生产环境的处于异常状态压力。当生成环境验证缺陷必须马上修复是,热修复分支可以基于master分支上对应与线上版本的tag创建。

其本质是团队成员(在develop分支上)的工作可以继续,而另一个人准备生产环境的快速修复。

Lax
 翻译得不错哦!

创建修补bug分支

hotfix branch(修补bug分支)是从Master分支上面分出来的。例如,1.2版本是当前生产环境的版本并且有bug。但是开发分支(develop)变化还不稳定。我们需要分出来一个修补bug分支(hotfix branch)来解决这种情况。

$ 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.1
1 files changed, 1 insertions(+), 1 deletions(-)

分支关闭的时侯不要忘了更新版本号(bump the version)

然后,修复bug,一次提交或者多次分开提交。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
lidashuang
 翻译得不错哦!

完成一个hotfix分支

完成一个bugfix之后,需要把butfix合并到master和develop分支去,这样就可以保证修复的这个bug也包含到下一个发行版中。这一点和完成release分支很相似。

首先,更新master并对release打上tag:

$ 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
编辑:你可能也会想使用 -sor-u <key>参数来对你的tag进行加密

下一步,把bugfix添加到develop分支中:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
规则的一个例外是: 如果一个release分支已经存在,那么应该把hotfix合并到这个release分支,而不是合并到develop分支。当release分支完成后, bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(如果在develop分支的工作急需这个bugfix,等不到release分支的完成,那你也可以把bugfix合并到develop分支)

最后,删除临时分支:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
JoeyBlue
 翻译得不错哦!

摘要

尽管这个分支模型没有任何震撼的新东西, 文章开头的图表在我们的项目中表现出惊人的实用性。它形成了一个优雅的思维模型,易于领悟并使团队成员发展出对分支和发布过程的共同理解。

这里提供一份高质量PDF格式图表。去吧,把它挂载墙上以便能随时快速参考。

更新: 如果有人需要: 这是主图表的gitflow-model.src.key (Apple Keynote格式).


Git-branching-model.pdf

Lax
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(20)
Ctrl/CMD+Enter

嗯,我现在工作里就是用的这种模式
gitflow
赞!目前只是一个人写写代码,还没认真研究过模式
gitflow ++
我们部门就这么用的。但是感觉还是有待完善啊。
我挺好奇他是用什么工具画的图(==)
全局添加--no-ff可以通过
git config --global --add merge.ff false
来完成
参考:http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git

我也是觉得这个模式蛮好的,但是测试环境是个问题啊如果developer上有东西要测比较久,有一部分又是要尽快上线的,这种模式就难办了。

引用来自“耀耀”的评论

我挺好奇他是用什么工具画的图(==)

看起来是keynote。
mark
学习一下,不错。

引用来自“耀耀”的评论

我挺好奇他是用什么工具画的图(==)

我也想知道

引用来自“ruanjf”的评论

引用来自“耀耀”的评论

我挺好奇他是用什么工具画的图(==)

我也想知道

mac电脑上的keynote
受益非浅啊
请问“Bumped version number to 1.2.1”是什么意思啊?因为我在commit里面看到这句话,一直不理解这是什么意思?哪位好心人可以为我解答一下!非常感谢!
发现翻译中有好几个小错误,不知道该怎么办
“完成一个release分支”这一段是机器翻译的么?

引用来自“Hu_JiaJun”的评论

请问“Bumped version number to 1.2.1”是什么意思啊?因为我在commit里面看到这句话,一直不理解这是什么意思?哪位好心人可以为我解答一下!非常感谢!
就是说版本直接跳到了1.2,而不是在1.1.5的基础上慢慢增加,比如1.1.6、1.1.7

引用来自“spudhsu”的评论

全局添加--no-ff可以通过
git config --global --add merge.ff false
来完成
参考:http://stackoverflow.com/questions/2500296/can-i-make-fast-forwarding-be-off-by-default-in-git

我也是觉得这个模式蛮好的,但是测试环境是个问题啊如果developer上有东西要测比较久,有一部分又是要尽快上线的,这种模式就难办了。
这个简单嘛, 可以再临时开个分支, 测试完成了, cherry-pick 选择需要的提交, 合并进目标分支就好了.
我想知道最左边那条分支为什么没有merge 中间的develop分支,因为在最左边那条分支merge到develop分支中途有其他分支merge到develop分支
relaese分支第二段
"当在Release分支完成这些所有工作以后,对于下一次打的发布,develop分支接收features会更加明确。"翻译的很有问题
顶部