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-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)になる)可能性があります。 そうしたオブジェクトは、 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>)がローカルマシン上にある場合は、参照リポジトリ(<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などを含む)をマッピングし、 ターゲット・リポジトリ内の git remote update でこれらの 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 を設定して、今後の git pull および git fetch 操作がタグに従わないようにします。 指定後も明示的なタグフェッチは引き続き機能します(git-fetch(1) 参照)。

--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ではなく、サブモジュールのリモート追跡ブランチのステータスを使用してサブモジュールを更新します。 --remote を git submodule update に渡すのと同じです。

--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をフェッチに使用できますが、これらは非効率的で非推奨です。 使用しないでください)。

ネイティブ・トランスポート(つまり、 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