分支策略 GIT [关闭]

Posted 2023-02-19

【中文标题】分支策略 GIT [关闭]

【英文标题】：Branching Strategy GIT [closed]

【发布时间】：2021-07-02 12:23:00

【问题描述】：

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

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

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

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

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

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

【问题讨论】：

为了更好地了解您当前的分支策略，您如何知道生产中的内容？

我们从 master 创建了一个名为 release 的分支，其中包含一个生产版本.. 这发生在 1 个月前，现在正在 master 中进行更改。

【参考方案1】：

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

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

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

【讨论】：

这会有所帮助..谢谢