如果应该删除文件,'git rm' 是对 'deleted by us' 的规范响应吗?

Is 'git rm' the canonical response to 'deleted by us' if the file should be deleted?

让我们考虑一下这个简短的 git 场景:

(master)>echo 1 > a.txt
(master)>git add a.txt
(master)>git commit -m "Commit 0"
(master)>git checkout -b b
(b)>git rm a.txt
(b)>git commit -m "Deleted a.txt"
(b)>git checkout master
(master)>echo 2 > a.txt
(master)>git commit -am "Modified a.txt"
(master)>git checkout b
(b)>git merge master
CONFLICT (modify/delete): a.txt deleted in HEAD and modified in master. Version master of a.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.

此时状态为:

(b|MERGING)>git status
On branch b
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)

        deleted by us:   a.txt

我的解决方法是git rm a.txt。这会给我我需要的东西,但是,这是 处理这个问题的方法吗?换句话说,有没有一种更具表现力的方式(比如 git merge accept_delete)来处理这个问题?

git checkout a.txt --ours 不起作用,因为 a.txt 在 our 侧不存在)

git rm 是我的首选方法。不过,Git 本身并不关心 如何 你产生结果;它只关心您将正确的分辨率放入 index。让你的工作树也反映你的索引通常是好的,但 Git 不关心这个:那只是为了你自己的理智。

在此特定状态下,文件 a.txt 出现在索引槽 1 和 3 中,而不是索引槽 2 中。槽 1 中 a.txt 的版本是从合并中获取的副本根据。插槽 3 中的版本是从 master 的提示中获取的副本。 a.txtmaster 版本也出现在工作树中。

使用:

rm a.txt
git add a.txt

将首先从工作树中删除 a.txt,然后从索引槽 1 和 3 中删除它,在索引中完全不留下 a.txt,这是您想要的状态。但更简单的是:

git rm a.txt

将从工作树和索引槽 1 和 3 中删除 a.txt,产生完全相同的结果。

所有Git关心的是索引里有什么。槽零条目中的文件——你可以用 git ls-files --stage 查看它们,尽管如果你有很多文件,打印的文本量会令人望而生畏——将在下一次提交中。插槽 1、2、and/or 3 中的文件处于 "conflicted" 状态。这些需要在 git commit 或任何其他提交之前清除,才能继续。

git addgit rm 都删除了冲突状态的条目,所以这两种方法都可以,但是 git add 一个不存在的文件对我来说感觉很奇怪——这种情况得先把它去掉,然后就觉得怪怪的。