分支策略 GIT

如何解决分支策略 GIT

我们正在进行基于功能的开发，一旦 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 个提交的功能。在那种情况下，我们认输并说我们会等到我们可以释放整个事情。作为一般经验法则，无论何时您为早期版本挑选功能，测试都是关键。