时间戳

首页 > 解决方案 > 如果文件应该被删除，“git rm”是对“我们删除”的规范响应吗？

git - 如果文件应该被删除，“git rm”是对“我们删除”的规范响应吗？

问题描述

让我们考虑一下这个简短的 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不起作用，因为our旁边不存在 a.txt）

标签： gitgithubgit-merge

解决方案

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

在这种特定状态下，文件a.txt出现在索引槽 1 和 3 中，而不是索引槽 2 中a.txt。槽 1 中的版本是从合并库中获取的副本。插槽 3 中的版本是从master. 这个master版本也a.txt出现在工作树中。

使用：

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 和/或 3 中的文件处于“冲突”状态。这些需要在 之前清除git commit，否则任何其他提交的内容都可以继续进行。

两者都git add删除git rm冲突状态条目，因此任何一种方法都可以，但是对于git add不存在的文件对我来说感觉很奇怪-对于这种情况，您必须先将其删除，然后才感觉很奇怪。

推荐阅读