[英]How to deal with release branch when develop has progressed since release branch was created in git flow?
I think I have a peculiar scenario.我想我有一个特殊的场景。 We follow standard git flow in our organisation.
我们在我们的组织中遵循标准的 git 流。 Except, the release branch takes a bit long to be ready to be merged back into master and develop.
除了,发布分支需要很长时间才能准备好合并回主控和开发。
We used to block all feature branch merges to develop until the release branch is merged back into master and develop.我们曾经阻止所有功能分支合并进行开发,直到发布分支合并回 master 和 develop。 However, when the team size grew, this has become understandably unacceptable.
然而,随着团队规模的扩大,这变得不可接受了,这是可以理解的。 So we want to allow developers to carry on merging their feature branches back to develop even before the release branch is merged.
因此,我们希望允许开发人员在合并发布分支之前继续合并他们的功能分支以进行开发。
Now the issue arises when it is finally the time to merge the release branch.现在问题出现了,终于到了合并发布分支的时候了。 Say features f1 and f2 were on develop before the release r1 was cut.
假设功能 f1 和 f2 在版本 r1 被删除之前正在开发中。 Since then, f3 and f4 were merged back into develop.
从那时起,f3 和 f4 重新合并为develop。 Now, if we merge the release branch r1, the develop's timeline looks like this:
现在,如果我们合并发布分支 r1,开发的时间线如下所示:
Merge commit of r1
Merge commit of f4
Merge commit of f3
Merge commit of f2
Merge commit of f1
This means when the next release r2 is cut, the commit history will include r1, f4 and f3.这意味着当下一个版本 r2 被删减时,提交历史将包括 r1、f4 和 f3。 Something tells me this isn't right.
有人告诉我这是不对的。
However, if we blocked merges to develop whilst the release branch was active, it would look a bit more organised with the release commit appearing exactly where it should be:但是,如果我们在发布分支处于活动状态时阻止合并进行开发,它会看起来更有条理,发布提交准确地出现在它应该在的位置:
Merge commit of f4
Merge commit of f3
Merge commit of r1
Merge commit of f2
Merge commit of f1
What are my options here?我在这里有什么选择? I don't want to do an interactive rebase of develop with last x commits so that I can re-order the commits as that will make me do a force push to the develop branch (scary!).
我不想使用最后 x 次提交对开发进行交互式变基,以便我可以重新排序提交,因为这将使我强制推送到开发分支(可怕!)。
One of the main purposes of Git Flow release
branches is so you don't need a code freeze on the develop
branch. Git Flow
release
分支的主要目的之一是让您不需要在develop
分支上冻结代码。 In fact, I might go as far as saying that when you used to enforce code freezes that Git Flow probably was overly complex for that situation.事实上,我什至可以说,当您过去强制执行代码冻结时,Git Flow 对于这种情况可能过于复杂。 That being said, now that you are doing simultaneous development, the resulting timeline of continuing work on
develop
as you presented is completely normal and expected.话虽如此,既然您正在同时进行开发,那么按照您介绍的方式继续
develop
工作的时间表是完全正常和预期的。 Note that the history of develop
doesn't represent the timeline of releases to production, but instead it's the actual simultaneous development on two separate "paths".请注意,
develop
的历史并不代表从发布到生产的时间表,而是在两个独立的“路径”上实际同时开发。 Similarly, the first-parent history of master
(or main
), which does represent the timeline of releases to production might end up looking like:同样,
master
(或main
)的第一父历史,它确实代表了发布到生产的时间线,最终可能看起来像:
Merge commit of r3
Merge commit of hotfix2.1
Merge commit of r2
Merge commit of r1
and that also is completely normal and expected for the master
or main
branch.对于
master
分支或main
分支来说,这也是完全正常和预期的。
I don't think you need to change a thing.我认为你不需要改变任何事情。
Side Notes:旁注:
release
branches to sometimes get merged back into develop
prior to them being released to production. release
分支有时会在发布到生产环境之前合并回develop
中是很常见的。 Normally this happens when a bug fix is important enough that you want all new and in-flight work on develop
to be able to access the changes immediately.develop
立即访问更改时,就会发生这种情况。 When you do this you'll have at least 2 merges of any specific release
back into develop
, and oftentimes more.release
合并回develop
,而且通常更多。 Some tools even make it easy to automate a backflow so that every completed PR into a release
branch automatically (if possible without conflicts) merges it back down to develop
.release
分支(如果可能没有冲突) develop
其合并回 development 。 Personally, I prefer not to have additional merge commits for "Merge release into develop", so I only do an extra manually merge when the team deems it necessary.release
into master
(or main
), I prefer to then merge master
into develop
instead of release
into develop
.release
合并到master
(或main
)后,我更喜欢将master
合并到develop
而不是release
到develop
。 The reason is simply to get that extra merge commit on master
back into develop
now so they don't build up over time and get brought back into develop
all at once when you finally have a hotfix
.master
上的额外合并提交现在重新回到develop
中,这样它们就不会随着时间的推移而累积,并在您最终获得hotfix
时立即全部重新回到develop
中。 It also makes it a little easier to see that develop
, and consequently any release
branch, is fully up to date with master
since the tip of master
is always reachable by develop
(or at least the existing release
branch).develop
以及因此任何release
分支完全与master
保持同步,因为master
的尖端始终可以通过develop
(或至少现有的release
分支)访问。 Then you know you don't need to worry about blowing away a hotfix on master
that someone forgot to merge back down.master
上吹走某人忘记合并回来的修补程序。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.