我有一个issue with renaming个文件，并获得了一个包含两个git命令的解决方案 - git read-tree -i HEAD和git checkout-index -a -f。我似乎已经弄明白第二个人做了什么并对其进行了测试，但我无法理解为什么即使对于最简单的情况我也需要第一个。我认为它可以以某种方式取代git add命令并添加一个文件到索引，但是当我创建一个新文件并运行命令然后用ls-files --staged检查索引的内容时它没有做到将这些文件显示为已添加，因此我对该命令目的的假设可能是错误的。我也访问了the manual page，但仍然不明白我为什么需要这个命令。
答案 0 :(得分：7)
git read-tree是这样的：
解析传递给它的“tree-ish”，以找到Git存储库中描述树的对象。
树代表Git中的目录：这种对象列出了包含树的blob（文件）和嵌套树（嵌套目录）的SHA-1和文件系统名称。每个提交只引用一个表示顶级项目目录本身状态的树。
“tree-ish”是一个规范，Git能够解析为树对象的名称。例如，HEAD首先被解析为引用的名称，然后它指向的分支被追逐以获得它的提示，然后它被解析以获得其树对象的名称。
以递归方式读取获取的树对象，并使用有关这些对象的信息填充索引。索引不包含关于它们的仅文件元信息的实际数据。
IOW，索引就像一个保存在单个文件中的微型文件系统。它的格式经过优化，可以通过大量嵌套文件进行超快速访问。
现在可以使用另一个命令git checkout-index使工作树与索引同步。像git checkout <commit>这样的命令就是这样做的：调用git read-tree来填充索引，然后调用git checkout-index来同步工作树。
这是基础知识。该命令可以做更多的事情：
-m命令行选项，它就可以将传递给它的树合并到索引中。--prefix）。--empty）。在我们处理原始问题时，我们称之为最简单的形式，它只是用HEAD引用的内容替换了索引的内容。
请注意，git read-tree是 plumbing 命令，不打算由用户常规使用。当您执行git checkout <commit>之类的操作时会自动调用它。我建议直接调用它，因为谁知道运行git checkout HEAD 是否真正更新你的索引，或者它会决定，因为它无论如何都反映了HEAD的状态完成。手动调用确保索引开始包含我们所需的状态。在一般情况下，你不需要这个程序，因此这就是为什么很难想出一个简单的用法示例。
答案 1 :(得分：1)
read-tree命令获取git树对象并将其状态复制到索引中。在您的情况下，您将当前标记为HEAD的树和重置索引以匹配此树 - 这相当于 git reset --mixed HEAD 。当您需要从其他存储库（请参阅此blog entry）引入不连续的历史记录（例如转换的CVS存储库）时，可以使用第一个命令。一旦索引处于与您需要的状态相匹配的状态，您就可以正常创建提交。 read-tree命令不会像 add 那样 - 它不会查看当前工作文件夹集中的任何内容。它正在重置。