答案 0 :(得分:6)
我同意文件不是很清楚。从测试中,我发现了三个不同之处,与文件发生的情况有关:
总结:
reset --merge
总是丢弃索引(分阶段更改);如果任何文件中存在未分级和暂存的更改,则中止reset --keep
保留,但不停止索引;如果重置目标触及相同的文件,则中止测试场景:
echo First > file.txt
git add file.txt
git commit -m 'first'
git tag v1
echo Second >> file.txt
git commit -am 'second'
git tag v2
echo New > newfile.txt
git add newfile.txt
git commit -m 'third'
git tag v3
echo 'More stuff' >> file.txt
git add file.txt
我们现在有三个提交,'file.txt'在v1和v2之间发生变化,但在提交v2和v3之间没有变化。
在这种情况下:
git reset --merge v2
抛弃了这些变化git reset --keep v2
会保留它们,但不会让它们失效。如果我们改为尝试重置为v1:
git reset --merge v1
抛弃了更改 git reset --keep v1
拒绝:
error: Entry 'file.txt' would be overwritten by merge. Cannot merge.
fatal: Could not reset index file to revision 'v1'.
git echo "Even more things" >> file.txt
现在,两者都失败了,但错误消息略有不同:
git reset --merge v1
error: Entry 'file.txt' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'v1'.
git reset --keep v1
error: Entry 'file.txt' would be overwritten by merge. Cannot merge.
fatal: Could not reset index file to revision 'v1'.
echo Unrelated > unrelated.txt
git add unrelated.txt
echo Stuff >> unrelated.txt
现在这有些奇怪:
git reset --merge v1
error: Entry 'unrelated.txt' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'v1'.
git reset --keep v1
两组更改都保留,但未分期。
为了完整性,这两者的行为相同:重置成功,文件保持未分阶段。
答案 1 :(得分:3)
处理合并冲突时它们是不同的,例如这会产生冲突
git init
echo 333 > foo.txt
git add foo.txt
git commit -m 333
git checkout -b feature
echo 444 > foo.txt
git commit -am 444
git checkout master
echo 555 > foo.txt
git commit -am 555
git merge feature
然后
$ git reset --keep
fatal: Cannot do a keep reset in the middle of a merge.
$ cat foo.txt
<<<<<<< HEAD
555
=======
444
>>>>>>> feature
对战
$ git reset --merge
$ cat foo.txt
555