SYNOPSIS
gitclone[--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>]
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対応」転送メカニズムをバイパスし、 HEAD のコピーと、 オブジェクトや refs のディレクトリの下にあるすべてのモノのコピーを作成することでリポジトリを複製します。
.git/objects/ディレクトリの下のファイルは、可能な場合はスペースを節約するためにハードリンクされています。リポジトリがローカル・パス(例:
/path/to/repo)として指定されている場合、これがデフォルトであり、--localは基本的に何も操作しません(no-op)。 リポジトリがURLとして指定されている場合、このフラグは無視されます(ローカル最適化は使用されません)。--no-localを指定すると、/path/to/repoが指定されたときはデフォルトが上書きされ、代わりに通常のGit転送が使用されます。リポジトリの
$GIT_DIR/objectsにシンボリック・リンクがある場合、 または$GIT_DIR/objectsがシンボリック・リンクである場合、 クローンは失敗します。 これは、 シンボリック・リンクの参照を解除(デリファレンス)することにより、 ファイルが意図せずコピーされるのを防ぐためのセキュリティ対策です。注意: この操作は、 <src> を変更しながら
cp-r<src> <dst> を実行するのと同様に、 ソースリポジトリへの同時変更と競合する可能性が あります。 -
--no-hardlinks -
ハードリンクを使用する代わりに、ローカルファイルシステム上のリポジトリからのクローン作成プロセスで、ファイルを
.git/objectsディレクトリの下にコピーするように強制します。 これは、リポジトリのバックアップを作成しようとしている場合に望ましい場合があります。 -
-s -
--shared -
クローンを作成するリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、オブジェクトをソースリポジトリと共有するように
.git/objects/info/alternatesを自動的に設定します。 結果のリポジトリは、独自のオブジェクトなしで開始されます。Noteこれは危険な操作になり得ます。あなたが、それが何をするのか理解していない限り、使用してはいけません。 このオプションを使用してリポジトリのクローンを作成してから、ソースリポジトリ内のブランチを削除する(または既存のコミットを参照しないようにする他のGitコマンドを使用する)と、一部のオブジェクトが参照されなくなる(unreferenced)(または宙ぶらりん(dangling)になる)可能性があります。 そうしたオブジェクトは、 gitmaintenancerun--autoを自動的に呼び出す通常のGit操作(gitcommitなど)によって削除される場合があります(git-maintenance(1) 参照)。 これらのオブジェクトが削除され、クローンされたリポジトリーによって参照された場合、クローンされたリポジトリーは破損します。注意:
--sharedでクローンされたリポジトリで--localオプションなしでgitrepackを実行すると、オブジェクトがソースリポジトリからクローンされたリポジトリのパックにコピーされ、clone--sharedによるディスクスペースの節約はなくなります。 ただし、デフォルトで--localオプションを使用するgitgcを実行するのは安全です。--sharedでクローンされたリポジトリのソースリポジトリへの依存関係を解消したい場合、gitrepack-aを実行するだけで、すべてのオブジェクトをソースリポジトリから、クローンされたリポジトリのパックにコピーできます。 -
--reference[-if-able] <repository> -
参照リポジトリ(<repository>)がローカルマシン上にある場合は、参照リポジトリ(<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> が指定されている場合、それらはすべてコマンドラインにリストされている順序で相手側に送信されます。 コマンドラインから--server-option=<option> が指定されていない場合は、 代わりに構成変数remote.<name>.serverOptionの値が使用されます。 -
-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 -
最上位ディレクトリ内のファイルのみが最初に存在するスパース・チェックアウトを採用します。 git-sparse-checkout(1) コマンドを使用して、必要に応じて作業ディレクトリを拡張できます。
-
--filter=<filter-spec> -
部分クローン(partial clone)機能を使用して、サーバーが特定のオブジェクトフィルターに従って到達可能なオブジェクトのサブセットを送信するように要求します。
--filterを使用する場合、提供された <filter-spec> が部分クローンフィルターに使用されます。 たとえば、--filter=blob:noneは、Gitで必要になるまで、すべてのブロブ(ファイルの内容)を除外します。 また、--filter=blob:limit=<size> は、少なくとも <size> のサイズのすべてのブロブを除外します。 フィルタ仕様の詳細については、 git-rev-list(1) の--filterオプションを参照してください。 -
--also-filter-submodules -
また、リポジトリ内のすべてのサブモジュールに部分クローン・フィルタ(partial clone filter)を適用します。
--filterと--recurse-submodulesが必要です。 これは、clone.filterSubmodules設定オプションを設定することで、デフォルトでオンにすることができます。 -
--mirror -
ソース・リポジトリのミラーを設定します。 これは
--bareの機能を含んでいます。--bareと比較して、--mirrorはソースのローカル・ブランチをターゲットのローカル・ブランチにマッピングするだけでなく、 すべての refs(リモート追跡ブランチ、 noteなどを含む)をマッピングし、 ターゲット・リポジトリ内のgitremoteupdateでこれらの refs がすべて上書きされるように refspec 構成を設定します。 -
-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> -
新しく作成されたリポジトリに構成変数を設定します。 これは、リポジトリが初期化された直後または、リモート履歴がフェッチされる前または、ファイルがチェックアウトされる前に有効になります。 <key> は、 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=<ref> -
指定のリモートブランチまたはタグから到達可能なコミットを除外して、履歴を持つ浅いクローン(shallow clone)を作成します。 このオプションは複数回指定できます。
-
--[no-]single-branch -
--branchオプションで指定された、またはリモートのプライマリブランチのHEADが指す単一のブランチの先端につながる履歴のみをクローンします。 結果のリポジトリにさらにフェッチすると、このオプションが最初のクローン作成に使用されたブランチのリモート追跡ブランチのみが更新されます。--single-branchクローンが作成されたときに、リモートのHEADがどのブランチも指さなかった場合、リモート追跡ブランチは作成されません。 -
--no-tags -
タグのクローンを作成せず、構成に
remote.<remote>.tagOpt=--no-tagsを設定して、今後のgitpullおよびgitfetch操作がタグに従わないようにします。 指定後も明示的なタグフェッチは引き続き機能します(git-fetch(1) 参照)。--single-branchと組み合わせて使用すると、単一のクローンされたブランチ以外の参照なしでブランチをクローンおよび維持できます。 検索インデックス作成のために、一部のリポジトリのデフォルトブランチの最小限のクローンを維持するので便利です。 -
--recurse-submodules[=<pathspec>] -
クローンが作成されたら、提供された <pathspec> に基づいてサブモジュールを初期化し、クローンを作成します。 <pathspec> が指定されていない場合、すべてのサブモジュールが初期化され、クローン化されます。 このオプションは、複数のエントリで構成されるパススペックに対して複数回指定できます。 結果として得られるクローンには
submodule.activeが指定され、 パススペック指定がない場合は . (すべてのサブモジュールを意味する)が設定されます。サブモジュールは、デフォルト設定を使用して初期化およびクローン化されます。 これは、クローンが終了した直後に
gitsubmoduleupdate--init--recursive<pathspec> を実行するのと同じです。 クローンされたリポジトリに ワークツリー/チェックアウト がない場合(つまり、--no-checkout/-nまたは--bareまたは--mirrorのいずれかが指定されている場合)、このオプションは無視されます。 -
--[no-]shallow-submodules -
クローンされるすべてのサブモジュールは、深さが1の浅さののになります。
-
--[no-]remote-submodules -
クローン化されるすべてのサブモジュールは、スーパープロジェクトの記録されたSHA-1ではなく、サブモジュールのリモート追跡ブランチのステータスを使用してサブモジュールを更新します。
--remoteをgitsubmoduleupdateに渡すのと同じです。 -
--separate-git-dir=<git-dir> -
クローンされたリポジトリを本来あるべき場所に配置する代わりに、クローンされたリポジトリを指定されたディレクトリに配置し、そこへのファイルシステムに依存しないGitシンボリックリンクを作成します。 その結果、Gitリポジトリを作業ツリーから分離できます。
-
--ref-format=<ref-format> -
リポジトリの ref ストレージ形式を指定します。有効な値は以下のとおりです:
-
filesは、 パックされた ref を持つ緩いファイル(loose files)用です。 これがデフォルトです。 -
reftableは reftable 形式です。 この形式は実験的なものであり、 その内部は変更される可能性があります。
-
- ‘-j <n>’
-
--jobs<n> -
同時にフェッチするサブモジュールの数。 デフォルトは
submodule.fetchJobsオプションです。 - <repository>
-
クローンを作成する(場合によってはリモートの)リポジトリ(<repository>)。 リポジトリの指定の詳細については、下記 GIT URLS セクションを参照してください。
- <directory>
-
クローンを作成する新しいディレクトリの名前。 <directory> が明示的に指定されていない場合は、ソースリポジトリの「人間味のある」(humanish)部分が使用されます(
/path/to/repo.gitの場合はrepo、host.xz:foo/.gitの場合はfoo)。 既存のディレクトリへのクローン作成は、ディレクトリが空の場合にのみ許可されます。 -
--bundle-uri=<uri> -
リモートからフェッチする前に、指定された <uri> からバンドルをフェッチし、データをローカル・リポジトリで非バンドル化(unbundle)します。 バンドル内のrefは、 非表示の
refs/bundle/* 名前空間に保存されます。 このオプションは、--depthや`--shallow-since` や--shallow-excludeと互換性がありません。
GIT URLS
一般に URLには、トランスポート・プロトコルや、リモート・サーバーのアドレスや、 リポジトリーへのパスに関する情報が含まれています。トランスポート・プロトコルによっては、一部の情報が欠落している場合があります。
Gitは、 ssh プロトコルと git プロトコルと http プロトコルと https プロトコルをサポートします(さらに ftp と ftps を fetch に使用できますが、 これらは非効率的で非推奨です。 使用しないでください)。
ネイティブ・トランスポート(つまり、 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>
代替scp風の構文を、 sshプロトコルで使用することもできます:
-
[<user>
@]<host>:/<path-to-git-repo>
この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカル・パスを区別するのに役立ちます。たとえば、ローカル・パス foo:bar を、絶対パスまたは ./foo:bar として指定して、 ssh url として誤って解釈されないようにすることができます。
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が特定のトランスポート・プロトコルを処理する方法を知らない場合、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
CONFIGURATION
このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は git-config(1) ドキュメント にあるものと同一です:
-
init.templateDir -
テンプレートのコピー元のディレクトリを指定します。 (See the "TEMPLATE DIRECTORY" section of git-init(1).)
-
init.defaultBranch -
デフォルトのブランチ名を上書きできます。例えば、新しいリポジトリを初期化するとき。
-
init.defaultObjectFormat -
新しいリポジトリのデフォルトのオブジェクト形式をオーバーライドできるようにします。 git-init(1) の
--object-format=を参照してください。 コマンド・ライン・オプションとGIT_DEFAULT_HASH環境変数の両方とも、 この設定より優先されます。 -
init.defaultRefFormat -
新しいリポジトリのデフォルトの ref ストレージ形式をオーバーライドできるようにします。 git-init(1) の
--ref-format=を参照してください。 コマンド・ライン・オプションとGIT_DEFAULT_REF_FORMAT環境変数の両方とも、 この設定より優先されます。 -
clone.defaultRemoteName -
リポジトリのクローンを作成するときに作成するリモートの名前。 デフォルトは
originです。 これは、--originコマンドライン・オプションを渡すことで オーバーライドできます。 -
clone.rejectShallow -
リポジトリが浅い(shallow)場合は、 複製(clone)を拒否します。 これは、 コマンドラインで
--reject-shallowオプションを渡すことでオーバーライドできます。 -
clone.filterSubmodules -
部分(partial)クローン・フィルタが提供され(git-rev-list(1) の
--filterを参照)、かつ、--recurse-submodulesが使用されている場合は、フィルタをサブモジュールにも適用します。
GIT
Part of the git(1) suite