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