没有合并的Git rebase冲突？

当git rebase发现冲突时，这意味着什么，但文件中没有明显问题？有问题的文件没有冲突标记，并且git mergetool说“没有合并”。没有合并的Git rebase冲突？

的选项我已经被重置或添加：

# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 
# both modified:  filename.js

如何才能知道这是怎么回事，并采取哪些路径？

git ls-files -s filename.js给出3行：

100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1 filename.js 
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2 filename.js 
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3 filename.js

根据该细手册中，该命令告诉我们模式位，对象名称和阶段数。模式位是相同的。那么，什么是1,2和3，为什么他们“都是修改过的”，但没有显示冲突标记？

来源

2011-10-26 Andrew Vit

它可能是空白区别。 – birryree

尝试'git ls-files -s filename.js'来查看版本是否确实不同。 –

@JoshLee我更新了我的问题以回应您的评论。输出结果显示了3个blob，但我不知道该从哪里去，我如何找到差异，或者告诉哪个是“添加”或“重置”？ –

索引中的版本标记1，2和3具有以下含义：

因为它是在你合并这两个提交的共同祖先文件。
该文件为HEAD，即您在合并时执行的当前提交。
该文件在您尝试合并到HEAD的提交中。

我的源代码是the git manual's useful section on resolving conflicts。

的both modified输出git status表示，当然，该文件已通过，因为他们的共同祖先，你合并这两个提交不同的方式改变。

对我而言，为什么在文件中看不到冲突标记，这是相当神秘的 - 但是，在输出git ls-files -s的输出中blob具有不同的对象名称（散列），这表明它们确实有字节接一个字节不同的内容。如果您对工作副本中的文件感到满意，则可以仅执行git add filename.js，然后执行git rebase --continue。但是，无论如何，你可能想知道这些差异是什么。为了做到这一点，我会尝试以下方法：

git diff :2:filename.js filename.js

...这将显示版本之间HEAD和你当前的工作副本的差异。同样，您可以尝试：

git diff :3:filename.js filename.js

...查看合并版本与您的工作副本之间的区别。

来源

2011-10-27 11:20:37

的1，2和git ls-files -s3表示一个3-way merge的“阶段”：1是共同的祖先，2是当前分支HEAD和3是另一分支HEAD。在Linux上，您可以尝试以下命令以查看文件中的不同之处：

$ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps 
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps 
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps

来源

2011-10-27 14:35:22

没有合并的Git rebase冲突？

回答

相关问题