分支策略GIT

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

主版本

当

master

在上线功能方面稳定时，我们将发布

版本

任何
版本
特定的更改将再次合并回主版本，主版本现在正在进行增量更改（新更改）

由于
master
上现在正在进行常规更改，我的同事要求从
master
中提取一个特性（不是单个提交，而是一堆提交，否则
cherry pick
是选项），作为
发布
分支提供，以推动生产

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

请建议正确的分支策略来处理此场景。
从概念上讲，您似乎想要进行热修复。要做到这一点，您需要从当前正在生产中的提交创建一个新分支。（或者，如果发布分支仍然存在，并且您更愿意使用它，您可以这样做。）让我们将该分支称为您的
hotfix
分支

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

正如您所指出的，您能否成功地选择提交取决于更改是什么，以及它们所依赖的其他提交。如果该功能是自包含的，那么它可能不会出现任何问题。我想说，我做的大部分樱桃采摘工作都完美无缺。有时，由于依赖关系，我不得不引入额外的提交。有一次，我试图引入一组相互交织的提交，结果我需要挑选100多个提交，只是为了引入一个本身只有5个提交的特性。在这种情况下，我们认输了，并说我们会等到我们可以释放整个事情。作为一般的经验法则，任何时候你选择一个早期版本的功能，测试都是关键。
为了更好地理解你当前的分支策略，你如何知道现在正在生产什么？我们从master创建了一个分支，名为release，它拥有一个生产版本。。这发生在1个月前，现在正在母版中进行更改。这将有助于。。谢谢