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

时间:2009-08-01 15:22:16

标签: git branch rebase

我遇到了从master到我的某个存储库中的'deploy'分支的基础问题。

我的回购设置如下:

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. 放松
  6. 我现在遇到的问题是,当我在部署分支上执行git rebase master时,它会出现3路合并/手动合并所需的错误(我不认为错误消息真的是通用的足以发布)。 Git告诉我执行合并然后使用git rebase --continue来完成 - 这从不起作用。

    我发现'确实'工作正在运行git rebase master --interactive,清理选择列表(此列表中有5个左右重复的'提交'但具有不同的引用号(相同的消息),所以我' ll选择其中之一)然后手动进行合并。一旦我为每次提交完成了这个,那么我就可以继续使用rebase,并且很高兴......

    直到下次我需要执行rebase。

    所以有人知道什么可能会幸福吗?该项目并非真正“秘密”,所以如果需要,我可以发布消息,日志,分支图等。

    谢谢

3 个答案:

答案 0 :(得分:2)

要让git rebase --continue工作,您必须实际合并冲突的文件(编辑它们,从冲突标记之间选择您想要的部分“<<<<<<<<<< ,“=======”,“>>>>>>>”)然后将git add指向索引(索引是记录为冲突的位置,添加文件会清除其冲突状态)。使用git diff --cached检查当前差异,如果看起来正确,则检查git rebase --continue

在您尝试使用rebase之前(或在中止有问题之后),请查看git log -p master..deploy以查看您尝试重新绑定的提交。其中一个与 master 中的任何内容相冲突。

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

答案 1 :(得分:1)

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

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

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

答案 2 :(得分:1)

听起来可能发生的事情是你已经改变了那些“重复”提交的提交历史记录,使得它们具有不同的sha1。每个sha1不仅对提交而且对提交历史是唯一的。因此,在宇宙的一生中,这是不可能的(嗯,非常不可能发生),在同一个历史中有两个同意的sha1,或者在两个不同的历史中有两个sha1。如果您在提交中更改了任何内容,例如修改或交互式rebase,那么您将更改sha1。因此,两个可能看起来相同的提交实际上是区别对待的。

所以非常有可能,你从另一个分支重新定义,做了某种类型的交互式rebase或修改了提交,继续提交了一些代码来修改代码的相同部分,然后在下一个rebase你有冲突,因为您在本地分支中具有的与您正在重新分支的分支不同的提交将从分支中删除,上游将被拉入,包括您已经提交的提交并更改了sha1,然后在重放提交时在分支上,您最终会遇到冲突,因为代码的状态已经从提交预期更改,因为它是从与您现在在分支上的历史记录不同的历史记录创建的。哇,那句话很长......

当您“清理”选择列表时......您正在做的事情可能是在重新定位之前删除这些重复的提交,所以现在您不会重新应用已经应用的更改,因此不会再发生冲突。< / p>

但是,如果您只是想在rebase期间解决冲突,这可能是最好的选择,因此您不会意外删除您想要的提交。解决冲突将使该提交的更改集适用于您拥有的历史记录。一旦推动此合并冲突解决方案,除非您修改已经再次推送的提交,否则不应再次看到问题。

要查找合并冲突的文件:

git status

git ls-files -u

一旦您知道哪些文件存在冲突,如果您有合并工具设置,则可以执行以下操作:

git mergetool <file>

如果您想手动合并,可以通过执行以下操作找到合并标记和行:

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

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

git add <file>

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

git rebase --continue

完成rebase。