git rebase发现冲突时意味着什么,但文件中没有明显问题?相关文件没有冲突标记,git mergetool
表示“无需合并”。
我的选项是重置或添加:
# 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,为什么它们“被修改”,但没有显示冲突标记?
答案 0 :(得分:8)
标记为1
,2
和3
的索引中的版本具有以下含义:
HEAD
中的文件,即合并时的当前提交。HEAD
的提交中的文件。此信息的来源为the git manual's useful section on resolving conflicts。
both modified
中的git status
输出当然表示文件是由于它们的共同祖先所合并的两个提交以不同方式更改的。
对我来说,为什么你没有在文件中看到冲突标记是相当神秘的 - 然而 - blob在git ls-files -s
的输出中有不同的对象名(哈希)表明它们是逐字节的当然确实有不同的内容。如果您对工作副本中的文件感到满意,则可以git add filename.js
然后git rebase --continue
。但是,无论如何,您可能想知道这些差异是什么。为此,我会尝试以下方法:
git diff :2:filename.js filename.js
...这将显示HEAD
中的版本与您当前的工作副本之间的差异。同样,您可以尝试:
git diff :3:filename.js filename.js
...查看正在合并的版本与您的工作副本之间的区别。
答案 1 :(得分:1)
1
的{{1}},2
和3
代表3-way merge的“阶段”:git ls-files -s
是共同的祖先, 1
是当前分支HEAD,2
是另一个分支HEAD。在Linux上,您可以尝试以下命令来查看文件之间的不同之处:
3