处理从开发合并到母版时的冲突

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为master以简单的方式，而无需审查和解决每一个变化？

Answer 1

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

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

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

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

由于master将取决于重命名/修改的文件，而staging将取决于旧文件，我们可以尝试欺骗git认为该文件并未真正使用选项重命名-Xrename-threshold=100%（因此文件必须相同才能被视为重命名）。请注意，您可能会留下一些多余的文件，并且对需要了解其他文件名的文件所做的任何更改都不会记录旧名称（仅是新名称），因此您可能需要返回并修复这些文件已经完成了合并。您还可以将其调整100%为较小的值（默认设置为50%当前会导致问题）。

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

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

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

最后，我建议你玩玩这些选项。在合并上花费的额外时间可能会使最后两个选项无用（甚至变得更糟）。

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

Answer 2

我使用下一个策略。首先，从开发分支签出到其他分支：

  git checkout -b feature/resolve-conflicts

下一步，您必须将代码从 master 拉入功能分支：

  git pull origin master

接下来解决冲突并将功能分支推送到 git 中：

  git add --all
  git commit -am 'resolve conflicts'
  git push -u origin feature/resolve-conflicts

然后创建拉取请求并将功能/解决冲突与主分支进行比较。在不同的平台上，它以不同的方式制作。将功能分支合并到主分支后，然后创建新的拉取请求，将开发分支合并到主分支中。

现在，开发中的更改通常必须通过提交合并到主分支中。

它对我有用，希望我能提供帮助。