当git reset修改HEAD和Staging索引状态时，如何获得可视输出？

出于教育目的，我正在寻找一种方法来直观地演示

git reset

如何修改

HEAD

和分段索引。在

--mixed

和可能

--hard

的情况下，我想获得一个Staging索引的前后视图，以显示它是如何被修改的。

--soft

的情况应表明它保持不变

我一直在使用

git status

演示

git reset

过程，发现当

git status

在“要提交的更改”部分显示挂起的更新时，说“staging index is unchange”会让人感到困惑。我了解到，

git status

并不能代表分级索引的状态，而是Head和索引之间的差异

到目前为止，我一直在使用以下示例进行演示：

git init .
touch reset_lifecycle_file
git add reset_lifecycle_file
git commit -am"initial commit"
echo 'hello git reset' >> reset_lifecycle_file
git commit -am"update content of reset_lifecycle_file"
git log
commit be4aaa98d6976531fdd28aeff52e233087066049
Author: kevzettler <kevzettler@gmail.com>
Date:   Thu Nov 30 15:31:16 2017 -0800

update content of reset_lifecycle_file

commit 5e2d74b369f57929673d873302eb7ebd752c2a95
Author: kevzettler <kevzettler@gmail.com>
Date:   Thu Nov 30 15:20:43 2017 -0800

initial commit

git status
On branch master
nothing to commit, working tree clean

这就是造成混乱的原因。我一直假设“要提交的更改”输出反映了索引的状态，然后假设

--soft

修改了所有Git文档状态都不会发生的索引

我最近发现了

gitshow

和

gitls文件

命令。我想知道这些是否可以更好地用于可视化这里的过程

git show --full-index commit 5e2d74b369f57929673d873302eb7ebd752c2a95
Author: kevzettler <kevzettler@gmail.com> Date: Thu Nov 30 15:20:43
2017 -0800

initial commit

diff --git a/reset_lifecycle_file b/reset_lifecycle_file new file mode
100644 index
0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

git lis-files-s

还有另一个对象，我可以用它来指示索引的更改吗？

---

在本例的这一点上，它与git show的输出中的SHA不同，这是否表明头部处于新索引SHA？

您使用的是

git ls文件

。该命令实际上是指管道。使用

--stage

或

-s

，它列出索引（也称为staging区域）中的每个条目及其哈希ID

这不会显示对索引的更改。索引本身只是一种状态：它是一个文件，其中包含一组文件，如果您运行

git commit

，或者在某些情况下，您必须解决正在进行的冲突，则将提交这些文件。因此，要显示对索引的更改，必须先查看一次，然后对其进行一些更改，然后再查看一次。两个“查看”步骤的两个输出中的不同之处在于这两次之间索引的变化

（有些索引项

git ls files-s

不显示，因为该索引还具有缓存的作用。添加

--debug

会显示文件项的缓存信息，但仍会跳过与文件不对应的特殊缓存项，例如录制扩展名或跟踪未跟踪文件的缓存项。后者听起来像是就像一个自相矛盾的问题，至少有时缓存是缓存未跟踪的文件和/或目录数据，以加速以后的

git状态

。由于所有这些条目都不参与提交，

git ls文件

会跳过它们。）

索引的内部格式很复杂，而且只是半文档化的；请参见Git。但是，外部视图相当简单：对于存储在索引中的每个文件（因此将在下一次提交中），索引具有：

• 模式：

  100644

  或

  100755

  用于任何blob
• 散列（现在是SHA-1，有一天可能会更大）
• 阶段编号：通常为0，但在合并期间可能为1、2或3；1
• 文件的路径名，包括前导目录，例如

  xdiff/xprepare.c

同时，

git show

将提交与其父文件进行比较：它非常类似于

git log-p-1

.2这意味着它不查看索引。您在这里得到的

索引：

行给出了要区分的父文件和子文件的blob哈希

（另外，

git status

实际上显示了两个

git diff

命令的输出：一个用于

HEAD

vs index，一个用于index vs work tree。）

---

1如果存在编号较高的阶段条目，则无法进行任何新的提交。只有在将所有这些条目解析为正常的阶段零条目后，才能进行提交

2如果当前提交是一个合并，

git show

生成一个组合的差异。因此它实际上相当于

git log-p-1--cc

git show --full-index commit 5e2d74b369f57929673d873302eb7ebd752c2a95
Author: kevzettler <kevzettler@gmail.com> Date: Thu Nov 30 15:20:43
2017 -0800

initial commit

diff --git a/reset_lifecycle_file b/reset_lifecycle_file new file mode
100644 index
0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0   reset_lifecycle_file