セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット作成
ブランチとマージ
プロジェクトの共有と更新
調査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
-
2.49.0
2025-03-14
- 2.48.1 変更なし
-
2.48.0
2025-01-10
- 2.47.1 → 2.47.2 変更なし
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.3 変更なし
-
2.46.0
2024-07-29
- 2.45.1 → 2.45.3 変更なし
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.3 変更なし
-
2.44.0
2024-02-23
- 2.43.1 → 2.43.6 変更なし
-
2.43.0
2023-11-20
- 2.41.1 → 2.42.4 変更なし
-
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.35.1 → 2.35.8 変更なし
-
2.35.0
2022-01-24
- 2.32.1 → 2.34.8 変更なし
-
2.32.0
2021-06-06
- 2.30.2 → 2.31.8 変更なし
-
2.30.1
2021-02-08
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 変更なし
-
2.29.0
2020-10-19
- 2.28.1 変更なし
-
2.28.0
2020-07-27
- 2.27.1 変更なし
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 変更なし
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 変更なし
-
2.23.0
2019-08-16
- 2.22.2 → 2.22.5 変更なし
-
2.22.1
2019-08-11
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 変更なし
-
2.21.0
2019-02-24
- 2.18.1 → 2.20.5 変更なし
-
2.18.0
2018-06-21
- 2.17.0 → 2.17.6 変更なし
-
2.16.6
2019-12-06
- 2.15.4 変更なし
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
- 2.12.5 変更なし
-
2.11.4
2017-09-22
- 2.10.5 変更なし
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
- 2.4.12 → 2.6.7 変更なし
-
2.3.10
2015-09-28
- 2.1.4 → 2.2.3 変更なし
-
2.0.5
2014-12-17
概要
git clone [--template=<template-directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--dissociate] [--separate-git-dir <git-dir>] [--depth <depth>] [--[no-]single-branch] [--[no-]tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] [--filter=<filter-spec>] [--also-filter-submodules]] [--] <repository> [<directory>]
説明
リポジトリを新しく作成されたディレクトリにクローンし、クローンされたリポジトリの各ブランチに対応するリモートトラッキングブランチを作成し(`git branch --remotes`で確認可能)、クローンされたリポジトリの現在アクティブなブランチからフォークされた初期ブランチを作成しチェックアウトします。
クローン後、引数なしの単純な`git fetch`は全てのリモートトラッキングブランチを更新し、引数なしの`git pull`は、もしあれば、リモートのマスターブランチを現在のマスターブランチにマージします(`--single-branch`が指定された場合はこれに当てはまりません。下記を参照)。
このデフォルト設定は、`refs/remotes/origin`以下にリモートブランチヘッドへの参照を作成し、`remote.origin.url`と`remote.origin.fetch`の設定変数を初期化することで実現されます。
オプション
-
-l
-
--local
-
クローン元のリポジトリがローカルマシン上にある場合、このフラグは通常の「Git認識」転送メカニズムをバイパスし、`HEAD`およびオブジェクトと参照ディレクトリ以下の全てのコピーを作成することでリポジトリをクローンします。`.git/objects/`ディレクトリ以下のファイルは、可能な限りスペースを節約するためにハードリンクされます。
リポジトリがローカルパス(例: `/path/to/repo`)として指定された場合、これがデフォルトであり、`--local`は実質的に何もしません。リポジトリがURLとして指定された場合、このフラグは無視されます(そしてローカル最適化は使用されません)。`/path/to/repo`が与えられた場合に`--no-local`を指定すると、デフォルトを上書きし、代わりに通常のGit転送が使用されます。
リポジトリの`$GIT_DIR/objects`にシンボリックリンクがある場合、またはそれ自体がシンボリックリンクである場合、クローンは失敗します。これは、シンボリックリンクを逆参照することによる意図しないファイルのコピーを防ぐためのセキュリティ対策です。
このオプションは、セキュリティ上の理由から他のユーザーが所有するリポジトリでは機能せず、クローンを成功させるには`--no-local`を指定する必要があります。
注: この操作は、ソースリポジトリへの同時変更と競合する可能性があり、`cp -r <src> <dst>`を実行中に<src>を変更する場合と同様です。
-
--no-hardlinks
-
ローカルファイルシステム上のリポジトリからクローンする際に、ハードリンクを使用する代わりに、`.git/objects`ディレクトリ以下のファイルを強制的にコピーします。これは、リポジトリのバックアップを作成しようとしている場合に望ましいかもしれません。
-
-s
-
クローンするリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、`.git/objects/info/alternates`を自動的に設定して、ソースリポジトリとオブジェクトを共有します。結果として生成されるリポジトリは、自身のオブジェクトを何も持たない状態で開始されます。
注: これは危険な可能性のある操作です。その動作を理解していない限り、**使用しないでください**。このオプションを使用してリポジトリをクローンし、その後ソースリポジトリでブランチを削除したり(または既存のコミットを参照解除する他のGitコマンドを使用したりすると)、一部のオブジェクトが参照解除された状態(またはダンシング)になることがあります。これらのオブジェクトは、`git maintenance run --auto`を自動的に呼び出す通常のGit操作(例: `git commit`)によって削除される可能性があります。(git-maintenance[1]を参照。)これらのオブジェクトが削除され、かつクローンされたリポジトリによって参照されていた場合、クローンされたリポジリは破損します。
`--shared`でクローンされたリポジトリで`--local`オプションなしで`git repack`を実行すると、ソースリポジトリのオブジェクトがクローンされたリポジトリのパックにコピーされ、`clone --shared`によるディスク容量の節約効果が失われることに注意してください。ただし、デフォルトで`--local`オプションを使用する`git gc`を実行することは安全です。
`--shared`でクローンされたリポジトリのソースリポジトリへの依存関係を解除したい場合は、`git repack -a`を実行するだけで、ソースリポジトリから全てのオブジェクトをクローンされたリポジトリのパックにコピーできます。
-
--reference[-if-able] <repository>
-
参照<repository>がローカルマシン上にある場合、`.git/objects/info/alternates`を自動的に設定して、参照<repository>からオブジェクトを取得します。既存のリポジトリを代替として使用すると、クローンされるリポジトリからコピーする必要のあるオブジェクトが少なくなり、ネットワークとローカルストレージのコストが削減されます。`--reference-if-able`を使用すると、存在しないディレクトリはクローンを中止する代わりに警告とともにスキップされます。
注: `--shared`オプションの注記と、`--dissociate`オプションも参照してください。
-
--dissociate
-
`--reference`オプションで指定された参照リポジトリからオブジェクトを借用するのは、ネットワーク転送を減らすためだけであり、クローンが作成された後に、借用されたオブジェクトの必要なローカルコピーを作成することで、それらからの借用を停止します。このオプションは、すでに他のリポジトリからオブジェクトを借用しているリポジトリからローカルにクローンする場合にも使用できます。新しいリポジトリは同じリポジトリからオブジェクトを借用しますが、このオプションを使用することで借用を停止できます。
-
-q
-
--quiet
-
静かに操作します。標準エラー出力ストリームには進捗状況は報告されません。
-
-v
-
--verbose
-
詳細に実行します。標準エラー出力ストリームへの進捗状況の報告には影響しません。
-
--progress
-
標準エラー出力ストリームが端末に接続されている場合、`--quiet`が指定されていない限り、デフォルトで進捗状況が報告されます。このフラグは、標準エラー出力ストリームが端末にリダイレクトされていない場合でも、進捗状況を強制的に表示します。
-
--server-option=<option>
-
プロトコルバージョン2を使用して通信する際に、指定された文字列をサーバーに送信します。指定された文字列には、NULL文字やLF文字を含めてはいけません。未知のオプションを含むサーバーオプションの処理は、サーバーに依存します。複数の`--server-option=<option>`が与えられた場合、それらはコマンドラインに記載された順序で全て相手側に送信されます。コマンドラインから`--server-option=`<option>が与えられない場合、代わりに構成変数`remote.<name>.serverOption`の値が使用されます。
-
-n
-
--no-checkout
-
クローン完了後、`HEAD`のチェックアウトは行われません。
-
--
[no-
]reject-shallow
-
ソースリポジトリがシャローリポジトリの場合、失敗します。`clone.rejectShallow`設定変数を使用してデフォルトを指定できます。
-
--bare
-
ベアGitリポジトリを作成します。つまり、<directory>を作成して管理ファイルを`<directory>/.git`に配置する代わりに、<directory>自体を`$GIT_DIR`とします。これにより、ワーキングツリーをチェックアウトする場所がないため、`--no-checkout`が当然ながら適用されます。また、リモートのブランチヘッドは、`refs/remotes/origin/`にマッピングされることなく、対応するローカルブランチヘッドに直接コピーされます。このオプションを使用する場合、リモートトラッキングブランチも関連する設定変数も作成されません。
-
--sparse
-
スパースチェックアウトを使用し、最初はトップレベルディレクトリ内のファイルのみが存在するようにします。git-sparse-checkout[1]コマンドを使用して、必要に応じてワーキングディレクトリを拡張できます。
-
--filter=<filter-spec>
-
部分クローン機能を使用し、指定されたオブジェクトフィルターに従って、到達可能なオブジェクトのサブセットをサーバーが送信するように要求します。`--filter`を使用する場合、提供される<filter-spec>は部分クローンフィルターに使用されます。例えば、`--filter=blob:none`は、Gitによって必要とされるまで、全てのブロブ(ファイルの内容)を除外します。また、`--filter=blob:limit=<size>`は、少なくとも<size>サイズの全てのブロブを除外します。フィルター仕様の詳細については、git-rev-list[1]の`--filter`オプションを参照してください。
-
--also-filter-submodules
-
リポジトリ内の全てのサブモジュールにも部分クローンフィルターを適用します。`--filter`と`--recurse-submodules`が必要です。これは、`clone.filterSubmodules`設定オプションを設定することで、デフォルトで有効にできます。
-
--mirror
-
ソースリポジトリのミラーを設定します。これは`--bare`を含意します。`--bare`と比較して、`--mirror`はソースのローカルブランチをターゲットのローカルブランチにマッピングするだけでなく、全てのリファレンス(リモートトラッキングブランチ、ノートなどを含む)をマッピングし、ターゲットリポジトリで`git remote update`によってこれらの全てのリファレンスが上書きされるようなrefspec設定を行います。
-
-o
<name> -
--origin
<name> -
上流リポジトリを追跡するためにリモート名`origin`を使用する代わりに、<name>を使用します。設定の`clone.defaultRemoteName`を上書きします。
-
-b
<name> -
--branch
<name> -
新しく作成された`HEAD`を、クローンされたリポジトリの`HEAD`が指すブランチではなく、<name>ブランチを指すようにします。ベアではないリポジトリでは、これがチェックアウトされるブランチになります。`--branch`はタグも受け入れ、結果のリポジトリでそのコミットに`HEAD`をデタッチします。
-
--revision=<rev>
-
新しいリポジトリを作成し、指定されたリビジョン<rev>に至るまでの履歴のみをフェッチし、リモートトラッキングブランチもローカルブランチも作成せず、`HEAD`を<rev>にデタッチします。引数は、コミットまで剥がされる参照名(例: `refs/heads/main`や`refs/tags/v1.0`)、または16進数のオブジェクト名です。このオプションは`--branch`および`--mirror`と互換性がありません。
-
-u
<upload-pack> -
--upload-pack
<upload-pack> -
指定され、クローン元のリポジトリがSSH経由でアクセスされる場合、これは相手側で実行されるコマンドのデフォルト以外のパスを指定します。
-
--template=<template-directory>
-
テンプレートが使用されるディレクトリを指定します。(git-init[1]の「TEMPLATE DIRECTORY」セクションを参照してください。)
-
-c
<key>=<value>
-
--config
<key>=<value>
-
新しく作成されたリポジトリに設定変数を設定します。これはリポジトリが初期化された直後、リモート履歴がフェッチされたりファイルがチェックアウトされる前に行われます。<key>はgit-config[1]で期待されるのと同じ形式です(例: `core.eol=true`)。同じキーに対して複数の値が与えられた場合、各値は設定ファイルに書き込まれます。これにより、例えば、originリモートに追加のフェッチリフスペックを安全に追加することができます。
現在の実装の制限により、一部の設定変数は初期フェッチとチェックアウトが完了するまで有効になりません。有効にならないことが知られている設定変数は、`remote.<name>.mirror`と`remote.<name>.tagOpt`です。代わりに、対応する`--mirror`オプションと`--no-tags`オプションを使用してください。
-
--depth <depth>
-
指定されたコミット数に履歴が切り詰められたシャロークローンを作成します。全てのブランチの先端近くの履歴をフェッチするために`--no-single-branch`が与えられない限り、`--single-branch`を含意します。サブモジュールもシャローにクローンしたい場合は、`--shallow-submodules`も渡してください。
-
--shallow-since=<date>
-
指定された時間以降の履歴を持つシャロークローンを作成します。
-
--shallow-exclude=<ref>
-
指定されたリモートブランチまたはタグから到達可能なコミットを除外した履歴を持つシャロークローンを作成します。このオプションは複数回指定できます。
-
--[no-]single-branch
-
`--branch`オプションで指定された単一ブランチの先端、またはプライマリブランチリモートの`HEAD`が指すブランチに至る履歴のみをクローンします。結果のリポジトリへのその後のフェッチでは、このオプションが初期クローンに使用されたブランチのリモートトラッキングブランチのみが更新されます。`--single-branch`クローンが作成されたときにリモートの`HEAD`がどのブランチも指していなかった場合、リモートトラッキングブランチは作成されません。
-
--[no-]tags
-
タグがクローンされるかどうかを制御します。`--no-tags`が与えられた場合、`remote.<remote>.tagOpt=--no-tags`設定により、オプションは永続的になります。これにより、将来の`git pull`や`git fetch`がタグを追跡しないことが保証されます。その後の明示的なタグのフェッチは引き続き機能します(git-fetch[1]を参照)。
デフォルトではタグがクローンされるため、`--tags`を渡すことは、以前の`--no-tags`をキャンセルしない限り、通常は何も影響しません。
`--single-branch`と組み合わせて、クローンされた単一のブランチ以外の参照を持たないブランチをクローンおよび維持するために使用できます。これは、例えば、検索インデックス作成のために、特定のリポジトリのデフォルトブランチの最小限のクローンを維持する場合に役立ちます。
-
--recurse-submodules[=<pathspec>]
-
クローンが作成された後、提供された<pathspec>に基づいて、その中のサブモジュールを初期化およびクローンします。`=<pathspec>`が提供されない場合、全てのサブモジュールが初期化およびクローンされます。このオプションは、複数のエントリからなるパススペックに対して複数回指定できます。結果として生成されるクローンは、提供されたパススペックに`submodule.active`が設定されます。パススペックが提供されない場合は、「`.`」(全てのサブモジュールを意味する)が設定されます。
サブモジュールはデフォルト設定を使用して初期化およびクローンされます。これは、クローン完了直後に`git submodule update --init --recursive <pathspec>`を実行するのと同等です。クローンされたリポジトリにワークツリー/チェックアウトがない場合(つまり、`--no-checkout`/`-n`、`--bare`、または`--mirror`のいずれかが与えられた場合)、このオプションは無視されます。
-
--[no-]shallow-submodules
-
クローンされる全てのサブモジュールは、深さ1のシャロークローンになります。
-
--[no-]remote-submodules
-
クローンされる全てのサブモジュールは、スーパープロジェクトに記録されたSHA-1ではなく、サブモジュールのリモートトラッキングブランチの状態を使用してサブモジュールを更新します。`git submodule update`に`--remote`を渡すのと同等です。
-
--separate-git-dir=<git-dir>
-
クローンされたリポジトリを本来あるべき場所に配置する代わりに、指定されたディレクトリに配置し、そこにファイルシステム非依存のGitシンボリックリンクを作成します。これにより、Gitリポジトリをワーキングツリーから分離することができます。
-
--ref-format=<ref-format>
-
リポジトリの指定された参照ストレージ形式を指定します。有効な値は次のとおりです。
-
`files`はpacked-refs付きのルーズファイル用です。これがデフォルトです。
-
`reftable`はreftable形式用です。この形式は実験的であり、内部構造は変更される可能性があります。
-
-
-j
<n> -
--jobs
<n> -
同時にフェッチされるサブモジュールの数。デフォルトは`submodule.fetchJobs`オプションです。
- <repository>
-
クローン元の(リモートである可能性のある)<repository>。リポジトリの指定に関する詳細については、下記のGIT URLセクションを参照してください。
- <directory>
-
クローン先の新しいディレクトリの名前。<directory>が明示的に指定されない場合、ソースリポジトリの「人間らしい」部分が使用されます(`/path/to/repo.git`の場合は`repo`、`host.xz:foo/.git`の場合は`foo`)。既存のディレクトリへのクローンは、そのディレクトリが空の場合にのみ許可されます。
-
--bundle-uri=<uri>
-
リモートからフェッチする前に、指定された<uri>からバンドルをフェッチし、データをローカルリポジトリに展開します。バンドル内の参照は、非表示の`refs/bundle/*`名前空間に保存されます。このオプションは、`--depth`、`--shallow-since`、および`--shallow-exclude`とは互換性がありません。
Git URL
一般に、URLにはトランスポートプロトコル、リモートサーバーのアドレス、およびリポジトリへのパスに関する情報が含まれます。トランスポートプロトコルによっては、これらの情報の一部が欠けている場合があります。
Gitはssh、git、http、httpsプロトコルをサポートしています(加えて、ftpとftpsはフェッチに使用できますが、これは非効率的であり非推奨です。使用しないでください)。
ネイティブ転送(すなわち`git://` URL)は認証を行わないため、セキュリティの保護されていないネットワークでは注意して使用する必要があります。
次の構文を使用できます。
-
ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
-
git://<host>[:<port>]/<path-to-git-repo>
-
http[s]://<host>[:<port>]/<path-to-git-repo>
-
ftp[s]://<host>[:<port>]/<path-to-git-repo>
SSHプロトコルでは、代替のscpのような構文も使用できます。
-
[<user>@]<host>:/<path-to-git-repo>
この構文は、最初のコロンの前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカルパスを区別するのに役立ちます。例えば、ローカルパス`foo:bar`は、SSH URLとして誤解されないように、絶対パスまたは`./foo:bar`として指定できます。
SSHおよびGitプロトコルは、さらに`~<username>`の展開をサポートしています。
-
ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
-
git://<host>[:<port>]/~<user>/<path-to-git-repo>
-
[<user>@]<host>:~<user>/<path-to-git-repo>
ローカルリポジトリの場合、Gitでネイティブにサポートされている次の構文も使用できます。
-
/path/to/repo.git/
-
file:///path/to/repo.git/
これら2つの構文はほとんど同等ですが、前者は`--local`オプションを含意します。
`git clone`、`git fetch`、`git pull`は(`git push`は除く)、適切なバンドルファイルも受け入れます。git-bundle[1]を参照してください。
Gitが特定のトランスポートプロトコルの扱い方を知らない場合、`remote-<transport>`リモートヘルパーが存在すれば、それを使用しようとします。リモートヘルパーを明示的に要求するには、次の構文を使用できます。
-
<transport>::<address>
ここで、<address>はパス、サーバーとパス、または呼び出される特定のリモートヘルパーによって認識される任意のURLのような文字列である場合があります。詳細については、gitremote-helpers[7]を参照してください。
多数の似た名前のリモートリポジトリがあり、それらに対して異なる形式を使用したい場合(使用するURLが機能するURLに書き換えられるように)、次のような形式の設定セクションを作成できます。
[url "<actual-url-base>"] insteadOf = <other-url-base>
例えば、これを使用すると、
[url "git://git.host.xz/"] insteadOf = host.xz:/path/to/ insteadOf = work:
"work:repo.git"や"host.xz:/path/to/repo.git"のようなURLは、URLを受け入れるあらゆるコンテキストで"git://git.host.xz/repo.git"に書き換えられます。
プッシュ専用のURLを書き換えたい場合は、次のような形式の設定セクションを作成できます。
[url "<actual-url-base>"] pushInsteadOf = <other-url-base>
例えば、これを使用すると、
[url "ssh://example.org/"] pushInsteadOf = git://example.org/
"git://example.org/path/to/repo.git"のようなURLは、プッシュ時には"ssh://example.org/path/to/repo.git"に書き換えられますが、プル時には元のURLが引き続き使用されます。
例
-
アップストリームからクローンする
$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux $ cd my-linux $ make
-
現在のディレクトリから借用し、チェックアウトせずにローカルクローンを作成する
$ git clone -l -s -n . ../copy $ cd ../copy $ git show-branch
-
既存のローカルディレクトリから借用しながら、アップストリームからクローンする
$ git clone --reference /git/linux.git \ git://git.kernel.org/pub/scm/.../linux.git \ my-linux $ cd my-linux
-
変更を公開するためのベアリポジトリを作成する
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
-
異なるユーザーのローカルリポジトリをクローンする
$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
設定
このセクションのこの行より下は、git-config[1]ドキュメントから選択的に含まれています。内容はそちらにあるものと同じです。
-
init.templateDir
-
テンプレートがコピーされるディレクトリを指定します。(git-init[1]の「TEMPLATE DIRECTORY」セクションを参照してください。)
-
init.defaultBranch
-
例えば新しいリポジトリを初期化する際に、デフォルトのブランチ名を上書きすることができます。
-
init.defaultObjectFormat
-
新しいリポジトリのデフォルトのオブジェクト形式を上書きすることができます。git-init[1]の`--object-format=`を参照してください。コマンドラインオプションと`GIT_DEFAULT_HASH`環境変数の両方がこの設定よりも優先されます。
-
init.defaultRefFormat
-
新しいリポジトリのデフォルトの参照ストレージ形式を上書きすることができます。git-init[1]の`--ref-format=`を参照してください。コマンドラインオプションと`GIT_DEFAULT_REF_FORMAT`環境変数の両方がこの設定よりも優先されます。
-
clone.defaultRemoteName
-
リポジトリをクローンする際に作成されるリモートの名前。デフォルトは`origin`です。`--origin`コマンドラインオプションを渡すことで上書きできます。
-
clone.rejectShallow
-
リポジトリがシャロークローンである場合、クローンを拒否します。これは、コマンドラインで`--reject-shallow`オプションを渡すことで上書きできます。
-
clone.filterSubmodules
-
部分クローンフィルターが提供され(git-rev-list[1]の`--filter`を参照)、`--recurse-submodules`が使用される場合、サブモジュールにもフィルターを適用します。
Git
git[1]スイートの一部