SYNOPSIS
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>]
DESCRIPTION
リポジトリを新しく作成されたディレクトリにクローン(clone;複製)し、複製されたリポジトリ内の各ブランチのリモート追跡ブランチを作成し(git
branch --remotes
を使用して表示できます)、複製されたリポジトリの現在アクティブなブランチからフォークされた初期ブランチを作成してチェックアウトします。
クローン後、引数のない git fetch は、すべてのリモート追跡ブランチを更新し、加えて、引数のない git pull
は、存在する場合、リモートのmasterブランチを現在のmasterブランチにマージします(これは、 --single-branch
が指定されている場合は当てはまりません。以下参照)。
このデフォルト設定は、 refs/remotes/origin の下にリモートブランチヘッドへの参照を作成し、remote.origin.url
と remote.origin.fetch 設定変数を初期化することによって実現されます。
OPTIONS
-
-l -
--local -
複製元のリポジトリがローカルマシン上にある場合、このフラグは通常の 「Git対応」転送メカニズムをバイパスし、オブジェクトおよびrefsディレクトリの下にあるHEADおよびすべてのコピーを作成することでリポジトリを複製します。
.git/objects/ディレクトリの下のファイルは、可能な場合はスペースを節約するためにハードリンクされています。リポジトリがローカルパス(例:
/path/to/repo)として指定されている場合、これがデフォルトであり、--localは基本的に何も操作しません(no-op)です。 リポジトリがURLとして指定されている場合、このフラグは無視されます(ローカル最適化は使用されません)。--no-localを指定すると、/path/to/repoが指定されたときデフォルトが上書きされ、代わりに通常のGit転送が使用されます。Noteこの操作は、 srcを変更しながらcp -r src dstを実行するのと同様に、ソースリポジトリへの同時変更と競合する可能性があります。 -
--no-hardlinks -
ハードリンクを使用する代わりに、ローカルファイルシステム上のリポジトリからのクローン作成プロセスで、ファイルを
.git/objectsディレクトリの下にコピーするように強制します。 これは、リポジトリのバックアップを作成しようとしている場合に望ましい場合があります。 -
-s -
--shared -
クローンを作成するリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、オブジェクトをソースリポジトリと共有するように
.git/objects/info/alternatesを自動的に設定します。 結果のリポジトリは、独自のオブジェクトなしで開始されます。Noteこれは危険な操作になり得ます。あなたが、それが何をするのか理解していない限り、使用してはいけません。 このオプションを使用してリポジトリのクローンを作成してから、ソースリポジトリ内のブランチを削除する(または既存のコミットを参照しないようにする他のGitコマンドを使用する)と、一部のオブジェクトが参照されなくなる(unreferenced)(または宙ぶらりん(dangling)になる)可能性があります。 そうしたオブジェクトは、 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> -
参照リポジトリがローカルマシン上にある場合は、参照リポジトリからオブジェクトを取得するように
.git/objects/info/alternatesを自動的に設定します。 既存のリポジトリをalternateとして使用すると、クローンされるリポジトリからコピーする必要のあるオブジェクトが少なくなり、ネットワークとローカルのストレージコストが削減されます。--reference-if-ableを使用すると、存在しないディレクトリはクローンを中断する代わりに警告を出してスキップします。Note--sharedオプションと--dissociateオプションについては「NOTE」を参照してください。 -
--dissociate -
ネットワーク転送を減らすために
--referenceオプションで指定された参照リポジトリからオブジェクトを借用しクローン作成後に、借用したオブジェクトの必要なローカルコピーを作成し、借用を停止(stop)します。 このオプションは、すでに他のリポジトリからオブジェクトを借りているリポジトリからローカルにクローンを作成するときにも使用できます—新しいリポジトリは同一のリポジトリからオブジェクトを借りますが、このオプションを使用して借用を停止できます。 -
-q -
--quiet -
静かにします。進行状況は標準エラーストリームに報告されません。
-
-v -
--verbose -
賑やかにします。標準エラーストリームへの進行状況のレポートには影響しません。
-
--progress -
--quietが指定されていない限り、進行状況は、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。 このフラグは、標準エラーストリームが端末に送信されていない場合でも、進行状況を強制します。 -
--server-option=<option> -
プロトコルバージョン2を使用して通信する場合、指定の文字列をサーバーに送信します。指定の文字列には、NULまたはLF文字を含めることはできません。 不明なオプションを含むサーバーオプションのサーバー処理は、サーバー固有です。 複数の
--server-option=<option>が指定されている場合、それらはすべてコマンドラインにリストされている順序で相手側に送信されます。 -
-n -
--no-checkout -
クローンの完了後、HEADのチェックアウトは実行されません。
-
--[no-]reject-shallow -
ソースリポジトリが浅い(shallow)リポジトリの場合は失敗します。 clone.rejectShallow 構成変数を使用して、デフォルトを指定できます。
-
--bare -
「ベア」(bare=裸の)Gitリポジトリを作成します。 つまり、
<directory>を作成して管理ファイルを<directory>/.gitに配置する代わりに、<directory>自体を$GIT_DIRにします。 作業ツリーをチェックアウトする場所がないため、これは明らかに--no-checkoutを意味します。 また、リモートのブランチヘッドは、refs/remotes/origin/にマッピングせずに、対応するローカルブランチヘッドに直接コピーされます。 このオプションを使用すると、リモート追跡ブランチも関連する構成変数も作成されません。 -
--sparse -
(sparse:まばらなの意)作業ディレクトリがリポジトリのルートにあるファイルのみで開始するように、sparse-checkoutファイルを初期化します。 sparse-checkoutファイルは、必要に応じて作業ディレクトリを拡張するように変更できます。
-
--filter=<filter-spec> -
部分クローン(partial clone)機能を使用して、サーバーが特定のオブジェクトフィルターに従って到達可能なオブジェクトのサブセットを送信するように要求します。
--filterを使用する場合、提供された<filter-spec>が部分クローンフィルターに使用されます。 たとえば、--filter=blob:noneは、Gitで必要になるまで、すべてのブロブ(ファイルの内容)を除外します。 また、--filter=blob:limit=<size>は、少なくとも<size>のサイズのすべてのブロブを除外します。 フィルタ仕様の詳細については、 git-rev-list(1) の--filterオプションを参照してください。 -
--mirror -
ソースリポジトリのミラーを設定します。 これは
--bareを意味します。--bareと比較して、--mirrorは、ソースのローカルブランチをターゲットのローカルブランチにマップするだけでなく、すべての参照(リモート追跡ブランチ、noteなどを含む)をマップし、以下のようなrefspec構成をセットアップします。 これらのすべての参照は、ターゲットリポジトリ内のgit remote updateによって上書きされます。 -
-o <name> -
--origin <name> -
リモート名
originを使用してアップストリームリポジトリを追跡する代わりに、<name>を使用します。 構成(config)のclone.defaultRemoteNameをオーバーライドします。 -
-b <name> -
--branch <name> -
新しく作成されたHEADを、複製されたリポジトリのHEADが指すブランチにポイントする代わりに、代わりに
<name>ブランチをポイントします。 非ベアリポジトリでは、これはチェックアウトされるブランチです。--branchはタグを取得し、結果のリポジトリでそのコミット時にHEADを切り離す(detach)こともできます。 -
-u <upload-pack> -
--upload-pack <upload-pack> -
これが指定され、クローンを作成するリポジトリにssh経由でアクセスする場合、これは、通信相手側(the other end)で実行されるコマンドのデフォルト以外のパスを指定します。
-
--template=<template_directory> -
テンプレートを使用するディレクトリを指定します。 (git-init(1) の「TEMPLATE DIRECTORY」セクションを参照してください。)
-
-c <key>=<value> -
--config <key>=<value> -
新しく作成されたリポジトリに構成変数を設定します。 これは、リポジトリが初期化された直後または、リモート履歴がフェッチされる前または、ファイルがチェックアウトされる前に有効になります。 キーは、 git-config(1) で期待されるものと同じ形式です(例:
core.eol=true)。 同じキーに複数値が指定されている場合、各値は構成ファイルに書き込まれます。 これにより、たとえば、originのリモートにフェッチrefspecを追加しても安全になります。現在の実装の制限により、一部の構成変数は、最初のフェッチとチェックアウトが完了するまで有効になりません。 有効にならないことがわかっている構成変数は、
remote.<name>.mirrorとremote.<name>.tagOptです。 代わりに、対応する--mirrorおよび--no-tagsオプションを使用してください。 -
--depth <depth> -
指定されたコミット数に切り捨てられた履歴を持つ「浅い」クローン(shallow clone)を作成します。 すべてのブランチの先端近くの履歴をフェッチするために
--no-single-branchが指定されていない限り、--single-branchを意味します。 サブモジュールを浅くクローンする場合は、--shallow-submodulesも渡します。 -
--shallow-since=<date> -
指定した日時以降の履歴を持つ浅いクローン(shallow clone)を作成します。
-
--shallow-exclude=<revision> -
指定のリモートブランチまたはタグから到達可能なコミットを除外して、履歴を持つ浅いクローン(shallow clone)を作成します。 このオプションは複数回指定できます。
-
--[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>] -
クローンが作成されたら、提供されたパススペックに基づいてサブモジュールを初期化し、クローンを作成します。 パススペックが指定されていない場合、すべてのサブモジュールが初期化され、クローン化されます。 このオプションは、複数のエントリで構成されるパススペックに対して複数回指定できます。 結果として得られるクローンには
submodule.activeが指定され、パス指定がない場合は.(すべてのサブモジュールを意味します) が設定されます。サブモジュールは、デフォルト設定を使用して初期化およびクローン化されます。 これは、クローンが終了した直後に
git submodule update --init --recursive <pathspec>を実行するのと同じです。 クローンされたリポジトリに ワークツリー/チェックアウト がない場合(つまり、--no-checkout/-nまたは--bareまたは--mirrorのいずれかが指定されている場合)、このオプションは無視されます。 -
--[no-]shallow-submodules -
クローンされるすべてのサブモジュールは、深さが1の浅さののになります。
-
--[no-]remote-submodules -
クローン化されるすべてのサブモジュールは、スーパープロジェクトの記録されたSHA-1ではなく、サブモジュールのリモート追跡ブランチのステータスを使用してサブモジュールを更新します。
--remoteをgit submodule updateに渡すのと同じです。 -
--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が特定のトランスポートプロトコルを処理する方法を知らない場合、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は、任意のコンテキストで、"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のままです。
EXAMPLES
-
アップストリームからのクローン:
$ 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 -
変更を公開するためのベア(bare)リポジトリを作成します:
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
GIT
Part of the git(1) suite