8

我在我的一个存储库中从 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 路合并/手动合并的错误（我认为该错误消息真的不够通用，无法发布）。Git告诉我执行合并然后使用git rebase --continue完成 - 这永远不会奏效。

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

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

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

谢谢

4

3 回答 3

2

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

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

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

于 2009-10-27T09:54:35.053 回答
2

听起来可能正在发生的是，您已经更改了那些“重复”提交的提交历史记录，使得它们具有不同的 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

完成变基。

于 2011-06-14T22:46:53.757 回答
1

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

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

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

于 2009-08-01T15:30:46.923 回答