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

Question

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

我的存储库设置如下：

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 路合并/手动合并所需的错误（我不认为错误消息是真的很通用，足以发布）。 Git 告诉我执行合并，然后使用 git rebase --continue 来完成 - 这永远不会起作用。

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

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

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

谢谢

Answer 1

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

有关合并管理器的示例，请参阅 这个答案。

其他策略已经讨论过，但是关键仍然是：始终将合并视为“项目范围的合并”，而不是基于文件的合并。 因此，当涉及到某些“特殊”文件时，需要完善项目范围内的合并的属性。

Answer 2

要让 git rebase --Continue 工作，你必须实际合并冲突的文件（编辑它们，从冲突标记“<<<<<<<<之间选择你想要的部分） ;<”, “=======”, “>>>>>>>”），然后 git add 它们到索引（索引是它们被记录为冲突的地方，添加文件会清除其冲突状态）。 使用 git diff --cached 检查当前的 diff，然后使用 git rebase --continue 检查它是否正确。

在尝试变基之前（或中止有问题的变基之后），请查看 git log -p master..deploy 来查看您尝试变基的提交。 这是与您在 master 中所拥有的内容相冲突的其中之一。

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

Answer 3

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

因此，很可能，您从另一个分支重新建立基础，进行某种类型的交互式重新建立基础或修改提交，继续提交更多修改代码同一部分的代码，然后在下一个重新建立基础时，您会发生冲突，因为您的提交本地分支中与您要变基的分支不同的分支将从分支中删除，上游将被拉入，包括您已经拉入并更改了 sha1 的提交，然后当提交重播到分支上时您最终会遇到冲突，因为代码的状态已经与提交的预期发生了变化，因为它最初是根据与您现在分支上的历史记录不同的历史记录创建的。 哇，那是一个很长的句子...

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

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

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

git status

或者

git ls-files -u

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

git mergetool <file>

找到合并标记和行：

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

如果您希望手动合并，则可以通过执行以下操作 存储库路径的顶层并进行编辑。 当您手动编辑时，请确保删除标记并使文件的最终版本看起来像您想要的那样... git 不会为您对标记执行任何特殊操作。 完成手动编辑后，请确保执行

git add <file>

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

git rebase --continue

完成变基操作。