在 Git 中 tree-ish 是啥意思？
Posted
技术标签:
【中文标题】在 Git 中 tree-ish 是啥意思？【英文标题】：What does tree-ish mean in Git?在 Git 中 tree-ish 是什么意思？ 【发布时间】：2011-05-01 22:58:05 【问题描述】：我很困惑如何使用git archive。
我有一个 git 存储库，其中包含***文件夹 Foo、Bar 和 Baz。我需要以类似 SVN 的方式导出文件夹 Foo 以进行快速测试部署。
我了解到我可以在SVN-ish export sort of way 中使用git-archive。
但事情是这样的，以下工作正常：
git archive master | tar -x -C ~/destination
它会导致 destination 文件夹中的 Foo、Bar、Baz 文件夹。
但是，fatal not a valid object name 会出现以下错误：
git archive master/foo | tar -x -C ~/destination
文档
查看git archive 程序的概要，我发现它可以将<tree-ish> [path] 作为参数（概要汇总到相关部分）：
git archive <tree-ish> [path...]
如果 master/foo 不是 tree-ish，那么什么是？
【问题讨论】：
master:foo 是树状的，但你最好使用 master foo 和 <tree-ish> <path>。
我将 git archive 命令的手册页不再是指树状结构，但是当我问这个问题时，他们做到了。关于接受的答案；当时没有其他人愿意回答这个问题。两年多后，甚至发布了另一个答案。
【参考方案1】：
简答 (TL;DR)
“Tree-ish”是指任何标识符（如the Git revisions documentation 中指定的）最终导致（子）目录的术语 树（Git 将目录称为“树”和“树对象”）。
在原始发帖人的情况下，foo是他想要的目录
指定。在 Git 中指定（子）目录的正确方法是使用这个
“树形”语法（来自the Git revisions documentation 的项目#15）：
<rev>:<path>，例如HEAD:README、:README、master:./README后缀
:后跟一个路径，为给定路径中的 blob 或树命名 冒号前部分命名的树状对象。
因此，换句话说，master:foo 是正确的语法，而不是 master/foo。
其他“Tree-ish”（加上 Commit-ish）
这里是 commit-ish 和 tree-ish 标识符的完整列表（来自the Git revisions documentation、thanks to LopSae for pointing it out）：
----------------------------------------------------------------------
| 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”，因为它们都导致提交，但是 因为提交也指向目录树，所以它们最终都会导致 （子）目录树对象，因此也可以用作“树形”。
#15 在引用（子）目录时也可以用作树形，但它 也可用于识别特定文件。当它提到文件时，我不是 确定它是否仍然被认为是“tree-ish”，或者更像是“blob-ish”（Git 将文件称为“blob”）。
长答案
在最低级别，Git 使用四个基本功能来跟踪源代码 对象：
-
带注释的标签，指向提交。
提交，指向项目的根目录树。
树，即目录和子目录。
Blob，即文件。
每个对象都有自己的 sha1 哈希 ID，因为 Linus Torvalds 设计了 Git 就像content- addressable 文件系统，即可以检索文件 基于它们的内容（sha1 ID 是从文件内容生成的）。专业的 Git 书给this example diagram：
许多 Git 命令可以接受提交和（子）目录的特殊标识符 树：
“Commit-ish”是最终导致提交对象的标识符。例如，
tag -> commit
“Tree-ish”是最终导致树（即目录）对象的标识符。
tag -> commit -> project-root-directory
因为提交对象总是指向一个目录树对象（根 项目的目录），任何“commit-ish”的标识符都是，由 定义，也是“树状”。换句话说，任何导致 提交对象也可用于指向（子）目录树对象。
但是由于目录树对象从不指向 Git 版本控制中的提交 系统，并非每个指向（子）目录树的标识符也可以是 用于指向一个提交。换句话说，“commit-ish”标识符集 是一组“树状”标识符的严格子集。
如the documentation (thanks to Trebor for helping me find it) 中所述：
<tree>表示树对象名称。
<commit>表示提交对象名称。
<tree-ish>表示树、提交或标记对象名称。采用
<tree-ish>的命令 参数最终想要对<tree>对象进行操作，但自动 取消引用指向<tree>的<commit>和<tag>对象。<commit-ish>表示提交或标记对象名称。采用
<commit-ish>的命令 参数最终想要对<commit>对象进行操作，但自动 取消引用指向<commit>的<tag>对象。
不能用作 commit-ish 的树状标识符集是
<rev>:<path>，将直接引导至目录树，而不是提交
对象。例如，HEAD:subdirectory。
目录树对象的Sha1标识符。
【讨论】：
你桌子上的第 16 条呢？这是否意味着您不确定它是否是树状的？ 0 指的是合并状态，这个概念仅适用于 blob，因为索引甚至不包含目录。请参阅：***.com/a/25806452/895245。那么问题就归结为：所有 blob-ishes 也是 tree-ishes 吗？据我所知，是的：所有使用<tree-ish> 的手册页都接受，man gitrevisions 定义：trees ("directories of files")。
请注意，git-archive 表示它需要 <tree-ish>，但它不允许使用 <sha1>。所以我想它应该改为要求<tree-ish-ish>。 ***.com/a/12073669/680464
但是我想知道当我使用 树形是命名特定树的一种方式，可以是以下之一：
参考如下： 头 标签 分公司名称 带有遥控器的分支名称，例如origin/somebranch
哈希
短哈希
除此之外，以上任何内容都可以附加^、~。引用还可以使用@ 表示法来获得一些附加功能：
HEAD^ 或 HEAD^1 将解析为 HEAD 的第一个父级。
HEAD^2 将解析为第二个父项
HEAD^3 会解析到第三个父节点，以此类推，这种情况比较少见，是 merges with the octopus strategy 的产物。
HEAD~ 或 HEAD~1 将解析为 head 的第一个父项
HEAD~2 将解析为 HEAD 的第一个父级的第一个父级。这将与HEAD^^ 相同
HEAD@0 将解析为当前的 HEAD
HEAD@1 将解析到前一个头部。这只能被引用使用，因为它使用了引用日志。在HEAD 的情况下，每次提交、合并、签出都会更改 HEAD 的值，从而将其添加到日志中。 git reflog HEAD 将显示参考日志，您可以在其中看到 HEAD 的所有动作以及 @1 等将解决的问题。
只要在您的存储库中有意义，上述大部分内容都可以进一步组合，例如：HEAD@2~3、somebranch^2~4、c00e66e~4^2、anotherbranch~^~^~^。
因此，上述任何内容及其组合在文档中都是树状的意思，这只是一种说明应该在大多数情况下使用什么树（或修订版）的方式git 命令。
Revision Selection in the Git book 中的更多信息。
【讨论】：
这个答案一般解释了修订（commit-ishes）并错过了关键案例：master:path/to/directory，这是一个树形但不是一个提交。纸杯蛋糕让这一点更清楚。【参考方案3】：
你可能想要
git archive master foo | tar -x -C ~/destination
master/foo 表达式没有意义：master 是分支名称，foo 是目录名称，我认为。
编辑：（删除断开的链接。参见 cmets。）
【讨论】：
在您的“Git Treeishes”链接中不再找到“tree”一词。仅供参考 Treeish 一般指的是修订树，而不是目录布局。 @JürgenStrobel：这不是真的。它没有提到这两者——过去时，因为在当前版本的文档中不再使用该术语。 （这也是链接断开的原因。）以前，treeish 指的是可以解析为 git 对象存储中的树对象的东西。这包括任何提交规范，因为每个提交都指向一个树对象。树对象包含有关此提交的目录树的信息 - 有关详细信息，请参阅 section on git objects in "Pro Git"。【参考方案4】：有关<tree-ish> 和<commit-ish> 的定义，请参见git(1) 手册页。您必须搜索这些条款。一般<tree-ish>表示对git树对象的引用，但是如果你传递一种引用树的对象类型（例如提交或分支），git会自动使用被引用的树。
【讨论】：
还有gitrevisions(7)。【参考方案5】：
来自Git Glossary tree-ish 是 “树对象或可以递归地取消引用到树对象的对象。” commit、HEAD 和 tag 是树状对象的示例。
【讨论】：
【参考方案6】：我是源代码管理和 git 的新手。这是我所知道的。树是存储库中文件的结构。它类似于文件系统中的目录。参见 - Which git tool generated this tree view?
Tree-ish 意味着像一棵树。它引用树的一部分或提交。您可以使用以下任何一种来引用提交：提交的完整或部分 SHA-1 哈希、HEAD 指针、分支引用、标记引用。另一种方法使用任何提到的方法以及提交的祖先或父母。祖先的例子：
【讨论】：
以上是关于在 Git 中 tree-ish 是啥意思？的主要内容，如果未能解决你的问题，请参考以下文章
git+ssh 在像 git+ssh://git@github.com/xxx.git 这样的 npm repo 路径中是啥意思