Git

【Git】ローカルリポジトリ チートシート

環境・事前準備

・macOS Ventura
GitHubの登録
・Gitのインストール
Homebrew:brew install git

gitによる開発の一般的なフローは次のようなイメージです。

本ページでは、ローカルリポジトリでの処理についてまとめていきます。

ローカルリポジトリの作成

  • % git init  <project-name>:カレントディレクトリにリポジトリを作成する。<project-name>フォルダが作成され、「.git」ファイルが生成される。
  • % git init:カレントディレクトリをリポジトリにする。カレントディレクトリに「.git」ファイルが生成される。

リモートリポジトリからローカルリポジトリの作成

  • % git clone <remote_repository_url>:リモートリポジトリからカレントディレクトリ内にローカルリポジトリを作成する。<remote_repository_url>はGitHubから取得(リポジトリのページにある緑色の<>Code」ボタンから取得可能)。デフォルトで「origin」というレファレンス名が<remote_repository_url>に振られる。
  • % git remote -v:ローカルリポジトリに紐づいているリモートリポジトリのレファレンス名とURLを表示する。
  • % git remote add <reference_name> <remote_repository_url>:リモートリポジトリ(<remote_repository_url>)にレファレンス名(<reference_name>)を割り振る。通常、fork元(もともとあるリモートリポジトリを自身のリモートリポジトリにコピーすることを「fork」という)のリポジトリにレファレンス名「upstream」をセットするときに使用する。※forkについては、「【Git】リモートリポジトリ チートシート」の項目「リポジトリの作成」を参照。

ブランチの管理

  • % git branch <branch-name>:ブランチを切る(複数の機能を平行で開発する場合等に、別の状態に切り分けること。主流のブランチはmainブランチまたは「masterブランチ」という。)。<branch-name>は、「-」で単語を区切るのがネーミング規則。※branchの実態はコミットへのポインタ。
  • % git branch:ブランチの一覧を表示する。「アクティブブランチ」(作業中のブランチ。「HEAD」というポインタで示される。)には「*」が付いている。「-a」オプションでリモートリポジトリを含む全てのブランチを表示する。
  • % git checkout <branch-name>:アクティブブランチを切り替える。「-b」オプションを付けることで、ブランチを切った上で、さらに切り替えることが可能。
  • % git branch -d <branch-name>:ブランチを削除する。mainブランチにマージしていないブランチは削除できない(強制的に削除する場合は、「-D」オプションを使用する)。
  • % git branch -m <branch-name1> <branch-name2>:ブランチ名を(<branch-name1>から<branch-name2>に)変更する。

ファイルの更新

  • % git ls-files:gitが「track」しているファイル(変更されたり、gitコマンドによってgitの管理下に置かれたファイル。新しいファイルは「untrack」ファイルとなる。)の一覧を表示する。
  • % git status「Working directory」(作業中のファイルや「untrack」ファイルが管理されているディレクトリ)と「Staging area」(Working directoryの変更内容をまとめたエリア)の変更内容を確認する。
  • % git add <file_name>:<file_name>の作業内容をStaging areaに追加する。<file_name>の代わりに「.」を指定すると、カレントディレクトリ配下の全てのファイル及びフォルダをStaging areaに追加する。※Working directoryからStaging areaに追加してもファイルの保存場所が変わるわけではない。あくまでも作業状況がどの段階にあるかを示している。
  • % git restore <file_name>:Working directoryでの作業をキャンセルする。内部的には、Working directoryの内容をStaging areaで上書きしている。
  • % git restore --staged <file_name>:Staging areaにaddした作業をキャンセルする(「unstage」)。内部的には、Staging areaの内容をリポジトリ(ここではmainブランチの最新の状態)で上書きし、Working directoryに移動している。
  • % git mv <file_name_1> <file_name_2>:ファイル名を(<file_name_1>から<file_name_2>に)変更しGitで管理する(変更内容はStaging areaに追加される)。※mvコマンドの場合、<file_name_1>は削除(deletedの履歴がWorking directoryに追加される)され、<file_name_2>がuntrackの状態で新規作成される。この変更は「% git add -A」(「-A」は、リポジトリ内の全てのファイル及びフォルダを対象とする。)コマンドでStaging areaに追加することができる(これにより「git mv」と同様の結果となる)。
  • % git rm <file_name>:ファイルを削除しGitで管理する(削除の履歴はStaging areaに追加される)。のファイルやStaging areaにあるファイルは削除できない。

rmコマンドの挙動

ファイルを新規作成(untrack)し、Staging areaにaddした後、rmコマンドでファイルを削除すると、Staging areaにはnew file(ファイルの作成)の履歴が残り、Working directoryにdeleted(ファイルの削除)の履歴が追加される。

このWorking directoryの内容をaddすると、deletedの履歴がStaging areaに追加されるが、new fileの履歴と相殺されることで、Staging areaの内容が消える。

git rmコマンドの挙動

ファイルを新規作成(untrack)し、(Staging areaに追加して)commitした後にgit rmコマンドでファイルを削除すると、Staging areaにdeletedの履歴が追加される。※リポジトリにはcommitの内容(make new file)が残っている。

さらにStaging areaの内容をunstageすると、Working directoryにdeletedの履歴が追加される(ファイルが戻っているわけではない)。

ここで、「git restore」コマンドでWorking directoryの内容をキャンセルすると、deletedの履歴が削除され(ファイルの削除がキャンセルされる)、git rmコマンドで削除したファイルが元に戻る。

このように、Git上で管理しておくことで誤ってファイルを削除しても元に戻すことができる。

ファイルのコミット

  • % git commit -m "<commit_message>":Staging areaの内容を「コミット」(リポジトリに保存)する。コミット時には必ずコミットメッセージ(1文で変更内容を記述。「-m」オプションでメッセージを付けることが可能)を付ける。コミット後は「コミットポイント」(コミットした時点)が作られる。
  • % git log:アクティブブランチのコミット履歴一覧を表示する。Qキーで抜けることができる。「--oneline」オプションで各コミット履歴を一行で表示、「--graph」オプションで各コミットの関係を線で結ぶ、「-- <file_name>」オプションで特定のファイルの情報を表示、「--follow <file_name>」オプションで当該ファイルのファイル名変更前の情報も一緒に表示、「--all」オプションで他のブランチのコミット履歴も表示できる。
  • % git show <commit_ID>:特定のコミットの情報を表示する。

リモートリポジトリとの同期

  • % git pull <remote_ref> <remote_branch>:リモートリポジトリの更新をローカルリポジトリ(アクティブブランチ)に反映する(「fetch+merge」)。<remote_ref>には、「% git remote -v」で表示されたリファレンス名を指定する(通常、「origin」)。<remote_branch>には、リモートリポジトリのブランチ名を指定する(通常、「main」)。

pull時に「Merge conflict」が発生した場合は、「% git merge <branch-name>での説明と同様の対応(ファイルを直接修正後、当該ファイルをコミットし直す)が必要となります。

  • % git fetch <remote_ref>:リモートリポジトリから情報を取得する。<remote_ref>には、「% git remote -v」で表示されたリファレンス名を指定する(省略時はデフォルトの「origin」が指定される)。取得した情報はローカルリポジトリの「.git/refs/remotes/<remote_ref>/<branch-name>」に更新される。
  • % git push <remote_ref> <local_branch>:ローカルリポジトリの更新をリモートリポジトリに反映する。<remote_ref>には、「% git remote -v」で表示されたリファレンス名を指定する(通常、「origin」)。<local_branch>には、ローカルのブランチ名を指定する(リモートリポジトリに同名のブランチとしてpushされる。なお、通常はcheckoutしてからpushするのが一般的なため、アクティブブランチを指定する。)

ローカルリポジトリでのマージ

  • % git merge <branch-name>:指定したブランチをアクティブブランチにマージする。「Automatic merge」の場合は、アクティブブランチと指定したブランチの両方を親とした子のコミットポイント(「マージコミット」)が作成される。「Merge conflict」が発生した場合は、「Merging area」に移行されるため、ファイルを直接修正した後、Staging areaに移行し、コミットし直す必要がある(「マージコミット」が作成される)。

diffの確認

  • % git diffWorking directoryとStaging area(なにもなければ「HEAD」)のdiffを表示する。「--<file_name>」オプションを付けることで特定のファイルのみのdiffを表示することができる。
  • % git diff HEADWorking directoryとアクティブブランチの最新のコミット(「HEAD」)のdiffを表示する。※「HEAD」部分を特定のコミットやブランチを指定することも可能。

「HEAD」はアクティブブランチの最新のコミットポイントを示すポインタ。

  • % git diff --staged HEADStaging areaとアクティブブランチの最新のコミット(「HEAD」)のdiffを表示する。※「HEAD」部分を特定のコミットやブランチを指定することも可能。
  • % git diff <base-commit_ID> <compare-commit_ID>コミット同士のdiffを表示する(<base-commit_ID>をベースに<compare-commit_ID>との差分を表示)。※最新のコミットの場合は「HEAD」を指定すれば良い。なお、「HEAD」の親コミットは「HEAD^」さらに親コミットは「HEAD^^」で指定が可能。親コミットが複数ある場合は、「HEAD^1」、「HEAD^2」というように番号を割り振る。
  • % git diff <base-branch> <compare-branch>ブランチ同士のdiffを表示する(<base-branch>をベースに<compare-branch>との差分を表示)。

Gitの管理から外す

「~/<project-name>/.gitignore」ファイルに指定することで、Gitで管理しないファイル等を定義することができます。

ファイル名やフォルダ名(末尾に「/」を付ける)をそのまま指定すれば定義することができます。

なお、「.gitignore」ファイル自体はGitで管理するファイルとなるので、コミットする必要があります。

GitHub社が「.gitignore」ファイルのリポジトリを提供しているので、適宜参照して下さい。