Git分支和合并修复基本

Question

情况就是这样。 我有master和一个分支，可以将其称为“ image2”

因此，从最新的最新版本开始，我分支并创建了image2。 我继续在image2分支上工作..过了一会儿，发现一个巨大的bug也影响了master。

现在，由于主版本已发布，因此我需要在那里进行修复。 我检出要掌握的内容，修复其中一个文件中的错误（将其称为文件A），然后返回image2以继续在该分支上工作。 事实是，此修复程序仅适用于master，而不适用于image2。 问题是：将主修订应用于image2的正确方法是什么？ 我猜因为合并会带来麻烦，因为image2中文件A的代码有很多新东西，但是它也需要在master中应用的修复程序。

谢谢

Answer 1

如果image2分支未推送到远程存储库，则可以将该分支重新建立在新的主数据库上。 如果已经推送到远程仓库，则需要将其与新的主仓库合并。

如果合并是一个大问题，则您只能应用可修复master分支中的错误的提交。 为此，请使用“ cherry-pick”命令。

在image2分支上，运行git cherry-pick sha-value-of-the-commit

Answer 2

您正在寻找一种称为Git Flow的Git分支策略。

这为众多常见的开发方案（包括您在问题中描述的“修补程序”方案）定义了一种策略。

master应该始终包含正在生产中积极运行的代码。 因此您可以正确地说，当您需要修复prod中的错误时，可以从master创建一个hotfix分支。 修复错误后，将修补程序分支部署到prod，然后合并到master 。

作为功能分支可以得到陈旧，它的共同需要从任一刷新功能分支master或develop 。 是你的，如果你想偏好合并 master / develop到您的特性分支，或者如果你想变基之上的特性分支master 。 我个人的喜好是重新定基。

因为合并会带来麻烦

如果您指的是合并冲突，那么是的，当您具有并行开发轨道（即， hotfix和feature分支）时，很有可能会发生合并冲突。 这个想法是要尽早解决合并冲突，因此它们不会堆积。 如果您打算使功能分支成为主服务器，则最终需要解决冲突，但是功能分支有责任解决这些冲突并保持最新状态。

这是很棒的gitflow分支图，以供参考。 这应该有助于说明分支的合并方式和时间：