Git
日本語 ▾ Topics ▾ Latest version ▾ git-clone last updated in 2.43.0

NAME

git-clone - リポジトリを新しいディレクトリにクローンする

概要

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> [--also-filter-submodules]] [--] <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トランスポートを使用します。

If the repository’s $GIT_DIR/objects has symbolic links or is a symbolic link, the clone will fail. This is a security measure to prevent the unintentional copying of files by dereferencing the symbolic links.

注意: この操作は、ソースリポジトリの同時変更と競合する可能性があります。 この操作は、ソースリポジトリの同時変更と競合する可能性があります。これは、 src を変更しながら cp -r src dst を実行するのと同じです。 src を変更しながら cp -r src dst を実行するのと同じように、この操作はソースリポジトリの同時変更と競合する可能性があります。

--no-hardlinks

ローカルファイルシステム上のリポジトリからクローン作成プロセスを強制して、ハードリンクを使用するのではなく .git/objects ディレクトリの下にファイルをコピーします。これは、リポジトリのバックアップを作成する場合に適しています。

-s
--shared

クローンを作成するリポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、オブジェクトをソースリポジトリと共有するように .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] <リポジトリ>

参照リポジトリがローカルマシン上にある場合は、参照リポジトリからオブジェクトを取得するように .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 を採用し、最初にトップレベル・ディレクトリのファイルのみが存在するようにします。git-sparse-checkout[1] コマンドを使うと、必要に応じて作業ディレクトリを増やすことができます。

--filter=<filter-spec>

パーシャルクローン機能を使って、与えられたオブジェクト・フィルタにしたがって、到達可能なオブジェクトのサブセットを送るようにサーバに要求します。 --filter を使う場合、パーシャルクローンのフィルタには、与えられた <filter-spec> が使われます。たとえば、 --filter=blob:none とすると、Gitが必要とするまで、すべてのblob（ファイルの内容）をフィルタリングします。また、 --filter=blob:limit=<size> とすると、少なくとも <size> 以上のサイズのblobをすべてフィルタリングします。フィルターの仕様についての詳細は、 git-rev-list[1] の --filter オプションを参照してください。

--also-filter-submodules

また、リポジトリ内の任意のサブモジュールにパーシャルクローンフィルタを適用します。 --filter と --recurse-submodules が必要です。これは、 clone.filterSubmodules 設定オプションで、デフォルトで有効にすることができます。

--mirror

ソースリポジトリのミラーを設定します。これは --bare を意味します。 --bare と比較して、 ` --mirror` は、ソースのローカルブランチをターゲットのローカルブランチにマップするだけでなく、すべての参照（リモートトラッキングブランチ、メモなどを含む）をマップし、ターゲットリポジトリの git remote update によってこれらのrefがすべて上書きされるようにrefspecの設定を行います。

-o <名前>
--origin <名前>

上流のリポジトリを追跡するためにリモート名 origin を使用する代わりに、 <名前> を使用します。 コンフィグの clone.defaultRemoteName をオーバーライドします。

-b <名前>
--branch <名前>

新しく作成された HEAD を、クローンされたリポジトリの HEAD が指すブランチに向けるのではなく、代わりに <名前> ブランチを指します。ベアリポジトリでない場合は、このブランチがチェックアウトされます。 また、--branch はタグを取ることができ、できあがったリポジトリのそのコミットの HEAD をデタッチします。

-u <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.<名前>.mirror と remote.<名前>.tagOpt です。 代わりに、対応する --mirror と --no-tags オプションを使用してください。

--depth <depth>

指定された数のコミットに切り詰められたヒストリーを持つ、「浅い」クローンを作成します。 --no-single-branch が指定されていない限り、--single-branch を意味し、すべてのブランチの先端付近の履歴を取得します。サブモジュールを浅くクローンしたい場合には、--shallow-submodules も指定してください。

--shallow-since=<日付>

指定した日時以降の履歴を持つシャロークローンを作成します。

--shallow-exclude=<リビジョン>

指定したリモートブランチやタグから到達可能なコミットを除いた、履歴付きのシャロークローンを作成します。 このオプションは複数回指定できます。

--[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 となります）。 既存のディレクトリへのクローン作成は、そのディレクトリが空の場合のみ可能です。

--bundle-uri=<uri>

Before fetching from the remote, fetch a bundle from the given <uri> and unbundle the data into the local repository. The refs in the bundle will be stored under the hidden refs/bundle/* namespace. This option is incompatible with --depth, --shallow-since, and --shallow-exclude.

GIT URLS

一般的に、URLにはトランスポートプロトコル、リモートサーバーのアドレス、リポジトリへのパスなどの情報が含まれています。 トランスポートプロトコルによっては、これらの情報の一部が含まれていない場合があります。

Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).

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

CONFIGURATION

Warning

Missing ja/includes/cmd-config-section-all.txt

See original version for this content.
Warning

Missing ja/config/init.txt

See original version for this content.
Warning

Missing ja/config/clone.txt

See original version for this content.

GIT

Part of the git[1] suite

scroll-to-top