5

我开始了一个工作流程，我的目标是在一个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无需查看和解决每个更改？

4

4 回答 4

7

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

有许多不同的合并算法git可供选择，因此我们将使用最简单、易于定制且通常默认使用的一种：递归策略。我们将强制它与 option 一起使用-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记录您手动解决的冲突的功能，然后学习如何在以后为您自动解决这些相同的冲突。因此，一旦您解决了一次，您就不必再次解决相同/相似的冲突。

于 2014-12-23T15:40:41.360 回答
4

使用git merge选项，称为“策略” -s ours（或他们的）。这意味着 git 将更喜欢来自开发分支（或来自 master）的更改。这意味着，如果您在 master 和 staging 中对一个代码字符串进行了不同的更改，那么它将进行 staging 更改。另外，我建议您使用 --no-commit 选项，这样您就可以在提交合并之前检查一次代码（不是每次更改）。

于 2014-12-23T16:26:58.877 回答
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

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

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

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

于 2021-02-03T08:03:46.120 回答
1

这是一个非常常见的问题，并且有一个简单的解决方案。一旦发生合并冲突，您可以通过以下方式逐个文件执行此操作

Keep master's file
git checkout --ours myfile.html

Keep development's file
git checkout --theirs myfile.html

您可以很容易地将其应用于整个文件夹

git checkout --ours ./
git checkout --theirs ./

这比 a 更好，git merge因为您也可以看到冲突的文件。更多细节在这里https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html

于 2014-12-30T14:09:29.157 回答