如何使用建议的解决方案解决变基期间的“文件位置”冲突？

Question

CONFLICT (file location): path/to/tests/NS/Domain/Projects/Foo/Bar/stories/workspace-public-channel-SOME_UUID.json added in HEAD inside a directory that was renamed in <some hash> (Reorganize tests), suggesting it should perhaps be moved to path/to/tests/unit/NS/Projects/Foo/Bar/stories/workspace-public-channel-SOME_UUID.json.

我检查了这条消息并确定该建议是正确的。

告诉 git 继续执行的确切咒语是什么？我担心，在这种特殊情况下，一般性建议可能不够，或者可能会把事情搞砸。"git add/rm <conflicted_files>", then run "git rebase --continue"

编辑以澄清：以下是git status具有此冲突类型的示例文件的显示内容：

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

...
...
        deleted:    old/path/to/some/file.spec.js
...
...

稍后在相同的输出中git status：

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
...
...
        added by us:     new/path/to/some/file.spec.js
...
...

这是我尝试执行以下操作时出现的错误消息git mv old/path/to/some/file.spec.js new/path/to/some/file.spec.js：

fatal: bad source, source=old/path/to/some/file.spec.js, destination=new/path/to/some/file.spec.js

Answer 1

\n

告诉 git 继续执行的确切咒语是什么？

\n

\n

问题的形式表明只有一个命令是正确的。事实并非如此。 任何一组在该路径名下的 Git 索引中包含该文件的 Git 命令就足够了。

\n

根据您所展示的内容：

\n

git add new/path/to/some/file.spec.js\n

\n

应该足够了。如果这不起作用，或者出错，请继续阅读。

\n

长的

\n

这里需要理解的是，Git 中深层（或者，不那么浅层？）的魔力是，当合并¹因合并冲突而停止时，Git 所做的就是将冲突保留在 Git\ 的索引中。您现在的工作是修复索引中的混乱情况。

\n

索引也称为暂存区（有时也称为缓存），包含一系列名称和哈希 ID 对，您可以通过以下方式查看：

\n

git ls-files --stage\n

\n

这些名称是将要或将要进入下一次提交的文件的名称。哈希ID是Git的内部标识符，记录了相应的文件内容。

\n

通常，每个条目都位于第 0 阶段，其输出git ls-files --stage如下所示（我仅从 Git 存储库中运行的命令中截取了一些输出）：

\n

git add new/path/to/some/file.spec.js\n

\n

s100644表示文件模式（不可执行），哈希值记录内容，零本身是阶段号，该行的其余部分是路径名，可能包括嵌入的（正向）斜杠，如本例所示文件Documentation/Makefile。

\n

如果现在运行git commit，新提交将恰好包含此处列出的文件集。但是，如果这些阶段编号中的任何一个不为零，git commit则其本身将阻止\xe2\x80\x94fail\xe2\x80\x94 。

\n

运行时git merge，它会扩展索引，填充大量非零阶段号。然后它执行合并，每次成功的合并都会解析一个文件并将其移回阶段零，从而折叠掉非零阶段条目。每次失败的合并都会将非零阶段条目保留在适当的位置。

\n

该git status命令将零阶段路径（即staged for commit）与非零阶段路径分开。暂存槽 #1 中的任何内容都是合并基础文件，来自共享的公共提交。暂存槽 #2 中的任何内容都来自该HEAD提交，暂存槽 #3 中的任何内容都来自另一个提交。

\n

合并操作可以通过接收重命名请求来修改路径名，但文件内容可能来自您的HEAD提交。事实上，他们的提交中可能没有文件，因此暂存槽 #3 是空的，如果文件也不在合并库中，则暂存槽 #1 也将为空。在这种情况下，您将看到该文件列为added by us. 即使路径名以某种方式发生了更改，情况也是如此。

\n

该git add命令告诉 Git：使该路径名的索引条目与相同路径名的工作树文件匹配。这样做的副作用是删除该路径名的任何第 1、2 和 3 阶段条目，从而解决冲突。它会在第 0 阶段添加文件，或者如果工作树中缺少该文件，则仅删除该文件的所有索引条目。无论哪种方式，都不再有任何非零阶段编号条目。

\n

大多数 Git 合并案例都非常简单，但只要有大量重命名，或者目录被重命名，事情就会变得混乱。某些文件的路径名位于old/path/to/file合并库中。它可能old/path/to/file在您自己的提交\xe2\x80\x94中，您正在通过复制git rebase到新的改进的提交\xe2\x80\x94，也可能是third/name/for/file，您想要的路径是new/nameoffile或其他路径。Git 是否以及何时将正确的路径放入某些索引槽中有点不确定。最近有很多工作来改进这一点，根据你引用的消息，我认为你有一个更新的 Git。

\n

不过，您在这里真正需要做的所有（“全部”？）是安排 Git 的索引来保存完整的正确文件名和内容哈希集。无论 Git 索引中的内容是什么，在第 0 阶段，当您运行git rebase --continue. 所有这些有关冲突的内容，由我们添加、由他们添加等等，都只是描述非零暂存槽编号中内容的一种方式。下面显示的所有内容都changes to be committed在暂存槽零中，并且显示在那里是因为它与当前提交中的内容不同HEAD。

\n

另请参见脚注 1，我现在将这个答案称为“完成”并继续编写它（“它”是脚注）。

\n\n

¹你正在跑步git rebase，而不是git merge。但 rebase 使用git cherry-pick, 并git cherry-pick使用 Git 的合并引擎。这里的技巧是，当 rebase 执行每个操作时git cherry-pick，您位于Git 正在就地构建的新分支上，该分支将被重命名为您的分支。这个新分支以与其分支相同的最后一次提交开始，即您要重新定位的分支。因此，当您看到“由我们添加”时，它的意思是“由某人在某个地方从他们开始的地方开始添加”，这可能是他们而不是我们。这是非常混乱的，因为当你在 rebase 中深入进行十或二十次提交时，Git 正在使用的“我们的”或提交是你复制的提交及其原始提交的HEAD十或二十次深度混合。

\n

所有这一切的要点是，您应该少注意有时这里令人讨厌的“我们”和“他们”的明显颠倒，而只专注于通过将每次提交所需的最终快照放在一起来解决冲突。我发现设置也有帮助merge.conflictStyle。diff3

\n