在`git rebase`期间有很多合并冲突

问题描述

很好奇，

如果我正在分支A上进行一次提交

另一个人正在分支master上工作，并添加/更改了大量代码

在完成rebase --continue之后，我必须经历另一个人所做的所有更改，做出合理的选择，我应该保留哪些更改，删除哪些更改，这就是

不是很多工作吗？考虑到这样做的好处只是删除重复的提交。

解决方法

要考虑的一些要素是：

1. 自分叉点以来，有多少个提交将A和master分开了
   如果在A上有8次提交，则有8次提交要重新应用在master之上，还有更多的情况触发冲突
2. 在A上更改了多少文件
   同样，如果您所做的更改/ A上的更改影响了50个文件，则发生冲突的机会要比仅影响5个文件时高。

---

关于1.的一个注释：如果出于某种原因，分支A（或master）是使用编辑历史记录的命令（例如：git rebase -i HEAD~5）删除的， 5之前犯的错误，或者git filter-branch从所有历史记录中删除了某些内容……），那么所谓的“叉点”将在历史记录中上升。

检查您的A分支的历史记录与master的历史记录：如果您真正需要重新设置基准的唯一事情是单次提交git cherry-pick mycommit（从{{1}开始运行） }）就足够了。

---

关于解决冲突：一些工具可帮助您“更快地合并”。

例如：master有一个meld选项。
您可以将其设置为默认的合并工具（改编自this blog post）：

--auto-merge

我还没有阅读所有其他合并工具（# in your ~/.gitconfig,add the following entries : [merge] tool = meldauto [mergetool "meldauto"] cmd = meld --auto-merge \"$LOCAL\" \"$BASE\" \"$REMOTE\" --output \"$MERGED\" --label \"MERGE (REMOTE BASE MY)\" trustExitCode = false ，kdiff3，...）的文档，但是您可能也找到了等效的选择。

,

如果您的分支上只有1次提交-A，则： （如果大于1，则将您的提交压缩为1次提交。或者您可以1挑选1）

1. 在分支中复制您的简短提交ID
2. 以A1创建另一个分支->通过git cherry-pick commit_id
选择您的提交
3. 删除A并将分支A1重命名为A，或者您只使用新的分支A1