62

故事：在一个项目的中间，我的同事从master创建了一个新分支，并开始做她繁重的重构工作。我从master创建了我的分支，并开始在页面上做新的东西。我们定期提交，但只有我可以将代码 rebase 到master（因为同事更改太重，还不能从 master 部署）。不幸的是，我们的一些工作依赖于相同的文件。因此，经过几天的工作，当她终于想将她的更改重新设置为master时，她遇到了很多 git 冲突。

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                                                     /
her branch   #------#-------#-----------#-----------#------------#

问题 1 是：当我们处理相同的文件时，如何防止大量 git 冲突？（或者在这种情况下最好的做法是什么？）

但这不是我们问题的结束，......绝对正确，她试图从 master 到她的分支进行变基（我提交了更改），所以提交映射应该看起来像这样

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                   \            \                    /
her branch   #------#-------#----*------#-----*-----#------------#

这就是困扰我们的地方。在这些变基期间，她正在解决这些冲突。但是 git 不记得她对冲突修复的决定，所以当她从master到her-branch进行另一个 git rebase 时，她必须再次修复她在以前的 rebase 中修复的相同 git 冲突。

问题 2 是：如何告诉 git 在 git rebase 从master分支之后记住 git conflict fix，所以在下一次 rebase 之后我们不必再次修复相同的冲突？

4

4 回答 4

77

幸运的是，git 有一种机制可以准确地处理这个问题git rerere——本质上，如果你git rerere启用了，那么每次你解决冲突时，都会记住你以特定方式解决了确切冲突的事实。如果再次出现相同的冲突，则会自动使用相同的解决方案。下面有一些有用的文章：

...但基本上你可以这样做：

git config --global rerere.enabled 1

...并忘记它，同时享受更轻松的变基/合并:)

于 2011-08-30T10:20:56.350 回答
4

确保您始终使用--onto开关进行变基。

为防止冲突，请使用浮动开发分支。每个开发人员都会不断地重新调整他们的开发分支。这很容易，因为开发人员知道他刚刚实现了什么并且不应该有解决冲突的问题。而不是变基，只需合并最终版本（它已经变基）。

于 2011-08-30T10:21:54.533 回答
1

您可以挤压她的分支以防止连续冲突解决。当您在从 master 创建到一个提交后将她的分支中的所有提交压缩时，则可以一步解决冲突。

如果您想从头开始编写新的提交消息，这就足够了：

git reset --soft HEAD~3 &&
git commit

在此示例中，我们将压缩最后 3 次提交。

为防止将来出现此问题，我建议您在每次提交后使用源分支重新定位您的分支。

于 2020-07-13T02:41:38.217 回答
1

让我分享一种解决变基冲突的可能方法。我称它为rebase via merge。如果您想重新设置具有许多提交并且预期会有许多冲突的分支，它会有所帮助。

首先，让我们创建一个temp分支并强制所有冲突通过常规合并显示

git checkout -b temp
git merge origin/master

以常规方式解决所有冲突并完成合并。

因此，temp分支现在显示了正确解决所有冲突后项目的外观。

现在让我们检查您未触及的分支（顺其自然alpha）。

git checkout alpha

并使用机械冲突自动解决进行变基以支持当前分支。

git rebase origin/master -X theirs

此时项目代码可能已损坏或无效。没关系，最后一步是temp通过一个额外的提交从分支恢复项目状态

git merge --ff $(git commit-tree temp^{tree} -m "Fix after rebase" -p HEAD)

temp基本上，这一步使用低级 git 命令创建一个与分支完全相同的项目状态（树）的新提交。并且该新提交将立即合并。

就是这样。我们刚刚通过隐藏合并做了一个变基。并且temp可以删除分支。

git branch -D temp

此外，还有一个脚本可以交互地执行相同的操作。可以在这里找到。

于 2021-12-14T23:02:42.470 回答