如果应该删除文件,'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.txt
的 master
版本也出现在工作树中。
使用:
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 add
和 git rm
都删除了冲突状态的条目,所以这两种方法都可以,但是 git add
一个不存在的文件对我来说感觉很奇怪——这种情况得先把它去掉,然后就觉得怪怪的。
让我们考虑一下这个简短的 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.txt
的 master
版本也出现在工作树中。
使用:
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 add
和 git rm
都删除了冲突状态的条目,所以这两种方法都可以,但是 git add
一个不存在的文件对我来说感觉很奇怪——这种情况得先把它去掉,然后就觉得怪怪的。