分支策略 GIT [关闭]
Posted
技术标签:
【中文标题】分支策略 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 个提交的功能。在那种情况下,我们认输并说我们会等到我们可以释放整个事情。作为一般经验法则,只要您为早期版本挑选功能,测试就是关键。
【讨论】:
这会有所帮助..谢谢以上是关于分支策略 GIT [关闭]的主要内容,如果未能解决你的问题,请参考以下文章