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

Question

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

我的仓库设置如下：

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. 在主分支上进行开发...测试、微笑、提交。
2. 查看deploy 分支
3. 在部署分支上执行git rebase master - 这曾经可以毫无问题地工作
4. 推送到远程然后执行cap deploy
5. 放松

我现在遇到的问题是，当我在部署分支上执行 git rebase master 时，它会出现 3-way merge/manual merge required 错误（我认为错误消息不够通用邮政）。 Git 告诉我执行合并，然后使用 git rebase --continue 完成 - 这永远不会奏效。

我发现“做”的工作正在运行 git rebase master --interactive，清理选择列表（有 5 个左右重复的“提交”，但在此列表中具有不同的参考编号（相同的消息），所以我会选择其中之一），然后手动进行合并。一旦我为每个提交完成了此操作，我就可以继续 rebase 并且一切顺利......

直到下一次我需要执行变基。

那么有谁知道什么是快乐的？该项目并不是真正的“秘密”，所以如果需要，我可以发布消息、日志、分支图等。

谢谢

Answer 1

听起来可能发生的事情是您更改了那些“重复”提交的提交历史记录，使得它们具有不同的 sha1。每个 sha1 不仅对提交是唯一的，而且对提交历史也是唯一的。因此，不可能（好吧，极不可能发生在宇宙的生命周期中）在同一历史中拥有两个相同的 sha1，甚至在两个不同的历史中拥有两个 sha1。如果您更改提交中的任何内容，例如修改或交互式变基，那么您将更改 sha1.所以看起来相同的两个提交实际上是不同的。

所以很可能，您从另一个分支进行了 rebase，进行了某种类型的交互式 rebase 或修改了提交，继续提交了一些修改相同部分代码的更多代码，然后在下一次 rebase 时您会发生冲突，因为您在本地分支中与您正在变基的分支不同的提交从分支中删除，上游被拉入，包括您已经拉入并更改了 sha1 的提交，然后在重播提交时到分支上，您最终会发生冲突，因为代码的状态已与预期的提交不同，因为它最初是从与您现在在分支上的不同历史创建的。哇，好长的一句话……

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

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

要查找哪些文件存在合并冲突，请执行以下操作：

git status

或

git ls-files -u

一旦你知道哪些文件有冲突，如果你有一个 mergetool 设置，你可以这样做：

git mergetool <file>

如果您想手动合并，您可以通过以下方式找到合并标记和行：

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

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

git add <file>

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

git rebase --continue

完成rebase。

Answer 2

要让git rebase --continue 工作，您必须实际合并冲突文件（编辑它们，从冲突标记“>>>>>>”）然后将git add它们添加到索引中（索引是它们被记录为冲突的位置，添加文件会清除其冲突状态）。用git diff --cached 检查当前的差异，然后用git rebase --continue 检查它是否正确。

在您尝试变基之前（或中止有问题的变基后），请查看git log -p master..deploy 以查看您尝试变基的提交。它是其中之一，与您在 master 中的任何内容发生冲突。

您通过删除 git rebase -i 中的“选择”行而删除的那些提交可能不完全相同（即使它们在提交消息中具有相同的“主题”）。您认为应该只有其中一个的事实表明您的 deploy 分支发生了一些可疑的事情。这些“重复”提交是在 deploy 的尖端还是在它们之后还有其他提交？也许看到那些“可疑”提交的内容（log -p，上面）会给你一个关于它们来源的线索。

Answer 3

您可以在“部署特定”文件的父目录中定义attribute，以便在合并时始终选择部署分支的内容。

有关合并管理器的示例，请参阅this SO answer。

其他strategies have been discussed，但关键仍然存在：始终将合并视为“项目范围的合并”，而不是基于文件的合并。因此，当涉及到一些“特殊”文件时，这些属性可以优化项目范围的合并。