Git 读取树命令用法的基本示例

我有一个a文件，得到了一个解决方案，其中包括两个git命令-

git read tree-I HEAD

和

git checkout index-a-f

。我似乎已经弄明白了第二种方法的作用并对其进行了测试，但我无法理解为什么即使在最简单的情况下也需要第一种方法。我认为它可以以某种方式取代git add命令并将文件添加到索引中，但是，当我创建一个新文件并运行该命令，然后用ls files检查索引的内容时，staged并没有将此文件显示为添加的文件，因此我对该命令用途的假设可能是错误的。我也访问了，但仍然不明白为什么我需要这个命令。

git read tree

如下所示：

解析传递给它的“tree-ish”，以查找Git存储库中描述树的对象

在Git中，树表示目录：这种对象列出了组成树的BLOB（文件）和嵌套树（嵌套目录）的SHA-1和文件系统名称。每个提交只引用一棵树，该树表示顶级项目目录本身的状态

“tree-ish”是Git能够解析到树对象名称的规范。例如，

HEAD

首先解析为引用的名称，然后追踪它所指向的分支以获取其tip commit，然后解析它以获取其树对象的名称

递归读取获取的树对象，并用这些对象的信息填充索引。该索引不包含文件的实际数据，只包含文件的元信息

瞧，索引就像一个保存在单个文件中的微型文件系统。它的格式经过优化，可以超快速访问大量嵌套的文件集

现在，可以使用另一个命令，

git checkout index

使工作树与索引同步。像

git-checkout

这样的命令正是这样做的：调用

git-read-tree

来填充索引，然后调用

git-checkout-index

来同步工作树

这是最基本的。该命令还可以执行以下操作：

• 如果传递了

  -m

  命令行选项，它可以将传递给它的树合并到索引中
• 它能够以某种方式读取指定的树，使其文件（在索引中）显示在项目的子目录中（通过

  --prefix

  ）
• 它可以清空索引（通过

  --empty

  ）

在处理原始问题时，我们将其称为最简单的形式，它只是用

HEAD

引用的内容替换了索引的内容

---

请注意，

git-read-tree

是一个管道命令，不供用户常规使用。当您执行诸如

git checkout

之类的操作时，它会自动调用。我建议直接调用它，因为谁知道运行

git checkout HEAD

是否真的会更新您的索引，或者它会决定，因为它反映了

HEAD

的状态，所以不应该做任何事情。手动调用确保索引开始精确地包含我们需要的状态。在一般情况下，您不需要这个程序，因此很难给出一个简单的使用示例。

read tree命令获取git tree对象并将其状态复制到索引中。在您的例子中，您将获取当前标记为HEAD的树，并重置索引以匹配此树-这相当于git reset-mixed HEAD。当需要从其他存储库（如转换后的CVS存储库）引入不连续的历史记录时，可以使用第一个命令。一旦索引处于与所需内容匹配的状态，就可以正常创建提交。readtree命令与add命令不同，它不会查看当前工作文件夹集中的任何内容。它正在重置。

@Maximus，看到了吗？使用

git-read-tree

的建议对我来说太过分了，因为

git-reset——mixed-HEAD

也做同样的事情。谢谢你的建议，帕特@Maximus，您可能想更好地学习Git的基本概念——请参阅，以获取入门资料。感谢您详细的回答！看来

working tree

和

git tree object

不是一回事，对吧？什么都不懂