セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの慣例
- 毎日の Git
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
配管コマンド (Plumbing Commands)
- 2.48.1 → 2.49.0 変更なし
-
2.48.0
2025-01-10
- 2.41.1 → 2.47.2 変更なし
-
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>…]
説明
"bundle" ファイルの作成、展開、操作を行います。バンドルは、ネットワーク接続の反対側にアクティブな「サーバー」がなくても、Git オブジェクトを「オフライン」で転送するために使用されます。
これらは、リポジトリの増分バックアップとフルバックアップの両方を作成するため (「EXAMPLES」の「フルバックアップ」の例を参照)、およびあるリポジトリの参照の状態を別のリポジトリに中継するために使用できます (2番目の例を参照)。
`ssh://` や `https://` などのプロトコルを介してフェッチまたは「読み取り」を行う Git コマンドは、バンドルファイルでも操作できます。バンドルから新しいリポジトリをgit-clone[1]したり、git-fetch[1]を使用してバンドルからフェッチしたり、git-ls-remote[1]でバンドルに含まれる参照をリストしたりすることが可能です。対応する「書き込み」サポート、つまりバンドルへの *git push* はサポートされていません。
バンドル形式
バンドルは、バンドルに含まれる参照を示すヘッダーを持つ `.pack` ファイルです (git-pack-objects[1] を参照)。
パックされたアーカイブ形式自体と同様に、バンドルは自己完結型にすることも、除外を使用して作成することもできます。「OBJECT PREREQUISITES」セクションを参照してください。
リビジョン除外を使用して作成されたバンドルは、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 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`) 指定できます。
これらすべての単純なケースはOKです（"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.
オブジェクトの前提条件
バンドルを作成する際、共通の履歴を持たないリポジトリで展開できる自己完結型バンドルを作成できるほか、履歴の早い段階で必要となるオブジェクトを除外するために否定リビジョンを提供することも可能です。
`git bundle create` に `new` のようなリビジョンを供給すると、`new` リビジョンから到達可能なすべてのオブジェクトを含むバンドルファイルが作成されます。このバンドルは、任意のリポジトリで展開して、`new` リビジョンに至る完全な履歴を取得することができます。
$ git bundle create full.bundle new
`old..new`のようなリビジョン範囲は、バンドルが「アンバンドル可能」であるために、リビジョン`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 の間の直接接続は許可されていませんが、A から B へは (CD、電子メールなどの) 何らかのメカニズムを介してデータを移動できます。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] スイートの一部
