の使い方がよくわかりませんgit archive。
フォルダのあるgitリポジトリがありますフー、バーそしてバズ最上位レベルでフォルダをエクスポートする必要がありますフーSVN 風の方法で、迅速なテスト展開を実現します。
私はgit-archive、SVNのようなエクスポート方法。
しかし、問題は以下は正常に動作します:
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では、何ですか?
ベストアンサー1
短い答え (TL;DR)
「ツリーっぽい」とは、（Git リビジョンのドキュメント) は、最終的に (サブ) ディレクトリ ツリーにつながります (Git では、ディレクトリを「ツリー」および「ツリー オブジェクト」と呼びます)。
元の投稿者の場合、foo ディレクトリですGitで（サブ）ディレクトリを指定する正しい方法は、この「ツリー風」構文を使用することです（項目#15からGit リビジョンのドキュメント):
<rev>:<path>例えばHEAD:README、、:READMEmaster:./READMEパスが続くサフィックス
:は、コロンの前の部分で名前が付けられたツリー状のオブジェクト内の指定されたパスにある BLOB またはツリーに名前を付けます。
つまり、 はmaster:foo正しい構文であり、 ではありませんmaster/foo。
その他の「Tree っぽい」（プラス Commit っぽい）
コミット風とツリー風の識別子の完全なリストは次のとおりです（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 はすべてコミットにつながるため「コミットっぽい」ものですが、コミットはディレクトリ ツリーも指すため、最終的にはすべて (サブ) ディレクトリ ツリー オブジェクトにつながるため、「ツリーっぽい」ものとしても使用できます。
#15 は、(サブ)ディレクトリを参照するときにツリー風として使用することもできますが、特定のファイルを識別するのにも使用できます。ファイルを参照する場合、それがまだ「ツリー風」と見なされるのか、それとも「ブロブ風」のように動作するのかはわかりません (Git はファイルを「ブロブ」と呼びます)。
長い答え
最下位レベルでは、Git は次の 4 つの基本オブジェクトを使用してソース コードを追跡します。
- コミットを指す注釈付きタグ。
- プロジェクトのルート ディレクトリ ツリーを指すコミット。
- ツリーはディレクトリとサブディレクトリです。
- BLOB はファイルです。
これらのオブジェクトはそれぞれ独自のsha1ハッシュIDを持っています。これは、Linus TorvaldsがGitをコンテンツアドレス可能ファイルシステム、つまり、ファイルはその内容に基づいて取得できます（sha1 IDはファイルの内容から生成されます）。Pro Gitの本では、この例の図:
多くの Git コマンドは、コミットと (サブ) ディレクトリ ツリーの特別な識別子を受け入れることができます。
「コミットっぽい」は最終的にコミットオブジェクトにつながる識別子です。例えば、
tag -> commit「ツリー風」は、最終的にツリー (つまりディレクトリ) オブジェクトにつながる識別子です。
tag -> commit -> project-root-directory
コミット オブジェクトは常にディレクトリ ツリー オブジェクト (プロジェクトのルート ディレクトリ) を指すため、"コミット風" の識別子は定義上、"ツリー風" でもあります。言い換えると、コミットオブジェクトにつながる識別子は、（サブ）ディレクトリツリーオブジェクトにつながる識別子としても使用できます。。
しかし、ディレクトリツリーオブジェクトはGitのバージョン管理システムのコミットを指すことはないので、（サブ）ディレクトリツリーを指すすべての識別子がコミットを指すために使用できるわけではありません。言い換えれば、「コミット風」識別子のセットは、「ツリー風」識別子のセットの厳密なサブセットです。
で説明したようにドキュメント（見つけるのに協力してくれたTreborに感謝します):
<tree>ツリーオブジェクト名を示します。
<commit>コミット オブジェクト名を示します。
<tree-ish>ツリー、コミット、またはタグ オブジェクト名を示します。
<tree-ish>引数を取るコマンドは、最終的にはオブジェクトを操作しますが、を指すオブジェクトを自動的<tree>に逆参照します。<commit><tag><tree><commit-ish>コミットまたはタグ オブジェクト名を示します。引数を取るコマンドは、
<commit-ish>最終的にはオブジェクトを操作しますが、を指すオブジェクト<commit>を自動的に逆参照します。<tag><commit>
ツリー状の識別子のセットはコミット風には使えないは
<rev>:<path>、それは直接ディレクトリ ツリーにコミットします。オブジェクトにコミットしません。たとえば、HEAD:subdirectory.Sha1識別子のディレクトリツリーオブジェクト。