セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
- 2.48.1 → 2.50.1 変更なし
-
2.48.0
2025-01-10
- 2.41.1 → 2.47.3 変更なし
-
2.41.0
2023-06-01
- 2.38.1 → 2.40.4 変更なし
-
2.38.0
2022-10-02
- 2.36.1 → 2.37.7 変更なし
-
2.36.0
2022-04-18
- 2.34.1 → 2.35.8 変更なし
-
2.34.0
2021-11-15
- 2.33.2 → 2.33.8 変更なし
-
2.33.1
2021-10-12
- 2.29.1 → 2.33.0 変更なし
-
2.29.0
2020-10-19
- 2.25.1 → 2.28.1 変更なし
-
2.25.0
2020-01-13
- 2.18.1 → 2.24.4 変更なし
-
2.18.0
2018-06-21
- 2.9.5 → 2.17.6 変更なし
-
2.8.6
2017-07-30
- 2.1.4 → 2.7.6 変更なし
-
2.0.5
2014-12-17
概要
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 オブジェクトを「オフライン」で転送するために使用されます。
これらを使用して、リポジトリの増分バックアップと完全バックアップの両方を作成し（「例」の「完全バックアップ」の例を参照）、あるリポジトリのリファレンスの状態を別のリポジトリに中継することができます（2番目の例を参照）。
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 [options] <file> <git-rev-list-args>
-
file という名前のバンドルを作成するために使用されます。これには、バンドルコンテンツを定義する <git-rev-list-args> 引数が必要です。options には、git bundle create サブコマンドに固有のオプションが含まれます。file が
-の場合、バンドルは標準出力に書き込まれます。 - verify <file>
-
バンドルファイルが有効であり、現在のリポジトリにきれいに適用されることを確認するために使用されます。これには、バンドル形式自体のチェックだけでなく、前提条件となるコミットが存在し、現在のリポジトリに完全にリンクされていることのチェックも含まれます。次に、git bundle は、不足しているコミットがあればそのリストを出力します。最後に、「オブジェクトフィルター」などの追加機能に関する情報が出力されます。詳細については gitformat-bundle[5] の「Capabilities」を参照してください。成功した場合は終了コードはゼロですが、バンドルファイルが無効な場合はゼロ以外になります。file が
-の場合、バンドルは標準入力から読み取られます。 - list-heads <file>
-
バンドルで定義されているリファレンスをリストします。リファレンスのリストが続く場合、それらに一致するリファレンスのみが出力されます。file が
-の場合、バンドルは標準入力から読み取られます。 - unbundle <file>
-
バンドル内のオブジェクトを git index-pack に渡し、リポジトリに格納し、定義されているすべてのリファレンスの名前を出力します。リファレンスのリストが指定されている場合、そのリスト内のリファレンスに一致するもののみが出力されます。このコマンドは実際には低レベルのコマンドであり、git fetch によってのみ呼び出されることを意図しています。file が
-の場合、バンドルは標準入力から読み取られます。 - <git-rev-list-args>
-
git rev-parse と git rev-list に受け入れられる引数のリスト（および名前付きリファレンスを含む、以下の「リファレンスの指定」を参照）で、転送する特定のオブジェクトとリファレンスを指定します。例えば、
master~10..masterは、現在の master リファレンスと、その10番目の祖先コミット以降に追加されたすべてのオブジェクトをパッケージ化します。パッケージ化できるリファレンスとオブジェクトの数に明示的な制限はありません。 - [<refname>…]
-
利用可能なものとして報告されるリファレンスを制限するために使用されるリファレンスのリスト。これは主に git fetch に役立ちます。git fetch は、要求されたリファレンスのみを受信することを期待しており、パック内のすべてを受信するとは限りません（この場合、git bundle は git fetch-pack のように動作します）。
- --progress
-
デフォルトでは、標準エラー出力ストリームがターミナルに接続されている場合、-q が指定されない限り、進行状況が標準エラー出力ストリームに報告されます。このフラグは、標準エラー出力ストリームがターミナルに接続されていない場合でも、進行状況を強制的に表示します。
- --version=<version>
-
バンドルバージョンを指定します。バージョン 2 は古い形式であり、SHA-1 リポジトリでのみ使用できます。新しいバージョン 3 は拡張を許可する機能を含んでいます。デフォルトは、使用中のハッシュアルゴリズムに基づいた、サポートされている最も古い形式です。
- -q
- --quiet
-
このフラグを指定すると、コマンドは標準エラー出力ストリームに進捗状況を報告しません。
リファレンスの指定
バンドルにパッケージ化されるリビジョンには、リファレンス名を付随させる必要があります。あるいは、すべてのリファレンスをパッケージ化するために --all を使用することもできます。
複数のリファレンスをパッケージ化でき、複数の前提条件オブジェクトのセットを指定できます。パッケージ化されるオブジェクトは、前提条件の和に含まれないものです。
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 のようなリビジョン範囲は、バンドルが「unbundle」可能であるために、リビジョン old（およびそこから到達可能なオブジェクト）が存在することを必要とするバンドルファイルを作成します。
$ git bundle create full.bundle old..new
前提条件のない自己完結型バンドルは、どこにでも、たとえ空のリポジトリにも抽出でき、そこからクローンすることもできます（つまり、new は可能ですが、old..new はできません）。
バンドルファイルがすでに宛先に存在するオブジェクトを含むようにするのは、安全側を考慮して問題ありません。これらのオブジェクトは宛先で展開するときに無視されるためです。
ソースリポジトリから直接クローンした場合と同じリファレンスセットを提供したい場合は、<git-rev-list-args> に --branches --tags を使用します。
git bundle verify コマンドは、受信側のリポジトリがバンドルに必要な前提条件コミットを持っているかどうかをチェックするために使用できます。
例
2つのケースについて説明します。
-
リポジトリの完全バックアップ
-
2台のマシンに直接接続がない場合に、あるリポジトリの履歴を別のマシンに転送する
まず、リポジトリの完全バックアップについて考えます。以下のコマンドは、すべてのリファレンスがバンドルに含まれるという意味で、リポジトリの完全バックアップを作成します。
$ git bundle create backup.bundle --all
ただし、これはリファレンス専用であることに注意してください。つまり、リファレンスとそれらのリファレンスから到達可能なコミットのみが含まれます。インデックス、作業ツリー、スタッシュ、リポジトリごとの設定、フックなどの他のローカルの状態は含まれません。
後で、例えば git-clone[1] を使用してそのリポジトリを回復できます。
$ git clone backup.bundle <new directory>
次の例では、マシン 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
考察
リポジトリの完全バックアップを行う単純な方法は、cp -r <repo> <destination> のようなものを使用することです。これは、コピー操作中にリポジトリに書き込みが行われる可能性があるため推奨されません。その結果、<destination> の一部のファイルが破損する可能性があります。
このため、リポジトリのバックアップを作成するには、このコマンドまたは例えば git-clone[1] を使用して Git ツールを使用することをお勧めします。ただし、これらのツールはリファレンスとコミット以外の状態のバックアップには役立たないことに注意してください。言い換えれば、インデックス、作業ツリー、スタッシュ、リポジトリごとの設定、フックなどの内容のバックアップには役立ちません。
システム間でのファイル同期に関連する問題については、gitfaq[7] の「TRANSFERS」セクションも参照してください。
ファイル形式
gitformat-bundle[5] を参照してください。
GIT
git[1]スイートの一部
