使い方に戸惑っていますgit archive。

最上位にFoo、Bar、Bazのフォルダーがあるgitリポジトリがあります 。迅速なテスト展開のために、フォルダーFooをSVN風の方法でエクスポートする必要があります。

私はSVN風のエクスポートのような方法で使用できることを学びgit-archiveました。

しかし、これが問題です。以下は正常に機能します。

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、そして何がありますか？

短い答え（TL; DR）

「ツリーっぽい」とは、最終的に（サブ）ディレクトリツリー（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はすべて「コミットっぽい」です。これらはすべてコミットにつながるためですが、コミットもディレクトリツリーを指すため、最終的にはすべて（サブ）ディレクトリツリーオブジェクトにつながり、したがって「ツリー」としても使用できます。 -Hは"。

＃15は、（サブ）ディレクトリを参照するときにツリーのように使用することもできますが、特定のファイルを識別するために使用することもできます。それがファイルを参照するとき、それがまだ「ツリーっぽい」と見なされているのか、それとも「ブロブっぽい」（Gitがファイルを「ブロブ」と呼ぶ）のように振る舞うのかはわかりません。

長い答え

最低レベルでは、Gitは4つの基本オブジェクトを使用してソースコードを追跡します。

1. コミットを指す注釈付きタグ。
2. プロジェクトのルートディレクトリツリーを指すコミット。
3. ツリーは、ディレクトリとサブディレクトリです。
4. ファイルであるブロブ。

Linus TorvaldsはGitをコンテンツアドレス可能なファイルシステムのように設計したため、これらのオブジェクトにはそれぞれ独自のsha1ハッシュIDがあります。つまり、ファイルはコンテンツに基づいて取得できます（sha1 IDはファイルコンテンツから生成されます）。Pro Gitブックには、次の図の例が示されています。

多くのGitコマンドは、コミットおよび（サブ）ディレクトリツリーの特別な識別子を受け入れることができます。

• 「コミットっぽい」は、最終的にコミットオブジェクトにつながる識別子です。例えば、

  tag -> commit

• 「ツリーっぽい」は、最終的にツリー（ディレクトリ）オブジェクトにつながる識別子です。

  tag -> commit -> project-root-directory

commitオブジェクトは常にディレクトリツリーオブジェクト（プロジェクトのルートディレクトリ）を指すため、「commit-ish」である識別子はすべて、定義上は「tree-ish」でもあります。言い換えると、コミットオブジェクトにつながる識別子は、（サブ）ディレクトリツリーオブジェクトにつながるためにも使用できます。

ただし、Gitのバージョン管理システムではディレクトリツリーオブジェクトがコミットをポイントすることはないため、（サブ）ディレクトリツリーをポイントするすべての識別子を使用してコミットをポイントできるわけではありません。言い換えると、「commit-ish」識別子のセットは、「tree-ish」識別子のセットの厳密なサブセットです。

ドキュメントで説明したように（Treborが見つけてくれてありがとう）：

<tree>

ツリーオブジェクト名を示します。

<commit>

コミットオブジェクト名を示します。

<tree-ish>

ツリー、コミット、またはタグのオブジェクト名を示します。<tree-ish> 引数を取るコマンドは、最終的に<tree>オブジェクトを操作したいが、を指すオブジェクト<commit>と<tag>オブジェクトを自動的に逆参照します<tree>。

<commit-ish>

コミットまたはタグのオブジェクト名を示します。<commit-ish> 引数を取るコマンドは、最終的に<commit>オブジェクトを操作したいが、<tag>を指すオブジェクトを自動的に逆参照します<commit>。

commit-ishとして使用できないツリーっぽい識別子のセットは、

1. <rev>:<path>オブジェクトをコミットするのではなく、ディレクトリツリーに直接つながります。たとえば、HEAD:subdirectory。

2. ディレクトリツリーオブジェクトのSha1識別子。

ツリーのようなものは、特定のツリーに名前を付ける方法で、次のいずれかになります。

• 次のような参照：
  • 頭
  • タグ
  • 支店名
  • のようなリモートを持つブランチ名 origin/somebranch
• ハッシュ
• 短いハッシュ

その上、上記のいずれかを付加することができます^、~。参照では@{}、いくつかの追加機能の表記を使用することもできます。

• HEAD^またはHEAD^1、HEADの最初の親に解決されます。
• HEAD^2 2番目の親に解決されます
• HEAD^33番目の親などに解決されます。これはよりまれ で、タコ戦略とのマージの結果です。
• HEAD~またはHEAD~1頭の最初の親に解決します
• HEAD~2HEADの最初の親の最初の親に解決されます。これは同じですHEAD^^
• HEAD@{0} 現在のHEADに解決されます
• HEAD@{1}前の頭に解決します。これは参照ログを使用するため、参照でのみ使用できます。HEADすべてのコミット、マージ、チェックアウトの場合、チェックアウトによりHEADの値が変更され、ログに追加されます。git reflog HEADHEADのすべての動きと適切に何@{1}が解決されるかなどを確認できる参照ログが表示されます。

それは例えば、リポジトリに理にかなっていると上記のほとんどは、さらに長いと組み合わせることができますHEAD@{2}~3、somebranch^2~4、c00e66e~4^2、anotherbranch~^~^~^。

したがって、上記のいずれか、およびその組み合わせは、ドキュメントでツリーのようなものを意味しています。これは、ほとんどのgitコマンドで使用する必要があるツリー（またはリビジョン）を示す方法の1つにすぎません。

Gitブックのリビジョン選択の詳細。

あなたはおそらく欲しい

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

この式master/fooは意味がありません。私が推測しているように、はmasterブランチ名でfooあり、ディレクトリ名です。

編集：（壊れたリンクを削除しました。コメントを参照してください。）

git（1）のマニュアルページの定義<tree-ish>と<commit-ish>参照。用語を検索する必要があります。一般的にはgitツリーオブジェクトへの参照を意味しますが、ツリーを参照するオブジェクトのタイプ（コミットやブランチなど）を渡すと、gitは参照されたツリーを自動的に使用します。<tree-ish>

私はソース管理とgitの初心者です。これは私が知っていることです。ツリーは、リポジトリ内のファイルの構造です。ファイルシステムのディレクトリに似ています。参照- このツリービューを生成したgitツールはどれですか。

ツリーっぽいというのは、ツリーのようなものです。ツリーの一部またはコミットを参照します。次のいずれかを使用してコミットを参照できます：コミットのSHA-1ハッシュの全部または一部、HEADポインター、ブランチ参照、タグ参照。別のメソッドは、コミットの祖先または親とともに、前述のメソッドのいずれかを使用します。祖先の例：

Git Glossaryから、tree-ishは「ツリーオブジェクトまたはツリーオブジェクトに再帰的に逆参照できるオブジェクト」です。commit、HEAD、tagは、ツリーっぽいオブジェクトの例です。