如何在重新提交许多提交时防止许多 git 冲突？
故事：在一个项目的中间，我的同事从 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 之后我们不必再次修复相同的冲突？
git merge 而不是 git rebase。是的，有些人说使用 merge 您没有正确的历史记录，这是不正确的。观看 youtube.com/watch?v=1ffBJ4sVUb4 以了解 git 中的一切是如何工作的（+ rebase 实际上可能具有破坏性）我的观点是 git merge 更有效率。我想这就是为什么 github 在处理拉取请求时也在他们的 Web 界面中使用 merge 的原因
merge 更加务实，否则每个人 10% 的时间将只是解决 rebase 冲突
幸运的是，git 有一种机制可以准确地处理这个问题，称为 git rerere - 本质上，如果您启用了 git rerere，那么每次您解决冲突时，都会记住您以特定方式解决该确切冲突的事实。如果再次出现相同的冲突，则会自动使用相同的解决方案。下面有一些有用的文章：
http://scottchacon.com/2010/03/08/rerere.html（博文）
http://git-scm.com/docs/git-rerere.html（手动输入）
启用 git rerere 有什么缺点吗？ （stackoverflow中的问题）
http://progit.org/2010/03/08/rerere.html （原始答案链接：似乎坏了）
...但基本上你可以这样做：
git config --global rerere.enabled 1
...并忘记它，同时享受更轻松的变基/合并:)
让我分享一种解决变基冲突的可能方法。我通过合并将其称为变基。如果您想重新设置具有许多提交并且预期会有许多冲突的分支，它会有所帮助。
首先，让我们创建一个 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)
基本上，此步骤使用低级 git 命令创建一个与 temp 分支具有完全相同的项目状态（树）的新提交。并且该新提交将立即合并。
而已。我们刚刚通过隐藏合并做了一个变基。并且可以删除 temp 分支。
git branch -D temp
此外，还有一个脚本可以交互地执行相同的操作。它可以在 here 中找到。
确保您始终使用 --onto 开关进行变基。
为防止冲突，请使用浮动开发分支。每个开发人员都会不断地重新调整他们的开发分支。这很容易，因为开发人员知道他刚刚实现了什么并且不应该有解决冲突的问题。而不是变基，只需合并最终版本（它已经变基）。
您可以挤压她的分支以防止连续冲突解决。当您在从 master 创建到一个提交后将她的分支中的所有提交压缩时，则可以一步解决冲突。
如果您想从头开始编写新的提交消息，这就足够了：
git reset --soft HEAD~3 &&
git commit
在此示例中，我们将压缩最后 3 次提交。
为防止将来出现此问题，我建议您在每次提交后使用源分支重新定位您的分支。
如果 2 个开发人员对同一行代码进行了不同的更改，冲突将不可避免，因为 git 将不知道应该保留或丢弃哪个喜欢。
至于来自 master 的 rebase，这确实不是理想的做法，除非您想故意更改提交历史记录（并可能更改您同事的提交历史记录）。
来自官方文档 about rebasing：
不要 rebase 存在于您的存储库之外并且人们可能已经基于工作的提交。
您应该改用 git merge。
https://i.stack.imgur.com/lfZnC.png
关注公众号
不定期副业成功案例分享
git config --global rerere.autoupdate true。此外，如果您希望团队中的其他人使用这些记录的解决方案，您可以与他们共享您的 .git/rr-cache 文件夹。干杯。