我很困惑如何使用git archive.
我有一个 git 存储库，其中 包含顶层文件夹Foo、Bar和Baz 。我需要以类似 SVN 的方式导出文件夹Foo以进行快速测试部署。
我了解到我可以git-archive以类似 SVN 的导出方式使用。
但事情是这样的，以下工作正常：
git archive master | tar -x -C ~/destination
它会在目标文件夹中生成Foo、Bar、Baz文件夹。
但是，以下将出错fatal not a valid object name：
git archive master/foo | tar -x -C ~/destination
作为git archive程序的概要，我发现它可以将 a<tree-ish> [path]作为参数（概要总结到相关部分）：
git archive <tree-ish> [path...]
如果 master/foo 不是 tree-ish，那是什么？
“Tree-ish”是一个术语，指的是最终导致（子）目录树的任何标识符（如Git 修订文档中所指定）（Git 将目录称为“树”和“树对象”）。
在原始发布者的情况下，foo 是他想要指定的目录。在 Git 中指定（子）目录的正确方法是使用这种“树状”语法（Git 修订文档中的项目 #15 ）：
<rev>:<path>, 例如HEAD:README,:README,master:./README后缀
:后跟路径命名树状对象中给定路径上的 blob 或树，该对象由冒号之前的部分命名。
因此，换句话说，master:foo是正确的语法，而不是master/foo.
这是提交式和树式标识符的完整列表（来自Git 修订文档，感谢 LopSae 指出）：
----------------------------------------------------------------------
| Commit-ish/Tree-ish | Examples
----------------------------------------------------------------------
| 1. <sha1> | dae86e1950b1277e545cee180551750029cfe735
| 2. <describeOutput> | v1.7.4.2-679-g3bee7fb
| 3. <refname> | master, heads/master, refs/heads/master
| 4. <refname>@{<date>} | master@{yesterday}, HEAD@{5 minutes ago}
| 5. <refname>@{<n>} | master@{1}
| 6. @{<n>} | @{1}
| 7. @{-<n>} | @{-1}
| 8. <refname>@{upstream} | master@{upstream}, @{u}
| 9. <rev>^ | HEAD^, v1.5.1^0
| 10. <rev>~<n> | master~3
| 11. <rev>^{<type>} | v0.99.8^{commit}
| 12. <rev>^{} | v0.99.8^{}
| 13. <rev>^{/<text>} | HEAD^{/fix nasty bug}
| 14. :/<text> | :/fix nasty bug
----------------------------------------------------------------------
| Tree-ish only | Examples
----------------------------------------------------------------------
| 15. <rev>:<path> | HEAD:README, :README, master:./README
----------------------------------------------------------------------
| Tree-ish? | Examples
----------------------------------------------------------------------
| 16. :<n>:<path> | :0:README, :README
----------------------------------------------------------------------
标识符#1-14 都是“commit-ish”，因为它们都导致提交，但由于提交也指向目录树，它们最终都导致（子）目录树对象，因此也可以用作“树-ish”。
#15 在引用（子）目录时也可以用作树形，但也可以用于标识特定文件。当它引用文件时，我不确定它是否仍然被认为是“树状”，或者是否更像“blob-ish”（Git 将文件称为“blob”）。
在最低级别，Git 使用四个基本对象跟踪源代码：
这些对象中的每一个都有自己的 sha1 哈希 ID，因为 Linus Torvalds 将 Git 设计为一个内容可寻址的文件系统，即可以根据其内容检索文件（sha1 ID 是从文件内容生成的）。Pro Git 书给出了这个示例图：
许多 Git 命令可以接受提交和（子）目录树的特殊标识符：
“Commit-ish”是最终导致提交对象的标识符。例如，
tag -> commit
“Tree-ish”是最终导致树（即目录）对象的标识符。
tag -> commit -> project-root-directory
因为提交对象总是指向一个目录树对象（项目的根目录），所以根据定义，任何“commit-ish”的标识符也是“tree-ish”。换句话说，任何导致提交对象的标识符也可以用于导致（子）目录树对象。
但是由于目录树对象在 Git 的版本控制系统中从不指向提交，因此并非每个指向（子）目录树的标识符也可以用来指向提交。换句话说，“commit-ish”标识符集是“tree-ish”标识符集的严格子集。
<tree>表示树对象名称。
<commit>表示提交对象名称。
<tree-ish>表示树、提交或标记对象名称。带
<tree-ish>参数的命令最终希望对<tree>对象进行操作，但会自动取消引用<commit>和<tag>指向<tree>.<commit-ish>指示提交或标记对象名称。带
<commit-ish>参数的命令最终想要对<commit>对象进行操作，但会自动取消引用<tag>指向 a 的对象<commit>。
不能用作 commit-ish的 tree-ish 标识符集是
<rev>:<path>，这直接导致目录树，而不是提交对象。例如，HEAD:subdirectory。
目录树对象的 Sha1 标识符。
tree-ish 是一种命名特定树的方式，它可以是以下之一：
origin/somebranch最重要的是，以上任何一项都可以附加^, ~。参考文献也可以将@{}符号用于一些附加功能：
HEAD^或HEAD^1将解析到 HEAD 的第一个父级。HEAD^2将解决到第二个父母HEAD^3会解析到三亲等等，比较少见，是和 章鱼策略合并的产物。HEAD~或HEAD~1将解析为 head 的第一个父级HEAD~2将解析为 HEAD 的第一个父级的第一个父级。这将与HEAD^^HEAD@{0}将解析为当前的 HEADHEAD@{1}将解决前一个头。这只能被引用使用，因为它使用了引用日志。在HEAD每次提交、合并、签出的情况下，都会更改 HEAD 的值，从而将其添加到日志中。git reflog HEAD将显示参考日志，您可以在其中看到 HEAD 的所有动作以及正确@{1}的解决方法等。只要在您的存储库中有意义，上述大部分内容都可以进一步组合，例如：HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.
因此，上述任何内容及其组合在文档中都是树状的，这只是说明大多数 git 命令应该使用哪种树（或修订版）的一种方式。
你可能想要
git archive master foo | tar -x -C ~/destination
该表达式master/foo没有意义：master是一个分支名称，并且foo是一个目录名称，正如我所推测的那样。
编辑：（删除断开的链接。见评论。）
有关定义<tree-ish>并<commit-ish>参见git(1)手册页。您必须搜索这些条款。一般<tree-ish>是指对 git 树对象的引用，但是如果你传递一种引用树的对象类型（例如提交或分支），git 会自动使用被引用的树。
从Git Glossary tree-ish 是“一个树对象或一个可以递归地取消引用到树对象的对象”。commit、HEAD 和 tag 是树状对象的示例。
我是源代码控制和 git 的新手。这是我所知道的。树是存储库中文件的结构。它类似于文件系统中的目录。请参阅 - 哪个 git 工具生成了这个树视图？
Tree-ish 的意思是像一棵树。它引用树的一部分或提交。您可以使用以下任何一种来引用提交：提交的完整或部分 SHA-1 哈希、HEAD 指针、分支引用、标记引用。另一种方法使用任何提到的方法以及提交的祖先或父母。祖先的例子：
