故事：在项目中间，我的同事从 master 创建了一个新分支，并开始进行重度重新分解工作。我从 master 创建了我的分支，并开始在页面上做新的东西。我们定期提交，但只有我可以将代码重新绑定到 master （因为同事的更改太重，无法从master部署）。不幸的是，我们的一些工作依赖于相同的文件。因此，经过几天的工作，她终于想要改变她对 master 的更改，她有很多git冲突。
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ /
her branch #------#-------#-----------#-----------#------------#
问题1 ：当我们处理相同的文件时，如何防止大量的git冲突？ （或者在这种情况下最佳做法是什么？）
但这不是我们问题的终点，...绝对正确她试图从master到她的分支进行rebase（为了进行我提交的更改），所以提交映射应该看起来像这样
my_branch #---#----#-#-------#----#--#-----#---#----#----#
/ \ \ \ \ \ \
master *-------*--------------*---*---*--------------*----*----*
\ \ \ /
her branch #------#-------#----*------#-----*-----#------------#
这就是困扰我们的事情。在这些改变期间，她正在解决这些冲突。但是git不记得她关于冲突修复的决定，所以当她从 master 到她的分支做另一个git rebase时，她必须修复相同的git冲突再次她正在修复之前的重组。
问题2 ：如何告诉git在 master 分支的git rebase之后记住git冲突修复，所以在下一个rebase之后我们不必修复它再次发生冲突？
答案 0 :(得分：49)
幸运的是，git有一个机制来处理这个名为git rerere的问题 - 实际上，如果你启用了git rerere，那么每当你解决冲突时你就解决了这个问题。记住一种特殊的方式。如果再次出现相同的冲突，则会自动使用相同的分辨率。下面有一些有用的文章：
...但基本上你可以这样做：
git config --global rerere.enabled 1
......忘了它，同时享受更容易的变基/合并：）
答案 1 :(得分：2)
确保始终使用--onto开关进行变基调。
为防止冲突，请使用浮动开发分支。每个开发人员都将不断改进他们的开发分支。这很容易，因为开发人员知道他刚刚实现了什么，并且不应该解决冲突问题。而不是重新定位，只需合并最终版本（它已经被重新定位）。
答案 2 :(得分：0)
您可以挤压她的分支以防止连续冲突解决。从母版创建为一次提交后，如果将其所有提交压缩到其分支中，则可以一步解决冲突。
如果您想从头开始编写新的提交消息，则足以：
git reset --soft HEAD~3 &&
git commit
在此示例中，我们将压缩最后3次提交。
为防止将来出现此问题，建议您在每次提交后使用源分支重新建立分支。