git - 分支策略 GIT

Question

我们正在进行基于功能的开发，一旦 PR 获得批准，它就会合并回master.

当上master线的功能稳定时，我们会创建release它的一个分支。

任何release特定更改都将再次合并回 master，现在进行增量更改（新更改）。

由于现在正在进行常规更改master，因此我的同事要求从（不是单个提交，一堆提交，否则cherry-pick是选项）中提取一个功能master作为release分支来推动生产。

好吧，由于该功能是针对增量更改开发的，因此根据“发布”分支重新开发可能需要大量时间。

请建议正确的分支策略来处理这种情况。

标签： gitversion-controlbranching-and-mergingbranching-strategy

Answer 1

从概念上讲，这听起来像是您想做一个修补程序。为此，您需要从当前正在生产的提交中创建一个新分支。（或者，如果发布分支仍然存在并且您更喜欢使用它，您可以。）让我们将该分支称为您的hotfix分支。

现在，您从 中获取您需要的一组较新的提交master，并按照创建它们的相同顺序将它们挑选hotfix到分支中。如果该功能中有许多提交，那么挑选可能会很麻烦，因此您可以使用git rebase --onto 3 个参数来有效地在一个命令中挑选一系列提交。

正如您所指出的，您是否可以成功挑选提交取决于更改是什么，以及它们依赖的其他提交。也许如果该功能是自包含的，它将毫无问题地工作。我会说我所做的大多数樱桃选择都完美无缺。有时，由于依赖关系，我最终不得不引入额外的提交。有一次我试图引入一组相互交织的提交，以至于我最终需要挑选超过 100 个提交，只是为了引入一个本身只有 5 个提交的功能。在那种情况下，我们认输并说我们会等到我们可以释放整个事情。作为一般经验法则，无论何时您为早期版本挑选一个功能，测试都是关键。