Git流程说明Hotfix和RC是否同时存在? [英] Git flow clarification for the existence of both Hotfix and RC?

问题描述

同时存在RC和Hotfix的一种常见方法是:

A common approach to the existence of both RC and Hotfix is:

修补程序不应该存在 _{(或者可以，但是很短)}，同时还有待处理的RC.

Hotfix should not exists _{(or can, but very shortly)} the same time while there is a pending RC.

查看此图片:

如果有一个暂挂的RC正在暂存中，并且尚未经过全面测试，又突然需要紧急修补程序怎么办?

What if there is a pending RC which is on staging, and wasn't fully tested yet, and suddenly there is a need for an urgent hotfix?

当然，我们接下来将创建一个修补程序分支，对其进行修复，然后合并回dev和master.

Sure we would then create a hotfix branch, fix it, and merge back to dev and master.

但是待处理的RC呢?

But what about the pending RC ?

• 它不包含更改.
• Git流说我们不应该将修补程序合并到RC.
• 我们不能相信此修补程序是在主版本上，因为严格来说，RC应该作为一个整体进行上传和测试.

那么我们应该取消RC吗?但是开发人员与RC分支时的开发人员将不同

So should we then cancel the RC ? but then dev would not be the same as it was when RC was branched

问题

假设有一个待定的未经完全测试的RC和一个紧急修补程序，那么就RC而言应该怎么做?

Assuming there is a pending non-fully-tested-RC, and an urgent hotfix, what should be done in terms of RC?

即使我们将RC(不包含此修补程序)上载到主服务器(包含该修补程序)，也只有下一个RC会包含该修补程序(因为开发人员与该修补程序合并)-但它说一个RC从未使用此修复程序进行过测试-将要上传！！！

我没有找到有关此类情况的此类信息.

I didn't find such information about those kinds of scenarios.

我们应该如何处理RC和修补程序?

How should we deal with RC's and hotfixes?

推荐答案

这就是为什么您不使用gitflow的原因.

That is why you don't use gitflow.

如果您具有这种非线性开发功能，并且不按顺序进行开发工作(例如修补程序)，则可以使用'在此处引入): Git存储库本身.

If you have that kind of non-linear development, with out-of-sequence development effort (like an hotfix), you would use 'gitworkflow" (one word, also introduced here): the workflow used by the Git repo itself.

使用Gitworkflow，您的 RC将位于master ，以及 maint分支(与Git Flow相反)，然后可以根据需要将其合并到master.
(请注意:并非所有所有修补程序都需要向后移植/合并到master或dev:有时，您正在对当前产品版本进行热修复，而这些内容在下一个开发中不再相关循环).

With Gitworkflow, your RC would be in master, and your hotfix in a maint branch which (contrary to Git Flow) can then be merged to master if needed.
(note: not all hotfixes need to be backported/merged to master or dev: sometime, you are hot-fixing in the current production release something which is no longer relevant in the next development cycle).

与Git Flow的另一个区别:"public"和"next"(又名"devel")分支永远不会合并到master.它们是暂时的"或短暂的"，始终被删除/重新创建.
仅功能分支合并到生命周期分支(public，next，master).这意味着您可以随时选择在开发生命周期的一个阶段与下一个阶段之间删除功能.
并且master可以随时从"maint"(修补程序)接收合并.

The other difference with Git Flow: "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.
Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.
And master can receive a merge from 'maint' (hotfixes) at anytime.

然后 dev(称为next )和 pu(用于实验) )只需重置/重新创建，它们各自的选定功能分支已经合并到其中，因为 Git 2.18带来了git rebase --rebase-merges .

Then dev (called next) and pu (for experimentation) are simply reset/recreated, with their respective selecgted feature branches already merged in them, since Git 2.18 brings git rebase --rebase-merges.

这篇关于Git流程说明Hotfix和RC是否同时存在?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！