Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.33.0 → 2.34.1 no changes
- 2.32.0 06/06/21
- 2.30.2 → 2.31.1 no changes
- 2.30.1 02/08/21
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.28.1 no changes
- 2.28.0 07/27/20
- 2.27.1 no changes
- 2.27.0 06/01/20
- 2.25.1 → 2.26.3 no changes
- 2.25.0 01/13/20
- 2.23.1 → 2.24.4 no changes
- 2.23.0 08/16/19
- 2.22.2 → 2.22.5 no changes
- 2.22.1 08/11/19
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.18.1 → 2.20.5 no changes
- 2.18.0 06/21/18
- 2.17.0 → 2.17.6 no changes
- 2.16.6 12/06/19
- 2.15.4 no changes
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 no changes
- 2.11.4 09/22/17
- 2.10.5 no changes
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.4.12 → 2.6.7 no changes
- 2.3.10 09/28/15
概要
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>] [--] <repository> [<directory>]
説明
リポジトリを新たに作成されたディレクトリにクローンし、クローンされたリポジトリの各ブランチにリモートトラッキングブランチを作成し(`git branch --remotes`で確認できます)、クローンされたリポジトリの現在アクティブなブランチからフォークされた初期ブランチを作成、チェックアウトします。
また、引数なしの git pull
は、リモートのマスターブランチがあれば、それを現在のマスターブランチにマージします (これは "-single-branch" を指定した場合には当てはまりません。後述します)。
このデフォルトの構成は、リモートブランチヘッドへの参照を refs/remotes/origin
の下に作成し、構成変数 remote.origin.url
と remote.origin.fetch
を初期化することで実現しています。
オプション
- -l
- --local
-
クローンを作成するリポジトリがローカルマシン上にある場合、このフラグは通常の「Git を意識した」転送メカニズムをバイパスして、HEAD と objects および refs ディレクトリ以下のすべてのコピーを作成してリポジトリをクローンします。
.git/objects/
ディレクトリ以下のファイルは、可能な限りスペースを節約するためにハードリンクされます。リポジトリがローカルパス(例:
/path/to/repo
)で指定されている場合は、これがデフォルトであり、--local は基本的に何もしません。 リポジトリが URL として指定されている場合は、このフラグは無視されます(ローカルでの最適化も使用されません)。--no-local`を指定すると、
/path/to/repo`が指定されたときのデフォルトを上書きし、代わりに通常のGitトランスポートを使用します。注意: この操作は、ソースリポジトリの同時変更と競合する可能性があります。 この操作は、ソースリポジトリの同時変更と競合する可能性があります。これは、
src
を変更しながらcp -r src dst
を実行するのと同じです。 src` を変更しながらcp -r src dst
を実行するのと同じように、この操作はソースリポジトリの同時変更と競合する可能性があります。 - --no-hardlinks
-
ローカルファイルシステム上のリポジトリからクローン作成プロセスを強制して、ハードリンクを使用するのではなく'.git/objects' ディレクトリの下にファイルをコピーします。これは、リポジトリのバックアップを作成する場合に適しています。
- -s
-
クローンを作成するリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、オブジェクトをソースリポジトリと共有するように `.git / objects / info / alternates`を自動的に設定します。結果のリポジトリは、独自のオブジェクトなしで開始されます。
注意: これは危険な操作になりうるため、理解できない限り使用*しないで* ください。このオプションを使ってリポジトリをクローンし、ソースリポジトリで ブランチを削除(あるいは既存のコミットを参照しなくなるようなGitコマンド を使用)すると、いくつかのオブジェクトが参照されなくなる (あるいはぶら 下がる) ことがあります。 これらのオブジェクトは、自動的に`git maintenance run --auto`を呼び出す通常の Git 操作 (たとえば
git commit
) で削除されるかもしれません。(参照 git-maintenance[1].) もしこれらのオブジェクトが削除され、クローンリポジトリ から参照されていた場合は、クローンリポジトリが壊れてしまいます。なお、
--shared
でクローンされたリポジトリでgit repack
を--local
オプションを指定せずに 実行すると、ソースリポジトリのオブジェクトがクローンされたリポジトリのパックにコピーされ、clone --shared
によるディスクスペースの節約効果がなくなります。 しかし、`--local`オプションをデフォルトで使用する`git gc`を実行することは安全です。`--shared`でクローンされたリポジトリのソースリポジトリへの依存関係を解消したい場合は、単純に`git repack -a`を実行して、ソースリポジトリのすべてのオブジェクトをクローンされたリポジトリのパックにコピーします。
- --reference[-if-able] <repository>
-
参照リポジトリがローカルマシン上にある場合は、参照リポジトリからオブジェクトを取得するように
.git/objects/info/alternates
を自動的に設定します。既存のリポジトリを代替として使用すると、クローンを作成するリポジトリからコピーする必要のあるオブジェクトが少なくなり、ネットワークとローカルのストレージコストが削減されます。 `--reference-if-able`を使用すると、クローンを中止する代わりに、存在しないディレクトリがスキップされ、警告が表示されます。注意:
--shared
オプションの 注意 を参照してください。 また、`--dissociate`オプションも参照してください。 - --dissociate
-
ネットワーク転送を減らすために、
--reference
オプションで指定された参照リポジトリからオブジェクトを借用し、借用したオブジェクトの必要なローカルコピーを作成してクローンを作成した後に、借用を停止します。 このオプションは、すでに他のリポジトリからオブジェクトを借用しているリポジトリからローカルにクローンを作成する場合にも使用できます。新しいリポジトリは同じリポジトリからオブジェクトを借用しますが、このオプションを使用して借用を停止することができます。 - -q
- --quiet
-
静かに動作します。 進行状況は標準エラーストリームに報告されません。
- -v
- --verbose
-
冗長に実行します。標準エラーストリームへの進行状況の報告には影響しません。
- --progress
-
標準エラーストリームがターミナルに接続されている場合、`--quiet`が指定されていない限り、進捗状況はデフォルトで標準エラーストリームに報告されます。このフラグは、標準エラーストリームがターミナルに向けられていない場合でも、進行状況を強制的に報告します。
- --server-option=<option>
-
プロトコルバージョン2を使用して通信するときに、指定された文字列をサーバーに送信します。指定された文字列には、NUL または LF 文字を含めることはできません。不明なオプションを含むサーバーオプションのサーバーの処理は、サーバー固有です。複数の
--server-option=<option>
が指定されている場合、それらはすべてコマンドラインにリストされている順序で反対側に送信されます。 - -n
- --no-checkout
-
クローンの完了後、HEAD のチェックアウトは行われません。
- --[no-]reject-shallow
-
ソースリポジトリがシャローリポジトリの場合は失敗します。 clone.rejectShallow 設定変数でデフォルトを指定することができます。
- --bare
-
「ベア」Git リポジトリを作成します。 つまり、
<directory>
を作成して管理用のファイルを<directory>/.git
に置くのではなく、<directory>
自体を$GIT_DIR
にするのです。これは明らかに、作業ツリーをチェックアウトする場所がないため、--no-checkout
を意味します。 また、リモートのブランチヘッドは、`refs/remotes/origin/`にマッピングされることなく、対応するローカルのブランチヘッドに直接コピーされます。 このオプションを使用すると、リモートトラッキングブランチも関連する設定変数も作成されません。 - --sparse
-
sparse-checkout ファイルを初期化して、作業ディレクトリがリポジトリのルートにあるファイルだけで始まるようにします。sparse-checkout ファイルは、必要に応じて作業ディレクトリを増やすように変更することができます。
- --filter=<filter-spec>
-
パーシャルクローン機能を使って、与えられたオブジェクト・フィルタにしたがって、到達可能なオブジェクトのサブセットを送るようにサーバに要求します。
--filter
を使う場合、パーシャルクローンのフィルタには、与えられた`<filter-spec>が使われます。たとえば、 `--filter=blob:none
とすると、Gitが必要とするまで、すべてのblob(ファイルの内容)をフィルタリングします。また、--filter=blob:limit=<size>
とすると、少なくとも`<size>以上のサイズのblobをすべてフィルタリングします。フィルターの仕様についての詳細は、 git-rev-list[1] の `--filter
オプションを参照してください。 - --mirror
-
ソースリポジトリのミラーを設定します。これは
--bare`を意味します。 `--bare`と比較して、
--mirror`は、ソースのローカルブランチをターゲットのローカルブランチにマップするだけでなく、すべての参照(リモートトラッキングブランチ、メモなどを含む)をマップし、ターゲットリポジトリの`git remote update`によってこれらのrefがすべて上書きされるようにrefspecの設定を行います。 - -o <name>
- --origin <name>
-
上流のリポジトリを追跡するためにリモート名
origin
を使用する代わりに、<name>
を使用します。 コンフィグのclone.defaultRemoteName
をオーバーライドします。 - -b <name>
- --branch <name>
-
新しく作成された HEAD を、クローンされたリポジトリの HEAD が指すブランチに向けるのではなく、代わりに
<name>
ブランチを指します。ベアリポジトリでない場合は、このブランチがチェックアウトされます。 また、--branch
はタグを取ることができ、できあがったリポジトリのそのコミットの HEAD をデタッチします。 - -u <upload-pack>
- --upload-pack <upload-pack>
-
指定された場合、クローンを作成するリポジトリにssh経由でアクセスすると、相手側で実行するコマンドのデフォルト以外のパスを指定します。
- --template=<template_directory>
-
テンプレートを使用するディレクトリを指定します。(git-init[1]の "TEMPLATE DIRECTORY "セクションを参照)
- -c <key>=<value>
- --config <key>=<value>
-
新しく作成されたリポジトリに設定変数を指定します。これは、リポジトリが初期化された直後で、リモートの履歴が取得されたり、ファイルがチェックアウトされたりする前に有効になります。 キーは git-config[1] で期待されるのものと同じ形式です (例:
core.eol=true
)。同じキーに複数の値が与えられた場合は、それぞれの値が設定ファイルに書き込まれます。これにより、たとえばオリジンのリモートに追加のフェッチrefspecを追加しても安全になります。現在の実装の制限により、一部の設定変数は最初のフェッチとチェックアウトが終わるまで有効になりません。 反映されない設定変数には次のようなものがあります。
remote.<name>.mirror
とremote.<name>.tagOpt
です。 代わりに、対応する--mirror
と--no-tags
オプションを使用してください。 - --depth <depth>
-
指定された数のコミットに切り詰められたヒストリーを持つ、「浅い」クローンを作成します。
--no-single-branch
が指定されていない限り、--single-branch
を意味し、すべてのブランチの先端付近の履歴を取得します。サブモジュールを浅くクローンしたい場合には、`--shallow-submodules`も指定してください。 - --shallow-since=<date>
-
指定した日時以降の履歴を持つシャロークローンを作成します。
- --shallow-exclude=<revision>
-
指定したリモートブランチやタグから到達可能なコミットを除いた、履歴付きのシャロークローンを作成します。 このオプションは複数回指定できます。
- --[no-]single-branch
-
--branch`オプションで指定されたブランチ、またはリモートの`HEAD`が指し示すプライマリブランチの先端に至るまでの履歴のみをクローンします。 結果として得られるリポジトリをさらにフェッチすると、最初のクローン作成時にこのオプションが使用されたブランチのリモートトラッキングブランチのみが更新されます。 `--single-branch
クローンを作成したときに、リモートの HEAD がどのブランチも指していなかった場合は、リモートトラッキングブランチは作成されません。 - --no-tags
-
タグをクローンせず、コンフィグで
remote.<remote>.tagOpt=--no-tags
と指定することで、今後のgit pull
やgit fetch
の操作でタグを追いかけることができなくなります。その後、明示的にタグを取得しても動作します(git-fetch[1]を参照)。--single-branch
と一緒に使うことで、クローンされた単一のブランチ以外の参照を持たないブランチをクローンして維持することができます。これは、例えば、あるリポジトリのデフォルトブランチの最小限のクローンを維持して、検索インデックスを作成するのに便利です。 - --recurse-submodules[=<pathspec>]
-
クローンが作成されると、与えられたpathspecに基づいて、その中のサブモジュールを初期化し、クローンを作成します。 pathspecが指定されていない場合は、すべてのサブモジュールが初期化され、クローンが作成されます。 このオプションは、複数のエントリからなる pathspec に対して複数回指定できます。 できあがったクローンは、
submodule.active
に与えられた pathspec が、あるいは "." (すべてのサブモジュールを意味する)が pathspec が与えられなかった場合に設定されます。サブモジュールは初期化され、デフォルトの設定でクローンされます。これは、クローンが終了した直後に、
git submodule update --init --recursive <pathspec>
を実行するのと同じです。このオプションは、クローンされるリポジトリに worktree/checkout がない場合(つまり、--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リポジトリを作業ツリーから切り離すことができるようになります。
- -j <n>
- --jobs <n>
-
同時に取得するサブモジュールの数です。 既定値は
submodule.fetchJobs
オプションになります。 - <repository>
-
クローンを作成するリポジトリ(リモートの場合もあります)。 リポジトリの指定についての詳細は、後の GIT URLS セクションを参照してください。
- <directory>
-
クローンを作成する新しいディレクトリの名前です。 ディレクトリが明示的に指定されていない場合は、ソースリポジトリの "humanish" の部分が使用されます(
/path/to/repo.git
の場合はrepo
、host.xz:foo/.git
の場合はfoo
となります)。 既存のディレクトリへのクローン作成は、そのディレクトリが空の場合のみ可能です。
GIT URLS
一般的に、URLにはトランスポートプロトコル、リモートサーバーのアドレス、リポジトリへのパスなどの情報が含まれています。 トランスポートプロトコルによっては、これらの情報の一部が含まれていない場合があります。
Gitは、ssh、git、http、httpsのプロトコルをサポートしています(さらに、ftp、ftpsもフェッチに使用できますが、これは効率が悪く、非推奨ですので使用しないでください)。
ネイティブトランスポート (つまり git:// URL) は認証を行わないので、セキュリティのないネットワークでは注意が必要です。
以下の構文を使用することができます。
-
ssh://[user@]host.xz[:port]/path/to/repo.git/
-
git://host.xz[:port]/path/to/repo.git/
-
http[s]://host.xz[:port]/path/to/repo.git/
-
ftp[s]://host.xz[:port]/path/to/repo.git/
scpのような別の構文をsshプロトコルで使用することもできます。
-
[user@]host.xz:path/to/repo.git/
この構文は、最初のコロンより前にスラッシュがない場合にのみ認識されます。これにより、コロンを含むローカルパスを区別することができます。例えば、ローカルパス foo:bar
を絶対パスまたは ./foo:bar
として指定することで、ssh の url と誤認されるのを防ぐことができます。
sshおよびgitプロトコルでは、さらに ~username の展開がサポートされています。
-
ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
-
git://host.xz[:port]/~[user]/path/to/repo.git/
-
[user@]host.xz:/~[user]/path/to/repo.git/
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" になるコンテキストで書き換えられます。
プッシュのみで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
Part of the git[1] suite