为什么在git reset之前显式调用git reset --soft（--mixed） [英] Why explicitly call git reset --soft before git reset (--mixed)

问题描述

在git文档（以及大量SO线程）中，推荐使用这种重置方法：

  $ git reset --soft HEAD ^;＃返回WIP状态< 2> 
 $ git reset< 3> 
  

.2。这将从提交历史中删除WIP提交，并将您的工作树设置为您创建该快照之前的状态。

.3。此时，索引文件仍具有作为快照在制品提交的所有WIP更改。这会更新索引以将您的WIP文件显示为未提交。

https://www.kernel.org/pub/software/scm/git/docs/git-reset.html

$ 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>

.2. This removes the WIP commit from the commit history, and sets your working tree to the state just before you made that snapshot.

.3. At this point the index file still has all the WIP changes you committed as snapshot WIP. This updates the index to show your WIP files as uncommitted.

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）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！