Gitを使い始めると、ほぼ必ず登場するのが次の3つのコマンドです。
git add
git commit
git push一見すると、
「変更したファイルをGitHubへ送るためのコマンド」
に見えます。
しかし、3つはそれぞれまったく違う役割を持っています。
ファイルを変更
↓
git add
↓
git commit
↓
git push
↓
GitHubこの流れを理解すると、Gitの操作が単なるコマンド暗記ではなくなります。
この記事では、ファイルを編集してからGitHubへ反映されるまでを一つずつ確認します。
まず全体像を理解する
Gitでは、変更したファイルがいきなりGitHubへ送られるわけではありません。
大きく分けると、次の4つの場所があります。
作業フォルダ
↓
ステージング領域
↓
ローカルリポジトリ
↓
リモートリポジトリGitHubを使う場合、リモートリポジトリはGitHub上にあります。
それぞれの役割を整理すると次のようになります。
| 場所 | 役割 |
|---|---|
| 作業フォルダ | 実際にファイルを編集する |
| ステージング領域 | 次の記録に含める変更を選ぶ |
| ローカルリポジトリ | PC内に変更履歴を記録する |
| リモートリポジトリ | GitHubなどへ履歴を送る |
そして、各場所をつなぐのが、
git add
git commit
git pushです。
ファイルを編集しただけではGitに記録されない
まず通常どおりファイルを編集します。
たとえば、
test.pyというPythonファイルに、
print("Hello Git")と書いて保存したとします。
この時点では、ファイルそのものは変更されています。
しかし、まだGitの履歴には記録されていません。
現在の状態は、
作業フォルダ
↓
変更あり
Git履歴
↓
まだ変更なしです。
Gitでは、この「ファイルは変更したが、まだ記録していない」という状態を扱えます。
git statusで現在の状態を見る
Git操作をするときに非常に重要なのが、
git statusです。
実行すると、現在のリポジトリの状態を確認できます。
たとえば、
Changes not staged for commit:
modified: test.pyと表示された場合、
test.pyは変更されている
↓
まだcommit対象には選ばれていないという意味です。
Gitで迷ったときは、まず、
git statusを見る習慣をつけると現在位置を把握しやすくなります。
git addとは何か
変更したファイルを次のコミットに含めたい場合、
git addを使います。
たとえば、
git add test.pyと実行します。
これは、
「test.pyをGitHubへ送る」
という意味ではありません。
正確には、
test.pyの現在の変更を、次のコミットに含める対象として登録する
操作です。
流れで見ると、
作業フォルダ
test.py
↓
git add
↓
ステージング領域となります。
ステージング領域とは何か
Gitには「ステージング領域」という少し独特な仕組みがあります。
これは、
次のコミットに何を含めるかを一時的に選ぶ場所
です。
たとえば3つのファイルを変更したとします。
main.py
README.md
config.jsonこのうち、
main.py
README.mdだけを今回のコミットに含めたい場合、
git add main.py
git add README.mdとします。
すると、
今回のcommit
├─ main.py
└─ README.md
まだcommitしない
└─ config.jsonという分け方ができます。
これがステージング領域の大きな役割です。
git add . は便利だが意味を理解して使う
よく使われるコマンドに、
git add .があります。
.は現在のディレクトリを表します。
そのため、
git add .は、現在のフォルダ以下の変更をまとめてステージングする操作です。
非常に便利ですが、
必要な変更
+
関係ない変更
+
意図しないファイルまで含めてしまう可能性があります。
そのため、
git statusで状態を確認してから実行する習慣が重要です。
addした状態を確認する
git addしたあと、もう一度、
git statusを実行します。
今度は、
Changes to be committed:
modified: test.pyのように表示されます。
これは、
test.py
↓
次のcommitに含まれる予定という状態です。
ここでまだ履歴そのものは作成されていません。
git commitとは何か
ステージングした変更を履歴として記録するのが、
git commitです。
一般的には、メッセージを付けて実行します。
git commit -m "Add greeting message"これによって、
ステージング領域
↓
git commit
↓
ローカルリポジトリへ変更が記録されます。
ここで重要なのは、
commitはGitHubへの送信ではない
という点です。
commitした時点では、変更履歴は自分のPC内にあります。
commitは「保存」より「履歴の記録」に近い
ファイルの保存とcommitは別物です。
通常の保存は、
Ctrl + Sなどでファイルの内容をディスクへ保存します。
一方、commitは、
その時点の変更をGitの履歴として記録する
操作です。
たとえば、
commit A
初期ファイルを作成
commit B
入力処理を追加
commit C
入力チェックを追加というように、プロジェクトの変更履歴が積み重なっていきます。
Gitでは、この履歴を後から確認できます。
commitメッセージは変更内容が分かるようにする
commitには通常、メッセージを付けます。
たとえば、
git commit -m "Update file"でも動作します。
しかし後から見たとき、
何を変更したのかが分かりにくくなります。
できるだけ、
git commit -m "Add input validation"git commit -m "Fix cylinder calculation"git commit -m "Update README installation steps"のように、変更内容を表すメッセージにすると履歴を利用しやすくなります。
commitしただけではGitHubは変わらない
ここは特に混同しやすい部分です。
git commitを実行しても、GitHub上のリポジトリはまだ更新されません。
状態としては、
PC
ローカルリポジトリ
commit済み
↓
GitHub
まだ古い状態です。
ローカルに作成したコミットをGitHubへ送る操作が、
git pushです。
git pushとは何か
ローカルリポジトリのコミットをリモートリポジトリへ送るのが、
git pushです。
流れとしては、
ローカルリポジトリ
↓
git push
↓
GitHubとなります。
通常、一度リモートとの追跡関係が設定されていれば、
git pushだけで送信できます。
初回pushでは -u を使うことがある
新しいローカルブランチを初めてGitHubへ送るときは、
git push -u origin mainのように実行することがあります。
それぞれの意味は、
origin
= リモートリポジトリの名前
main
= 送信するローカルブランチです。
-uを指定すると、
ローカル main
↓
origin/mainという追跡関係が設定されます。
一度設定されれば、その後は、
git pushだけで済むことが多くなります。
add・commit・pushの違い
ここまでを整理すると、3つのコマンドの役割は明確です。
| コマンド | 役割 |
|---|---|
git add | 次のコミットに含める変更を選ぶ |
git commit | 選んだ変更をローカル履歴として記録する |
git push | ローカルのコミットをGitHubへ送る |
一行で表すと、
変更
↓
選ぶ
↓
記録する
↓
送るです。
コマンドに対応させると、
変更
↓
git add
↓
git commit
↓
git pushになります。
実際の基本フロー
ファイルを編集したあと、最も基本的な流れは次のようになります。
まず状態を確認します。
git status変更内容を確認します。
git diffコミットしたいファイルをステージングします。
git add test.py再び状態を確認します。
git status履歴として記録します。
git commit -m "Add greeting message"GitHubへ送ります。
git pushこれで、
編集
↓
確認
↓
add
↓
commit
↓
push
↓
GitHubという一連の流れが完了します。
git diffも一緒に使う
git statusは、
どのファイルが変更されたかを確認するのに向いています。
一方、
git diffを使うと、
ファイルの中身が具体的にどう変わったかを確認できます。
たとえば、
-print("Hello")
+print("Hello Git")のように差分が表示されます。
そのため、実際の作業では、
git status
git diffをセットで使うと変更内容を確認しやすくなります。
pushできたかGitHubで確認する
git pushが成功したら、GitHubの対象リポジトリを開きます。
確認するポイントは、
- 変更したファイルが反映されている
- 最新のcommitメッセージが表示されている
- 対象ブランチが正しい
ことです。
GitHub上に最新のコミットが表示されれば、
ローカル
↓
GitHubまで変更が届いたことを確認できます。
よくある勘違い
addするとGitHubへ送られる
送られません。
git addはステージング領域へ変更を登録するだけです。
commitするとGitHubへ反映される
まだ反映されません。
git commitはローカルリポジトリへ履歴を記録します。
GitHubへ反映するにはgit pushが必要です。
pushすれば未保存の変更まで送られる
送られません。
基本的にpushされるのは、ローカルリポジトリに存在するコミットです。
ファイル変更
↓
未commitの状態では、その変更はpush対象になりません。
git add . を毎回使えばよい
動作はしますが、不要なファイルまで含める可能性があります。
特に複数ファイルを編集している場合は、
git statusで確認してから実行する方が安全です。
操作に迷ったらgit statusを見る
Gitでは、
今どの状態なのか分からないということがよくあります。
そのときは、
git statusを実行します。
たとえば、
変更しただけなのか、
add済みなのか、
commitするものがないのかを確認できます。
Git操作では、
操作
↓
git status
↓
次の操作という使い方をすると状態を見失いにくくなります。
実習
Git管理されているテスト用リポジトリで、ファイルを1つ変更します。
例として、
test.txtを作り、
Git practiceと書いて保存します。
まず状態を確認します。
git status次にステージングします。
git add test.txt確認します。
git statusコミットします。
git commit -m "Add test file"GitHubへ送ります。
git push最後にGitHubを開き、
test.txtと、
Add test fileというコミットが反映されているか確認します。
まとめ
Gitで変更をGitHubへ反映するときの基本は、
作業フォルダ
↓
git add
↓
ステージング領域
↓
git commit
↓
ローカルリポジトリ
↓
git push
↓
GitHubです。
それぞれの意味は、
git add
= 変更を選ぶ
git commit
= 履歴として記録する
git push
= GitHubへ送ると考えると分かりやすくなります。
この3つの役割を区別できるようになると、Gitの基本操作はかなり理解しやすくなります。
コマンドを丸暗記するより、
変更が今どこにあるのか
を意識しながら操作することが、Gitを理解する近道です。
