【Git入門】git cloneの使い方！ソースコードをダウンロードしてみよう

最初にgit cloneコマンドの使い方の説明をしています。
その後に既存のリポジトリからソースコードを落としてみます。

Gitのインストールはこちらの記事に書いているので、確認してみてください。

git cloneの使い方
Githubのリポジトリからソースコードをダウンロードしてみよう
オプション一覧
終わりに
動画で確認する

git cloneの使い方

gitコマンドでcloneを使用することで、リポジトリをローカルのディレクトリにクローンしてくることが可能です。
リポジトリは、クラウドにソースコードが置いてあって、共有されているイメージになります。

git cloneをすることで、それぞれのパソコンからリポジトリにある内容をダウンロードしてくることが可能です。
gitのリポジトリにはソースコードだけでなく、テキストファイルや画像などを置くこともできます。

基本的な使い方

基本的には下記のように使います。
現在のディレクトリに指定したリポジトリの内容をダウンロードすることが可能です。

$ git clone [リポジトリを指定する]

cloneの後に、gitのリポジトリを指定します。
リポジトリはGithubやGitlabなどで作成することが可能です。
VPSなどを使用してリポジトリを用意することもできます。

クローンされると、リポジトリの名前でローカルにディレクトリができます。
そのディレクトリ配下にリポジトリの内容が入ります。

ディレクトリを指定する

ディレクトリを指定して、クローンすることも可能です。
ディレクトリを指定すると、指定したディレクトリ名でディレクトリが作成されて、その配下にリポジトリの内容がクローンされます。

$ git clone [リポジトリを指定する] [ディレクトリ名]

その他オプションの確認

-hオプションをつけて実行すると、他に使用できるオプションなどを確認することができます。

$ git clone -h

実行すると、下記のように基本的な構文とオプションが確認できます。

$ git clone -h
usage: git clone [<options>] [--] <repo> [<dir>]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
    --progress            force progress reporting
    --reject-shallow      don't clone shallow repository
    -n, --no-checkout     don't create a checkout
    --bare                create a bare repository
    --mirror              create a mirror repository (implies bare)
    -l, --local           to clone from a local repository
    --no-hardlinks        don't use local hardlinks, always co
# --- 省略 ---

Githubのリポジトリからソースコードをダウンロードしてみよう

実際にGithubのリポジトリから、ソースコードをダウンロードしてみます。
今回は下記のリポジトリを使ってみます。
https://github.com/gabrielecirulli/2048

こちらのリポジトリはHTMLとJavaScriptで2048というゲームを作成しているものです。

codeの箇所をクリックすると、下記のようなツールチップが表示されるので、リポジトリのURLをコピーします。

コピーしたURLを使用して、ターミナルやコマンドプロンプトから下記のようにgit cloneを実行します。

$ git clone https://github.com/gabrielecirulli/2048.git

そうすると、下記のようにリポジトリがクローンされて、ローカルにリポジトリ名の2048のディレクトリが作成されます。

$ git clone https://github.com/gabrielecirulli/2048.git
Cloning into '2048'...
remote: Enumerating objects: 1315, done.
remote: Total 1315 (delta 0), reused 0 (delta 0), pack-reused 1315
Receiving objects: 100% (1315/1315), 612.22 KiB | 2.44 MiB/s, done.
Resolving deltas: 100% (775/775), done.

ダウンロードしたディレクトリにcdコマンドで移動します。

$ cd 2048

lsコマンドを使用して、ダウンロードされたファイルを確認すると、下記のようにファイルが落ちてきていることが確認できます。

$ ls -ls
total 56
 8 -rw-r--r--   1 yasuaki  staff  1970  4 10 11:18 CONTRIBUTING.md
 8 -rw-r--r--   1 yasuaki  staff  1083  4 10 11:18 LICENSE.txt
 8 -rw-r--r--   1 yasuaki  staff  2280  4 10 11:18 README.md
 8 -rw-r--r--   1 yasuaki  staff   300  4 10 11:18 Rakefile
16 -rw-r--r--   1 yasuaki  staff  4286  4 10 11:18 favicon.ico
 8 -rw-r--r--   1 yasuaki  staff  3988  4 10 11:18 index.html
 0 drwxr-xr-x  12 yasuaki  staff   384  4 10 11:18 js
 0 drwxr-xr-x   5 yasuaki  staff   160  4 10 11:18 meta
 0 drwxr-xr-x   6 yasuaki  staff   192  4 10 11:18 style

ちなみに、このファイルのindex.htmlをクリックしてブラウザで開くと、下記のように遊ぶことが可能です。

オプション一覧

自動翻訳したオプション一覧です。

オプション	説明
`-l`, `--local`	クローン元リポジトリがローカルマシン上にある場合、通常の “Git 認識” トランスポート機構をバイパスし、HEAD のコピーと objects および refs ディレクトリ以下のすべてを作成してリポジトリをクローンします。可能な場合は、`.git/objects/` ディレクトリ以下のファイルは、スペースを節約するためにハードリンクされます。リポジトリがローカルパス（例：`/path/to/repo`）として指定されている場合、これがデフォルトであり、`--local` は事実上何もしません。リポジトリが URL として指定されている場合、このフラグは無視されます（ローカル最適化は使用されません）。`/path/to/repo` が指定されている場合、`--no-local` を指定するとデフォルトが上書きされ、代わりに通常の Git トランスポートが使用されます。リポジトリの `$GIT_DIR/objects` にシンボリックリンクがある場合、またはシンボリックリンクである場合、クローンは失敗します。これは、シンボリックリンクを間接参照することによるファイルの意図しないコピーを防ぐためのセキュリティ対策です。このオプションは、セキュリティ上の理由から、他のユーザーが所有するリポジトリでは機能せず、クローンを成功させるには `--no-local` を指定する必要があります。注意：この操作は、`<src>` を変更しながら `cp -r <src> <dst>` を実行するのと同様に、ソースリポジトリの同時変更と競合する可能性があります。
`--no-hardlinks`	ローカルファイルシステム上のリポジトリからのクローンプロセスで、ハードリンクを使用する代わりに、`.git/objects` ディレクトリ以下のファイルをコピーするように強制します。これは、リポジトリのバックアップを作成しようとしている場合に望ましい場合があります。
`-s`, `--shared`	クローン元リポジトリがローカルマシン上にある場合、ハードリンクを使用する代わりに、自動的に `.git/objects/info/alternates` を設定して、オブジェクトをソースリポジトリと共有します。結果のリポジトリは、独自のオブジェクトを持たない状態で開始します。注意：これは危険な可能性がある操作です。何をするのかを理解していない限り、使用しないでください。このオプションを使用してリポジトリをクローンし、ソースリポジトリでブランチを削除する（または既存のコミットを参照解除する他の Git コマンドを使用する）と、一部のオブジェクトが参照解除される（または宙ぶらりんになる）可能性があります。これらのオブジェクトは、`git commit` などの通常の Git 操作によって削除される可能性があり、自動的に `git maintenance run --auto` を呼び出します。(git-maintenance[1] を参照)。これらのオブジェクトが削除され、クローンされたリポジトリによって参照されていた場合、クローンされたリポジトリは破損します。`--shared` でクローンされたリポジトリで `--local` オプションなしで `git repack` を実行すると、ソースリポジトリからクローンされたリポジトリのパックにオブジェクトがコピーされ、`clone --shared` のディスクスペースの節約がなくなります。ただし、デフォルトで `--local` オプションを使用する `git gc` を実行するのは安全です。`--shared` でクローンされたリポジトリのソースリポジトリへの依存関係を解消したい場合は、`git repack -a` を実行して、ソースリポジトリからクローンされたリポジトリのパックにすべてのオブジェクトをコピーするだけです。
`--reference[-if-able] <repository>`	参照 `<repository>` がローカルマシン上にある場合、自動的に `.git/objects/info/alternates` を設定して、参照 `<repository>` からオブジェクトを取得します。既存のリポジトリを代替として使用すると、クローンされるリポジトリからコピーされるオブジェクトが少なくなり、ネットワークとローカルストレージのコストが削減されます。`--reference-if-able` を使用する場合、存在しないディレクトリは、クローンを中断する代わりに警告とともにスキップされます。注意：`--shared` オプションの注意と、`--dissociate` オプションも参照してください。
`--dissociate`	ネットワーク転送を削減するためだけに `--reference` オプションで指定された参照リポジトリからオブジェクトを借用し、必要な借用オブジェクトのローカルコピーを作成して、クローン作成後にそれらからの借用を停止します。このオプションは、すでに別のリポジトリからオブジェクトを借用しているリポジトリからローカルにクローンする場合にも使用できます—新しいリポジトリは同じリポジトリからオブジェクトを借用し、このオプションを使用して借用を停止できます。
`-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`	ベアリポジトリを作成します。つまり、`<directory>` を作成し、管理ファイルを `<directory>/.git` に配置する代わりに、`<directory>` 自体を `$GIT_DIR` にします。これは明らかに `--no-checkout` を意味します。作業ツリーをチェックアウトする場所がないためです。また、リモートのブランチヘッドは、`refs/remotes/origin/` にマッピングせずに、対応するローカルブランチヘッドに直接コピーされます。このオプションを使用すると、リモート追跡ブランチも関連する構成変数も作成されません。
`--sparse`	スパースチェックアウトを使用し、最初は最上位ディレクトリのファイルのみが存在します。`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` はソースのローカルブランチをターゲットのローカルブランチにマッピングするだけでなく、すべての ref (リモート追跡ブランチ、ノートなどを含む) をマッピングし、これらのすべての ref がターゲットリポジトリの `git remote update` によって上書きされるような 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] の「テンプレートディレクトリ」セクションを参照してください。)
`-c <key>=<value>`, `--config <key>=<value>`	新しく作成されたリポジトリに構成変数を設定します。これは、リポジトリが初期化された直後、リモート履歴がフェッチされる前、またはファイルがチェックアウトされる前に有効になります。`<key>` は、`git-config(1)` で想定されているのと同じ形式です (例: `core.eol=true`)。同じキーに複数の値が指定されている場合、各値が構成ファイルに書き込まれます。これにより、たとえば、`origin` リモートに追加の fetch refspec を追加するのが安全になります。現在の実装の制限により、一部の構成変数は、最初のフェッチとチェックアウトが完了するまで有効になりません。有効にならないことがわかっている構成変数は、`remote.<name>.mirror` と `remote.<name>.tagOpt` です。代わりに、対応する `--mirror` および `--no-tags` オプションを使用してください。
`--depth <depth>`	指定されたコミット数に履歴を切り詰めた shallow クローンを作成します。すべてのブランチの先端付近の履歴をフェッチするために `--no-single-branch` が指定されていない限り、`--single-branch` を暗黙的に指定します。サブモジュールを shallow にクローンする場合は、`--shallow-submodules` も渡します。
`--shallow-since=<date>`	指定された時刻以降の履歴を持つ shallow クローンを作成します。
`--shallow-exclude=<revision>`	指定されたリモートブランチまたはタグから到達可能なコミットを除外して、履歴を持つ shallow クローンを作成します。このオプションは複数回指定できます。
`--[no-]single-branch`	`--branch` オプションで指定されたブランチ、またはプライマリブランチのリモートの HEAD が指すブランチの先端につながる履歴のみをクローンします。結果のリポジトリへのそれ以降のフェッチでは、このオプションが最初のクローンに使用されたブランチのリモート追跡ブランチのみが更新されます。`--single-branch` クローンが作成されたときに、リモートの HEAD がどのブランチも指していなかった場合、リモート追跡ブランチは作成されません。
`--depth <depth>`	指定されたコミット数に履歴を切り詰めた shallow クローンを作成します。すべてのブランチの先端付近の履歴をフェッチするために `--no-single-branch` が指定されていない限り、`--single-branch` を暗黙的に指定します。サブモジュールを shallow にクローンする場合は、`--shallow-submodules` も渡します。
`--shallow-since=<date>`	指定された時刻以降の履歴を持つ shallow クローンを作成します。
`--shallow-exclude=<ref>`	指定されたリモートブランチまたはタグから到達可能なコミットを除外して、履歴を持つ shallow クローンを作成します。このオプションは複数回指定できます。
`--[no-]single-branch`	`--branch` オプションで指定されたブランチ、またはプライマリブランチのリモートの HEAD が指すブランチの先端につながる履歴のみをクローンします。結果のリポジトリへのそれ以降のフェッチでは、このオプションが最初のクローンに使用されたブランチのリモート追跡ブランチのみが更新されます。`--single-branch` クローンが作成されたときに、リモートの HEAD がどのブランチも指していなかった場合、リモート追跡ブランチは作成されません。
`--no-tags`	タグをクローンせず、`remote.<remote>.tagOpt=--no-tags` を config に設定して、将来の `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>` を実行するのと同じです。このオプションは、クローンされたリポジトリに作業ツリー/チェックアウトがない場合 (つまり、`--no-checkout/-n`、`--bare`、または `--mirror` のいずれかが指定されている場合) は無視されます。
`--[no-]shallow-submodules`	クローンされるすべてのサブモジュールは、深さ 1 の shallow になります。
`--[no-]remote-submodules`	クローンされるすべてのサブモジュールは、スーパープロジェクトの記録された SHA-1 ではなく、サブモジュールのリモート追跡ブランチの状態を使用してサブモジュールを更新します。`git submodule update` に `--remote` を渡すのと同じです。
`--separate-git-dir=<git-dir>`	クローンされたリポジトリを本来あるべき場所に配置する代わりに、指定されたディレクトリにクローンされたリポジトリを配置し、そこにファイルシステムに依存しない Git シンボリックリンクを作成します。その結果、Git リポジトリを作業ツリーから分離できます。
`--ref-format=<ref-format>`	リポジトリに指定された ref ストレージ形式を指定します。有効な値は次のとおりです。`files`: packed-refs を持つルーズファイル用。これがデフォルトです。`reftable`: reftable 形式用。この形式は実験的であり、その内部は変更される可能性があります。
`-j <n>`, `--jobs <n>`	同時にフェッチされるサブモジュールの数。デフォルトは `submodule.fetchJobs` オプションです。
`<repository>`	クローン元の (場合によってはリモートの) `<repository>`。リポジトリの指定の詳細については、下記の「GIT URLS」セクションを参照してください。
`<directory>`	クローン先の新しいディレクトリの名前。`<directory>` が明示的に指定されていない場合は、ソースリポジトリの「人間的な」部分が使用されます (`/path/to/repo.git` の場合は `repo`、`host.xz:foo/.git` の場合は `foo`)。既存のディレクトリへのクローンは、ディレクトリが空の場合にのみ許可されます。
`--bundle-uri=<uri>`	リモートからフェッチする前に、指定された `<uri>` からバンドルをフェッチし、データをローカルリポジトリに展開します。バンドル内の ref は、非表示の `refs/bundle/*` 名前空間に格納されます。このオプションは、`--depth`、`--shallow-since`、および `--shallow-exclude` と互換性がありません。