Git rebase 不断失败，需要手动 merge 干预

Question

我在从 master rebase 到我的一个存储库中的“部署”分支时遇到问题。

我的仓库设置如下:

master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master

通常我的工作流程是:

1. 在 master 分支上进行开发...测试、微笑、提交。
2. 检查部署分支
3. 在部署分支上执行 git rebase master - 这曾经没有问题
4. 推送到远程然后执行cap deploy
5. 放松

我现在遇到的问题是，当我在部署分支上执行 git rebase master 时，出现了 3-way merge/manual merge required 错误(我不认为错误消息真的很通用，可以发布)。 Git 告诉我执行 merge ，然后使用 git rebase --continue 完成 - 这永远行不通。

我发现“有效”的是运行 git rebase master --interactive，清理选择列表(有 5 次左右重复的“提交”，但引用编号不同(相同的消息) 在此列表中，因此我将选择其中之一)，然后手动进行 merge 。一旦我为每次提交完成了这个，我就可以继续 rebase 并且一切顺利......

直到下次我需要执行 rebase 。

那么有谁知道什么是幸福的呢？该项目并不是真正的“ secret ”，因此如果需要，我可以发布消息、日志、分支图等。

谢谢

Answer 1

听起来可能正在发生的事情是您更改了那些“重复”提交的提交历史，使它们具有不同的 sha1。每个 sha1 不仅对提交而且对提交历史都是唯一的。因此，不可能(好吧，在宇宙的生命周期中极不可能发生)，在同一历史中有两个相同的 sha1，或者甚至在两个不同的历史中有两个 sha1。如果您在提交中更改任何内容，例如修改或交互式 rebase ，那么您将更改 sha1。因此，看起来可能相同的两个提交实际上被区别对待。

所以很有可能，你从另一个分支 rebase ，做了某种类型的交互式 rebase 或修改了提交，继续提交了一些修改代码的相同部分的代码，然后在下一个 rebase 时你有冲突，因为您在本地分支中拥有的与您要重新定位的分支不同的提交将从分支中删除，上游被 pull 入，包括您已经 pull 入并更改其 sha1 的提交，然后在重播提交时到分支上你最终会遇到冲突，因为代码的状态已经从提交的预期中改变，因为它最初是根据与你现在在你的分支上不同的历史创建的。哇，好长的一句话……

当您“清理”选择列表时...您所做的很可能是在 rebase 之前删除这些重复的提交，所以现在您不会重新应用已经应用的更改，因此不会再有冲突。

但是，如果您只是想在 rebase 期间解决冲突，这可能是最好的选择，这样您就不会意外删除您想要的提交。解决冲突将使该提交的更改集与您拥有的历史记录不同。推送此 merge 冲突解决方案后，除非您修改已经再次推送的提交，否则您不应该再次看到这些问题。

要查找哪些文件有 merge 冲突，请执行以下操作:

git status

或

git ls-files -u

一旦您知道哪些文件存在冲突，如果您有 mergetool 设置，您可以执行以下操作:

git mergetool <file>

如果您更愿意手动 merge ，您可以通过执行以下操作找到 merge 标记和行:

grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *

在您的 repo 路径的顶层并编辑。当你手动编辑时，确保你删除了标记并使文件的最终版本看起来像你想要的那样......git 不会为你做任何特殊的标记。手动完成编辑后，请务必执行

git add <file>

添加文件将其添加到索引并移除未 merge 标志。完成所有未 merge 文件的解析后，执行

git rebase --continue

完成 rebase 。