セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの規約
- 日々のGit
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
低レベルコマンド
- 2.41.1 → 2.47.0 変更なし
-
2.41.0
06/01/23
- 2.38.1 → 2.40.3 変更なし
-
2.38.0
10/02/22
- 2.36.1 → 2.37.7 変更なし
-
2.36.0
04/18/22
- 2.34.1 → 2.35.8 変更なし
-
2.34.0
11/15/21
- 2.33.2 → 2.33.8 変更なし
-
2.33.1
10/12/21
- 2.29.1 → 2.33.0 変更なし
-
2.29.0
10/19/20
- 2.25.1 → 2.28.1 変更なし
-
2.25.0
01/13/20
- 2.18.1 → 2.24.4 変更なし
-
2.18.0
06/21/18
- 2.9.5 → 2.17.6 変更なし
-
2.8.6
07/30/17
- 2.1.4 → 2.7.6 変更なし
-
2.0.5
12/17/14
書式
git bundle create [-q | --quiet | --progress] [--version=<version>] <file> <git-rev-list-args> git bundle verify [-q | --quiet] <file> git bundle list-heads <file> [<refname>…] git bundle unbundle [--progress] <file> [<refname>…]
説明
"バンドル"ファイルの作成、解凍、操作を行います。バンドルは、ネットワーク接続の反対側にアクティブな"サーバー"が存在しない状態で、Gitオブジェクトを"オフライン"で転送するために使用されます。
リポジトリの増分バックアップとフルバックアップの作成、およびあるリポジトリの参照の状態を別のリポジトリにリレーするために使用できます。
ssh:// や https:// などのプロトコルを介してフェッチまたは"読み取り"を行う Git コマンドは、バンドルファイルに対しても操作できます。バンドルから新しいリポジトリを git-clone[1] すること、git-fetch[1] を使用してバンドルからフェッチすること、git-ls-remote[1] を使用してバンドルに含まれる参照を一覧表示することが可能です。対応する "書き込み" サポートはありません。つまり、バンドルへの *git push* はサポートされていません。
バンドルの使用方法の例については、以下の "例" セクションを参照してください。
バンドル形式
バンドルは、バンドルに含まれる参照を示すヘッダーが付いた .pack ファイルです（git-pack-objects[1] を参照）。
パックされたアーカイブ形式自体と同様に、バンドルは自己完結型にすることも、除外を使用して作成することもできます。以下の "オブジェクトの前提条件" セクションを参照してください。
リビジョンの除外を使用して作成されたバンドルは、git-pack-objects[1] の --thin オプションを使用して作成された "シンパック" であり、git-index-pack[1] の --fix-thin オプションを使用して解凍されます。
リビジョンの除外を使用する場合、"シックパック"を作成するオプションはなく、ユーザーは違いを気にする必要はありません。"シンパック"を使用することで、除外を使用して作成されたバンドルのサイズが小さくなります。内部的に "シン" であることは、単なる豆知識として、そして他のドキュメントへの参照としてここで言及されています。
詳細については、gitformat-bundle[5] と、詳細については gitformat-pack[5] の "シンパック" の説明を参照してください。
オプション
- create [オプション] <ファイル> <git-rev-list-args>
-
*ファイル* という名前のバンドルを作成するために使用されます。これには、バンドルの内容を定義する *<git-rev-list-args>* 引数が必要です。 *オプション* には、*git bundle create* サブコマンドに固有のオプションが含まれています。 *ファイル* が
-の場合、バンドルは標準出力に書き込まれます。 - verify <ファイル>
-
バンドルファイルが有効であり、現在のリポジトリに正常に適用されることを確認するために使用されます。これには、バンドル形式自体のチェックと、前提条件となるコミットが存在し、現在のリポジトリに完全にリンクされていることのチェックが含まれます。次に、 *git bundle* は、不足しているコミットがある場合は、そのリストを出力します。最後に、"オブジェクトフィルター" などの追加機能に関する情報が出力されます。詳細については、gitformat-bundle[5] の "機能" を参照してください。終了コードは成功の場合はゼロですが、バンドルファイルが無効な場合はゼロ以外になります。 *ファイル* が
-の場合、バンドルは標準入力から読み取られます。 - list-heads <ファイル>
-
バンドルで定義されている参照を一覧表示します。参照のリストが続く場合、指定されたものと一致する参照のみが出力されます。 *ファイル* が
-の場合、バンドルは標準入力から読み取られます。 - unbundle <ファイル>
-
バンドル内のオブジェクトをリポジトリに格納するために *git index-pack* に渡し、次に定義されているすべての参照の名前を出力します。参照のリストが指定されている場合、リスト内の参照と一致する参照のみが出力されます。このコマンドは実際には低レベルコマンドであり、 *git fetch* によってのみ呼び出されることを意図しています。 *ファイル* が
-の場合、バンドルは標準入力から読み取られます。 - <git-rev-list-args>
-
転送する特定のオブジェクトと参照を指定する、 *git rev-parse* および *git rev-list* で受け入れ可能な引数のリスト（名前付き参照を含む、以下の「参照の指定」を参照）。たとえば、
master~10..masterは、現在の master 参照を、その10番目の祖先コミット以降に追加されたすべてのオブジェクトとともにパッケージ化します。パッケージ化できる参照とオブジェクトの数に明示的な制限はありません。 - [<参照名>…]
-
使用可能な参照として報告される参照を制限するために使用される参照のリスト。これは主に、要求された参照のみを受信し、必ずしもパック内のすべてを受信するとは限らない *git fetch* で役立ちます（この場合、 *git bundle* は *git fetch-pack* のように動作します）。
- --progress
-
進行状況は、-q が指定されていない限り、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。このフラグは、標準エラーストリームが端末に向けられていない場合でも、進行状況を強制的に出力します。
- --version=<バージョン>
-
バンドルのバージョンを指定します。バージョン 2 は古い形式で、SHA-1 リポジトリでのみ使用できます。新しいバージョン 3 には、拡張を許可する機能が含まれています。デフォルトは、使用されているハッシュアルゴリズムに基づいた、サポートされている最も古い形式です。
- -q
- --quiet
-
このフラグは、コマンドが標準エラーストリームに進行状況を報告しないようにします。
参照の指定
リビジョンは、バンドルにパッケージ化するには、参照名が付いている必要があります。
複数の参照をパッケージ化でき、複数の前提条件オブジェクトのセットを指定できます。パッケージ化されるオブジェクトは、前提条件の和集合に含まれていないオブジェクトです。
*git bundle create* コマンドは、 git rev-parse --abbrev-ref=loose と同じルールを使用して、参照名を解決します。各前提条件は、明示的に（例： ^master~10）、または暗黙的に（例： master~10..master、 --since=10.days.ago master）指定できます。
これらの単純なケースはすべて問題ありません（"master" と "next" ブランチがあると仮定します）
$ git bundle create master.bundle master $ echo master | git bundle create master.bundle --stdin $ git bundle create master-and-next.bundle master next $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
これらも同様です（そして、同じですが、省略された --stdin の例）
$ git bundle create recent-master.bundle master~10..master $ git bundle create recent-updates.bundle master~10..master next~5..next
リビジョン名または右辺が参照に解決できない範囲は受け入れられません
$ git bundle create HEAD.bundle $(git rev-parse HEAD) fatal: Refusing to create empty bundle. $ git bundle create master-yesterday.bundle master~10..master~5 fatal: Refusing to create empty bundle.
オブジェクトの前提条件
バンドルを作成する場合、共通の履歴のないリポジトリで解凍できる自己完結型のバンドルを作成したり、履歴の初期の部分に必要なオブジェクトを除外するために負のリビジョンを指定したりできます。
new などのリビジョンを git bundle create に渡すと、リビジョン new から到達可能なすべてのオブジェクトを含むバンドルファイルが作成されます。そのバンドルは、任意のリポジトリで解凍して、リビジョン new につながる完全な履歴を取得できます
$ git bundle create full.bundle new
old..new などのリビジョン範囲は、バンドルを「解凍」可能にするためにリビジョン old （およびそこから到達可能なオブジェクト）が存在する必要があるバンドルファイルを生成します
$ git bundle create full.bundle old..new
前提条件のない自己完結型のバンドルは、空のリポジトリを含め、どこにでも抽出したり、クローンしたりできます（つまり、 new は可能ですが、 old..new は不可能です）。
宛先に既に存在するオブジェクトをバンドルファイルに含めるように注意することは問題ありません。これらのオブジェクトは、宛先で解凍するときに無視されます。
refs/remotes/* などの参照を含む git clone --mirror と一致させたい場合は、 --all を使用します。ソースリポジトリから直接クローンした場合と同じ参照セットを提供したい場合は、 <git-rev-list-args> に --branches --tags を使用します。
`git bundle verify` コマンドは、受信側のリポジトリがバンドルの前提条件となるコミットを持っているかどうかを確認するために使用できます。
例
マシンAのリポジトリR1からマシンBのリポジトリR2に履歴を転送したいとします。何らかの理由で、AとBの直接接続は許可されていませんが、何らかのメカニズム（CD、電子メールなど）を介してAからBにデータを移動できます。R1のブランチmasterで行われた開発でR2を更新したいと考えています。
プロセスをブートストラップするには、最初に前提条件のないバンドルを作成します。タグを使用して、最後に処理したコミットを記憶しておくと、後で増分バンドルを使用して他のリポジトリを簡単に更新できます。
machineA$ cd R1 machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master
次に、file.bundleをターゲットマシンBに転送します。このバンドルは既存のオブジェクトの抽出を必要としないため、そこからクローンを作成することでマシンBに新しいリポジトリを作成できます。
machineB$ git clone -b master /home/me/tmp/file.bundle R2
これにより、結果のリポジトリに「origin」と呼ばれるリモートが定義され、バンドルからフェッチおよびプルできます。 R2の$GIT_DIR/configファイルには、次のようなエントリがあります。
[remote "origin"]
url = /home/me/tmp/file.bundle
fetch = refs/heads/*:refs/remotes/origin/*
結果のmine.gitリポジトリを更新するには、/home/me/tmp/file.bundleに保存されているバンドルを増分更新に置き換えた後、フェッチまたはプルを実行できます。
元のレポジトリでさらに作業した後、増分バンドルを作成して他のレポジトリを更新できます。
machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master
次に、バンドルを他のマシンに転送して/home/me/tmp/file.bundleを置き換え、そこからプルします。
machineB$ cd R2 machineB$ git pull
意図した受信側リポジトリがどのコミットまで必要なオブジェクトを持っているべきかを知っている場合は、その知識を使用して前提条件を指定し、結果のバンドルに含まれるリビジョンとオブジェクトを制限するカットオフポイントを指定できます。前の例では、この目的のためにlastR2bundleタグを使用しましたが、git-log[1]コマンドに指定する他のオプションを使用できます。さらに例を挙げます。
両方に存在するタグを使用できます。
$ git bundle create mybundle v1.0.0..master
時間に基づいた前提条件を使用できます。
$ git bundle create mybundle --since=10.days master
コミットの数を使用できます。
$ git bundle create mybundle -10 master
`git-bundle verify` を実行して、前提条件付きで作成されたバンドルから抽出できるかどうかを確認できます。
$ git bundle verify mybundle
これにより、バンドルから抽出するために必要なコミットがリストされ、それらがない場合はエラーが発生します。
受信側リポジトリの観点からのバンドルは、フェッチまたはプルする通常のレポジトリと変わりません。たとえば、フェッチ時に参照をマッピングできます。
$ git fetch mybundle master:localRef
また、提供されている参照を確認することもできます。
$ git ls-remote mybundle
ファイル形式
gitformat-bundle[5]を参照してください。
GIT
git[1]スイートの一部
