在吉特，树的意思是什么？
我对如何使用git archive感到非常困惑。
我有一个git存储库，其中文件夹Foo、Bar和Baz位于顶层。我需要导出文件夹Foo以SVN的方式快速测试部署。
我了解到我可以在一个git-archive中使用SVN-ish出口方式。
但是事情是这样的，下面的工作很好：
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程序的概要，我看到它可以将一个<tree-ish> [path]作为参数(概要概述到相关部分)：
git archive <tree-ish> [path...]如果 master/foo 不是 tree-ish，那么是什么？
Stack Overflow用户
发布于 2013-09-04 04:38:08
简短的回答(TL;DR)
"trees“是指任何标识符(如Git修订文件中所指定的)，它最终导致(子)目录树(Git将目录称为”树“和”树对象“)。
在最初的海报中，foo 是他想要指定的目录。在Git中指定(子)目录的正确方法是使用这种“树式”语法(来自Git修订文件的第15项)：
<rev>:<path>，例如HEAD:README，:README，master:./README后缀:后面是路径，在冒号前面的部分命名的树级对象中，路径名为blob或给定路径的树。
因此，换句话说，master:foo是正确的语法，而不是master/foo。
其他“Tree”(加号提交-ish)
以下是提交ish和树ish标识符的完整列表(来自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都是“提交-ish”，因为它们都会导致提交，但由于提交也指向目录树，它们最终都会导致(子目录树对象)，因此也可以用作“树-ish”。
#15在引用(子目录)时也可以用作树形ish，但也可以用于标识特定的文件。当它提到文件时，我不确定它是否仍然被认为是“树形的”，或者是否更像"blob-ish“(Git将文件称为”blob“)。
长篇大论
在最低级别，Git使用以下四个基本对象跟踪源代码：
- 带注释的标记，指向提交。
- 提交，指向项目的根目录树。
- 树，它们是目录和子目录。
- 这些是文件。
每个对象都有自己的sha1哈希ID，因为Linus将Git设计成一个内容-可寻址文件系统，即可以根据它们的内容检索文件(从文件内容生成sha1 ID)。Pro Git的书给了此示例图
许多Git命令可以接受提交和(子)目录树的特殊标识符：
- " commit -ish“是最终导致提交对象的标识符。例如,
tag -> commit - “tree”是最终导致树(即目录)对象的标识符。
tag -> commit -> project-root-directory
因为提交对象总是指向目录树对象(项目的根目录)，任何“提交-ish”的标识符从定义上来说也是“树-ish”。换句话说，任何导致提交对象的标识符也可以用于生成(子)目录树对象。
但是，由于目录树对象在Git版本控制系统中从不指向提交，所以并非指向(子)目录树的每个标识符也可以用于指向提交。换句话说，“提交-ish”标识符集是“树-ish”标识符集的严格子集.。
正如在文献资料 (感谢特雷博尔帮我找到它)中所解释的：
不能用作提交-ish的树-ish标识符集是
<rev>:<path>，它直接引导到目录树，而不是提交对象。例如，HEAD:subdirectory。- Sha1标识符的目录树对象。
https://stackoverflow.com/questions/4044368
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号