问题描述
我们正在进行基于功能的开发,一旦 PR 获得批准,它就会合并回 master
。
当 master
在上线功能方面稳定时,我们创建它的 release
分支。
任何 release
特定更改将再次合并回 master,后者现在进行增量更改(新更改)。
由于现在在 master
上发生常规更改,我的同事要求从 {{1} 中提取(不是单个提交,一堆提交,否则 cherry-pick
是选项) } 作为 master
分支提供以推动生产。
好吧,由于该功能是针对增量更改开发的,因此根据“发布”分支重新开发可能需要大量时间。
请提出正确的分支策略来处理这种情况。
解决方法
从概念上讲,您似乎想做一个修补程序。为此,您需要从当前生产中的提交创建一个新分支。 (或者,如果 release 分支仍然存在并且您更喜欢使用它,则可以。)让我们将该分支称为您的 hotfix
分支。
现在您从 master
获取您需要的一组较新提交,并cherry-pick,按照它们的创建顺序,进入 hotfix
分支.如果功能中有很多提交,挑选可能会很麻烦,因此您可以使用 git rebase --onto
with 3 arguments 在单个命令中有效挑选一系列提交。
正如您所指出的,您是否可以成功挑选提交取决于更改是什么,以及它们依赖于哪些其他提交。也许如果该功能是自包含的,它就可以正常工作。我会说我所做的大多数樱桃选择都完美无缺。有时,由于依赖关系,我最终不得不引入额外的提交。有一次,我试图引入一组相互交织的提交,以至于我最终需要挑选超过 100 个提交来引入一个本身只有 5 个提交的功能。在那种情况下,我们认输并说我们会等到我们可以释放整个事情。作为一般经验法则,无论何时您为早期版本挑选功能,测试都是关键。