git - 从 development merge 到 master 时处理冲突

Question

我开始了一个工作流程，我的目标是在 development 分支中完成所有新功能，而 master 分支将仅用于生产就绪代码。

完成以下操作后:

git checkout master
git merge staging

我收到了一堆这样的冲突:

CONFLICT (rename/add): Rename app/assets/stylesheets/mobile.css->app/assets/stylesheets/application.css in HEAD. app/...
CONFLICT (modify/delete): app/views/organizers/mobile.html.erb deleted in HEAD and modified in staging. Version stagi...
CONFLICT (modify/delete): app/views/events/mobile.html.erb deleted in HEAD and modified in staging. Version staging of app/v...

当我现在用谷歌搜索这个时，我所读到的只是检查每个文件、解决冲突并提交更改。但我看不出做这一切有什么意义，因为我知道代码，而且它只是同一代码集的进步。

如何以简单的方式将 staging 中所做的更改 merge 到 master 中，而无需审查和解决每个更改？

Answer 1

这是一个复杂的问题，因为它基本上意味着 git 无法直观地弄清楚如何组合两个分支。似乎一些文件在 master 上被删除，然后在 staging 中修改(因此被使用)，而另一个在 master 中重命名但添加到 staging。以下将主要是在黑暗中拍摄，您可能仍然需要手动解决一些(但希望更少)冲突。

git 可以选择多种不同的 merge 算法，因此我们将使用最简单、易于定制且通常默认使用的一种:递归策略。我们将通过选项 -s recursive 强制使用它。

帮助 git 的第一步是让它花更多时间改进补丁，因此我们将使用选项 -Xdiff-algorithm=histogram。这将花费最长的时间，但它会强制 git-merge 产生更好的差异输出(这有望减少冲突)。

下一步是告诉 git-merge 花更多时间进行正确的 merge 。我们将使用 -Xpatience 选项来执行此操作。

由于 master 将依赖于重命名/修改的文件，而 staging 将依赖于旧文件，我们可以尝试欺骗 git认为该文件并没有真正用选项 -Xrename-threshold=100% 重命名(因此文件必须相同才能被视为重命名)。请注意，您可能遗留了一些冗余文件，并且对需要注意其他文件名的文件进行的任何更改都不会记录旧名称(仅记录新名称)，因此您可能想返回并修复这些文件一旦你'已经完成 merge 。您还可以将 100% 调整为更小的值(默认值为 50%，目前这会导致问题)。

现在要包含 staging 所需的文件，我们可以使用以下选项强制添加它们:-Xtheirs。 警告:此选项将默认忽略所有 merge 冲突并仅使用 staging 的内容。确保运行完整的测试套件以检查是否存在任何不一致。如果在 merge 后测试套件中确实存在问题，请使用 git reset --hard HEAD^ 撤消它并重做没有这个选项的 merge 。您可能会遇到少量必须手动解决的 merge 冲突，但您会知道错误的来源来自其中一个(有限多个)冲突，这是在前面猜测的巨大飞跃一个调试器。

最后，我们把它们放在一起得到

git checkout master
git merge staging -s recursive -Xdiff-algorithm=histogram -Xpatience -Xrename-threshold=100% -Xtheirs

最后，我建议您尝试一下这些选项。花费在 merge 上的额外时间可能会使最后两个选项无用(甚至变得更糟)。

将来，我建议您定期将 master 中的任何更改 pull 到您的主题分支。这不仅会更早地呈现冲突(因此一次冲突较少)，而且还会使您及时了解最新情况，甚至可以在冲突发生之前解决它们。这很好的另一个原因是 git 有一个名为 git-rerere 的功能，它记录您手动解决的冲突，然后学习如何稍后自动为您解决这些相同的冲突。因此，一旦您解决了一次，您就不必再次解决相同/相似的冲突。