出于教育目的，我正在寻找一种方法来视觉上证明git reset如何修改HEAD和登台索引。在--mixed的情况下，也许--hard我想在分期索引之前和之后获得一个，以说明如何对其进行修改。--soft的情况应证明其保持不变。
我一直在使用git status来演示git reset进程，并发现当git status显示"要承诺的更改"部分中的"登台索引"不变时，"登台索引是不变的"。我得知git status不是登台索引状态的代表，而是头部和索引之间的差异。
我一直在使用以下示例来演示：
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
如果我执行git重置为第一个提交5e2d74b369f57929673d873302eb7ebd752c2a95
git reset --soft 5e2d74b369f57929673d873302eb7ebd752c2a95
git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: reset_lifecycle_file
这是混乱源于的地方。我一直在假设"要进行的更改"输出反映了索引状态，然后假设--soft正在修改所有GIT文档状态未发生的索引。
我最近发现了git show和git ls-files命令。我想知道是否可以更好地使用这些方法来可视化过程。
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 show --full-index似乎将一些索引对象添加到输出末尾。我可以用它指示重置索引的重置吗？
git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
git lis-files-s有另一个对象，我可以用它来指示索引的更改吗？在示例中的这一点上，它与git show输出中的SHA有所不同，这表明头部在新的索引sha？
您在正确的轨道上使用git ls-files。该命令确实意味着管道。使用--stage或-s，它列出了索引中的每个条目（又称登台区），以及其哈希ID。
这不显示更改为索引。索引本身仅仅是一个状态：它是一个文件，保留如果运行git commit，或者在某些情况下是您必须解决的持续冲突，则将提交的文件集。因此，要显示更改为索引，您必须查看一次，然后对其进行一些更改，然后再次查看它。两个输出与两个"浏览"步骤中有什么不同的是，这两次之间的索引发生了变化。
（git ls-files -s没有显示一些索引条目，因为该索引还具有缓存的角色。添加--debug显示文件条目的缓存信息，但仍然跳过与文件相对应的特殊缓存条目，作为那些记录扩展名或跟踪未跟踪的文件。后者听起来像是自我矛盾，并且有点IS：至少有时，缓存是在缓存未跟踪的文件和/或目录数据以加快git status的速度。这些条目不参与提交，git ls-files跳过它们。）
该索引的内部格式很复杂，只有半文档；请参阅Git的Documentation/technical/index-format.txt文件。但是，外部视图非常简单：对于存储在索引中的每个文件，因此将在下一个提交中，该索引具有：
- 模式：
100644或100755用于任何BLOB; - 哈希（sha-1现在，总有一天可能会更大）;
- 阶段号：通常0，但在合并期间可能是1、2或3; 1
- 文件的路径名，包括领先的目录，例如
xdiff/xprepare.c。
同时，git show将提交与其父的比较：它很像git log -p -1。 2 这意味着它不关注索引。您在这里获得的index:行提供了差异的blob哈希。
（此外，git status实际上显示了两个 git diff命令的输出：一个用于HEAD vs Index，一个用于索引与索引与Work-Tree。）
1 较高的舞台条目的存在阻止了任何新提交。您只能在解决所有这些回到正常的零级条目后才提交。
2 如果当前提交是合并，则git show会产生组合的差异。因此，它实际上等于git log -p -1 --cc。