在 Git 中，tree-ish 是什么意思？

我对如何使用 git archive非常困惑。

我有一个文件夹 阿福，酒吧和 巴兹在顶层的 git 存储库。我需要以类似于 SVN 的方式导出文件夹 阿福，以便快速进行测试部署。

我学会了在 类似 SVN 的出口方式中使用 git-archive。

但问题是 以下工作良好:

git archive master | tar -x -C ~/destination

它导致 阿福、 酒吧、 巴兹文件夹位于 目的地文件夹中。

但是，如果使用 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 < strong > ，那么是什么？

49909 次浏览
小开

你可能需要

git archive master foo | tar -x -C ~/destination

表达式 master/foo没有意义: 正如我推测的那样，master是一个分支名称，而 foo是一个目录名称。

编辑 : (删除断开的链接，请参阅注释。)

小开

一棵树-ish 是一种特定树的命名方式，它可以是下列的一种:

  • 参考资料如:
    • 头
    • 标签
    • 分支名称
    • 有遥控器的分支名称，比如 origin/somebranch
  • 大麻
  • 短散列

最重要的是，上面的任何内容都可以附加 ^、 ~。参考文献还可以使用 @{}符号来表示一些额外的特性:

  • HEAD^或 HEAD^1将被解析为 HEAD 的第一个父级。
  • HEAD^2将解析为第二个父级
  • HEAD^3会分解成第三亲本等，这是比较罕见的和 与章鱼战略相结合的产物。
  • HEAD~或 HEAD~1将解析为头的第一个父级
  • HEAD~2将解析为 HEAD 的第一个父级的第一个父级，这与 HEAD^^相同
  • HEAD@{0}将解析为当前的 HEAD
  • HEAD@{1}将解析到前一个头。这只能由引用使用，因为它使用引用日志。对于 HEAD，每次提交、合并、签出都会改变 HEAD 的值，从而将其添加到日志中。git reflog HEAD将显示参考日志，在那里你可以看到所有的运动头和正确的 @{1}等将解决。

只要在存储库中有意义，上述大部分内容都可以进一步组合，例如: HEAD@{2}~3、 somebranch^2~4、 c00e66e~4^2、 anotherbranch~^~^~^。

因此，上面描述的任何一种以及它们的组合，在文档中都是树型的，这只是说明大多数 git 命令应该使用哪种树(或修订版)的一种方式。

更多信息在 Git 图书中的修订选择。

小开

有关 <tree-ish>和 <commit-ish>的定义，请参见 Git (1)手册页。你得搜索条款。一般来说，<tree-ish>表示对 git 树对象的引用，但是如果您传递了引用树的对象类型(比如提交或分支) ，git 将自动使用引用的树。

小开
最佳答案

简短的回答(TL; DR)

“ Tree-ish”是一个指任何标识符的术语(如在 Git 中指定的那样) 修订文档 ) ，最终导致一个(子)目录 Tree (Git 将目录称为“ tree”和“ tree object”)。

在原来的海报的情况下，foo 是一个目录，他希望 在 Git 中指定(子)目录的正确方法是使用 “ tree-ish”语法(来自 Git 修订文档的第15项) :

例如: HEAD:README、 :README、 master:./README

中给定路径处的 blob 或树的后缀 :后跟路径 由冒号前的部分命名的树状对象。

所以，换句话说，master:foo是正确的语法，而不是 master/foo。

其他“树型”(加上承诺型)

下面是一个完整的提交式和树式标识符列表(来自 < a href = “ https://www.kernel.org/pub/software/scm/Git/docs/gitvisions.html # _  “ rel = “ noReferrer”> the Git 修订文档 ，< a href = “ https://stackoverflow./a/13754113/456814”> 感谢 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都是“提交”，因为它们都会导致提交，但是 因为提交也指向目录树，所以它们最终都会导致 (sub)目录树对象，因此也可以用作“ tree-ish”。

当它引用一个(子)目录时，# 15也可以用作树状目录，但是 也可以用来识别特定的文件。当它涉及到文件，我不是 确定它是否仍然被认为是“树状的”，或者它的行为是否更像“ blob-ish”(Git 将文件称为“ blobs”)。

长答案

在最底层，Git 使用四个基本原理来跟踪源代码 目的:

  1. 带注释的标记，它指向提交。
  2. 提交，它指向项目的根目录树。
  3. 树，即目录和子目录。
  4. 斑点，就是文件。

这些对象都有自己的 sha1散列 ID，因为 Linus Torvalds 设计了 Git 类似于 内容可寻址文件系统，即可以检索文件 基于它们的内容(sha1 ID 由文件内容生成) 书中给出了 这个示例图:

Figure 9-3 from Pro Git book

许多 Git 命令可以接受提交和(子)目录的特殊标识符 树木:

  • “ Commit-ish”是最终导致提交对象的标识符,

    tag -> commit

  • “ Tree-ish”是最终导致树(即目录)对象的标识符。

    tag -> commit -> project-root-directory

因为提交对象总是指向一个目录树对象(根 目录) ，任何“ commit-ish”标识符都是通过 也就是说，< strong > < em > 任何导致 提交对象还可以用来导致一个(子)目录树对象 。

但是由于目录树对象在 Git 的版本控制中从不指向提交 系统中，并不是每个指向(子)目录树的标识符也可以是 换句话说，< strong > “ commit-ish”标识符集 是“ tree-ish”标识符集的一个严格子集

正如在 文件中所解释的(< a href = “ https://stackoverflow./a/16042171/456814”> 感谢 Trebor 的帮助 我发现它 

<tree>

指示树对象名称。

<commit>

指示提交对象名称。

<tree-ish>

指示树、提交或标记对象名称 参数最终希望对 <tree>对象进行操作，但是会自动执行 解引用指向 <tree>的 <commit>和 <tag>对象。

<commit-ish>

指示提交或标记对象名称 参数最终希望对 <commit>对象进行操作，但是会自动执行 解引用指向 <commit>的 <tag>对象。

< em > 不能用作 commit-ish 是一组树状标识符

  1. <rev>:<path>，它将 直接导向目录树，而不是提交 例如，HEAD:subdirectory.

  2. < em > 目录树 对象的 Sha1标识符。

小开

我是源代码控制和 Git 的新手。这就是我所知道的。树是存储库中文件的结构。它类似于文件系统中的目录。你看 哪个 git 工具生成了这个树视图？

树一样的意思是像一棵树。它引用树的一部分或提交。您可以使用以下任何一种方法来引用提交: 提交的完整或部分 SHA-1散列、 HEAD 指针、分支引用、标记引用。另一个方法与提交的祖先或父代一起使用上述任何方法。祖先的例子: enter image description here

小开

从 Git Glossary的树-样是 “树对象或可以递归地解引用树对象的对象。” 提交、 HEAD 和标记是类树对象的例子。


提交答案