问题描述
在git文档（以及大量SO线程）中，推荐使用这种重置方法：
$ git reset --soft HEAD ^;＃返回WIP状态< 2>
$ git reset< 3>
$ b $显然这很好，但似乎这两个命令可以被替换为
$ git reset HEAD ^
（相当于）
$ git reset --mixed HEAD ^
这应该重置HEAD指针和前一个提交的索引。这个命令和前两个命令的结果有没有区别？如果不是，是否有理由更喜欢两阶段过程？或者只是在文档中以这种方式来明确说明 - 软件的行为？
不， t
这更多的是说明 git reset --soft （即只移动HEAD，它可以）
git reset HEAD 用于unstaging，并且一个简单的 git reset HEAD ^ 可以同时执行（移动HEAD和停用，不需要 - mixed ，因为它是默认选项）
这是一个快速测试，看看是什么样子：
之前（你只需切换回功能，你提交了一个 wip - work in progress）：
C：\ Users \VonC\prog\git\test \r\r3> gl
* 6ac95bd - （master / master，origin / HEAD，master）fix in master（2分钟前）< VonC>
| * fd8d97d - （HEAD，origin / feature，feature）snap WIP（3分钟前）< VonC>
| * 16066dd - f1（3分钟前）< VonC>
| /
* e8ad96f - f1（3分钟前）< VonC>
重设本身：
C：\ Users \VonC\prog\git\test\r\r3> git resetHEAD ^
复位后的不间断更改：
M
这给你的状态：
C：\ Users \VonC\prog\git\test\r\r3> git st
＃在分支功能
＃您的分支由1次提交支持'origin / feature'，并且可以进行快速转发。
＃（使用git pull更新你的本地分支）
＃
＃没有为commit提交的变化：
＃（使用git add< file> ... 更新将提交的内容）
＃（使用git checkout - < file> ...放弃工作目录中的更改）
＃
＃修改：f
$
没有更改添加到提交中（使用git add和/或git commit -a）
$ > git reset HEAD ^
C：\ Users \VonC\prog\git\test\r\r3> gl
* 6ac95bd - （origin / master，origin / HEAD，master）fix in master（6分钟前）< VonC>
| * fd8d97d - （origin / feature）snap WIP（7分钟前）< VonC>
| * 16066dd - （HEAD，feature）f1（7分钟前）< VonC>
| /
* e8ad96f - f1（8分钟前）< VonC>
在两个步骤中，您会看到以下内容在 git reset --soft HEAD ^ ：
C： \Users\VonC\prog\git\test\r\r2> gl
* 6ac95bd - （原点/主，原点/ HEAD，主）在主（65秒前）修复< ; VonC>
| * fd8d97d - （原点/特征）捕捉WIP（89秒前）< VonC>
| * 16066dd - （HEAD，feature）f1（2分钟前）< VonC>
| /
* e8ad96f - f1（2分钟前）< VonC>
您的索引仍然会反映 wip ：
C：\ Users \VonC\prog\git\test\r\r2> ; git st
＃在分支特性
＃你的分支在1提交后落后于'origin / feature'，并且可以被快速转发。
＃（使用git pull更新您的本地分支）
＃
＃要提交的更改：
＃（使用git reset HEAD< file> ... to unstage）
＃
＃modified：f
＃
重置然后unstaged，使您回到同一阶段比 git重置HEAD ^ 将有一步：
C：\ Users \VonC\prog\git\test\r\r2> git reset
复位后的不间断更改：
M f
C：\ Users \VonC\prog\git\test\r\r2> git st
＃在分支特征
＃你的分支在1次提交后落后于'origin / feature'，并且可以被快速转发。
＃（使用git pull更新你的本地分支）
＃
＃没有为commit提交的变化：
＃（使用git add< file> ... 更新将提交的内容）
＃（使用git checkout - < file> ...放弃工作目录中的更改）
＃
＃修改：f
$
没有更改添加到提交中（使用git add和/或git commit -a）
In the git docs (and numerous SO threads) this reset approach is recommended:
$ git reset --soft HEAD^ ;# go back to WIP state <2>
$ git reset <3>
https://www.kernel.org/pub/software/scm/git/docs/git-reset.html
Obviously that's fine, but it seems that these two commands could be replaced by
$ git reset HEAD^
(which is equivalent to)
$ git reset --mixed HEAD^
which should reset both the HEAD pointer and the index to the previous commit. Is there in fact a difference between the result of this command and the previous two? If not, is there some reason to prefer the two-stage process? Or was it just done that way in the docs to explicitly illustrate the behavior of --soft?
No, there doesn't seem to be any difference.
It is more to illustrate the git reset --soft (i.e. moving HEAD only, which can have other more practical uses)
git reset HEAD is for "unstaging", and a simple git reset HEAD^ does both (move the HEAD, and unstage, no need for --mixed, since it is the default option)
Here is a quick test to see what that looks like:
Before (you just switch back to feature, where you committed a "wip" -- work in progress):
C:\Users\VonC\prog\git\test\r\r3>gl
* 6ac95bd - (origin/master, origin/HEAD, master) fix in master (2 minutes ago) <VonC>
| * fd8d97d - (HEAD, origin/feature, feature) snap WIP (3 minutes ago) <VonC>
| * 16066dd - f1 (3 minutes ago) <VonC>
|/
* e8ad96f - f1 (3 minutes ago) <VonC>
The reset itself:
C:\Users\VonC\prog\git\test\r\r3>git reset "HEAD^"
Unstaged changes after reset:
M f
That gives you the status:
C:\Users\VonC\prog\git\test\r\r3>git st
# On branch feature
# Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded.
# (use "git pull" to update your local branch)
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: f
#
no changes added to commit (use "git add" and/or "git commit -a")
log after git reset HEAD^
C:\Users\VonC\prog\git\test\r\r3>gl
* 6ac95bd - (origin/master, origin/HEAD, master) fix in master (6 minutes ago) <VonC>
| * fd8d97d - (origin/feature) snap WIP (7 minutes ago) <VonC>
| * 16066dd - (HEAD, feature) f1 (7 minutes ago) <VonC>
|/
* e8ad96f - f1 (8 minutes ago) <VonC>
In two steps, you would have seen the following log after the git reset --soft HEAD^:
C:\Users\VonC\prog\git\test\r\r2>gl
* 6ac95bd - (origin/master, origin/HEAD, master) fix in master (65 seconds ago) <VonC>
| * fd8d97d - (origin/feature) snap WIP (89 seconds ago) <VonC>
| * 16066dd - (HEAD, feature) f1 (2 minutes ago) <VonC>
|/
* e8ad96f - f1 (2 minutes ago) <VonC>
You index would still reflect what was staged for wip:
C:\Users\VonC\prog\git\test\r\r2>git st
# On branch feature
# Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded.
# (use "git pull" to update your local branch)
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: f
#
The reset would then unstaged, bringing you back to the same stage than a git reset HEAD^ would have in one step:
C:\Users\VonC\prog\git\test\r\r2>git reset
Unstaged changes after reset:
M f
C:\Users\VonC\prog\git\test\r\r2>git st
# On branch feature
# Your branch is behind 'origin/feature' by 1 commit, and can be fast-forwarded.
# (use "git pull" to update your local branch)
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: f
#
no changes added to commit (use "git add" and/or "git commit -a")
这篇关于为什么在git reset之前显式调用git reset --soft（--mixed）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！