READMEの説明を直し、記事の原稿にも手を入れた。そんなとき、変更したファイルをすべて一度に履歴へ残すべきでしょうか。それとも、説明の修正だけを先に記録したほうがよいでしょうか。
Gitでは、次の記録に含める変更を選ぶ操作をステージング、選んだ内容を履歴に残す操作をコミットと呼びます。この2段階を理解すると、作業途中の変更と、ひとまとまりの記録を分けて扱えるようになります。
この記事では、READMEと記事原稿を編集する例で、ステージングとコミットの関係を説明します。登場するファイルや作業内容は説明用の例です。
1. ファイルの保存と、Gitへの記録は別の操作
文章を書いて保存すると、パソコン上のファイルは新しい内容になります。ただし、その保存だけでGitの履歴に新しい記録が追加されるわけではありません。
Gitで変更を記録するときは、基本的に次の流れで進めます。
- ファイルを編集し、保存する。
- 次のコミットに含める変更をステージングする。
- 選んだ内容を確認し、コミットする。
Gitの公式解説でも、編集したファイルの変更を選んでステージングし、その内容をコミットする流れが説明されています。Git公式：変更をリポジトリに記録する
たとえば、原稿の保存は「机の上で書き直すこと」、ステージングは「今回記録したい版を確認用のトレーにそろえること」、コミットは「その内容を説明付きで記録台帳に残すこと」と考えると、役割をつかみやすくなります。このたとえでファイルが実際に別のフォルダへ移動するわけではありません。
2. Gitでは、3つの場所を分けて考える
ステージングとコミットを理解するには、次の3つを区別します。
| 場所 | 何を扱うか | 自分が行うこと |
|---|---|---|
| 作業ツリー | 現在、手元で編集しているファイル | 文章やコードを編集・保存する |
| ステージングエリア | 次のコミットに使う内容 | 今回記録する変更を選ぶ |
| ローカルリポジトリの履歴 | コミットとして記録された状態 | 過去の記録を確認する |
作業ツリーは「今の作業内容」、ステージングエリアは「次に記録する内容」、履歴は「すでに記録した内容」です。ステージングエリアは、インデックスとも呼ばれます。Git公式：git add
作業ツリーの最新状態と、次にコミットする内容は、必ずしも同じではありません。 作業中の修正を手元に残しつつ、完成した部分だけを記録できます。
- ファイルを編集・保存する手元のファイルを更新する ↓
- 作業ツリー：今の作業内容git add：次に記録する変更を選ぶ ↓
- ステージングエリア（インデックス）：次に記録する内容git commit：選んだ状態を説明付きで記録する ↓
- ローカルリポジトリの履歴：コミットとして記録された状態push：手元のコミットを共有先へ送る ↓
- 共有先（GitHubなど）
3. ステージングは、今回記録する変更を選ぶこと
ステージングの基本操作はgit addです。指定したファイルの内容をインデックスに反映し、次のコミットで使う状態を用意します。新しいファイルだけでなく、既存ファイルの修正も対象になります。Git公式：git add
たとえば、次の2つを編集したとします。
README.md：使い始める手順の説明を修正した。articles/draft.md：記事の導入文を試しに書き換えたが、まだ検討中。
この場合、READMEの修正だけを先に記録したいなら、README.mdだけをステージングします。原稿の修正は手元に残して、次の作業へ続けられます。
git add README.mdステージングを挟む目的は、「何を一つの記録にするか」を自分で決めることです。ファイルを変更した順番に関係なく、同じ目的の変更をまとめられます。
同じファイル内の一部だけを選ぶ方法もあります。git add -pでは、変更のまとまりを確認しながらステージングできます。初めはファイル単位で選ぶ方法を覚え、必要になってから部分的な選択へ進むと理解しやすくなります。Git公式：git addのパッチ選択
4. コミットは、選んだ状態を説明付きで履歴に残すこと
基本形のgit commitは、インデックスに用意した内容から新しいコミットを作ります。変更を記録する際には、何をしたかを伝えるコミットメッセージを付けます。Git公式：git commit
git commit -m "READMEに記事作成の開始手順を追記"-mの後ろの文字列が、コミットメッセージです。「修正した」だけよりも、「どこに何を加えたか」がわかる文にすると、あとから履歴を読みやすくなります。
コミットは、変更ファイルの寄せ集めではない
コミットは、記録時点のプロジェクトの状態を表すスナップショットとして考えます。今回変更したファイルだけでなく、変更していない追跡対象ファイルの状態も含め、プロジェクトの状態を表します。ステージングでは、その次の状態に反映する変更を選んでいます。Git公式：変更をリポジトリに記録する
たとえば「READMEの手順を直す」という変更を記録すれば、その目的に対応する区切りができます。次に記事の導入文を完成させたときは、別の目的としてコミットできます。
コミットしても、GitHubへ自動的に送られるわけではありません。 コミットはまず手元の履歴に作られ、共有先へ送るにはpushという別の操作が必要です。Git公式：リモートでの作業
5. READMEの修正を記録する基本手順
以下は、Gitがインストールされ、既存のローカルリポジトリがあり、コミットに使う名前とメールアドレスの設定が済んでいる場合の例です。そのリポジトリのフォルダで操作します。
手順1：変更したファイルを確認する
READMEを編集・保存したら、まず状態を確認します。
git statusgit statusは、コミット予定の変更、まだステージングしていない変更、未追跡のファイルなどを示します。Git公式：git status
| 表示される見出し | 意味 |
|---|---|
| Changes to be committed | 次のコミットに含まれる変更 |
| Changes not staged for commit | 追跡対象ファイルにある、まだステージングしていない変更 |
| Untracked files | まだGitの追跡対象になっていないファイル |
表示が英語でも、「コミット予定か」「未選択か」「新しいファイルか」を見分けられれば、次の操作を判断できます。
手順2：修正の中身を確認する
git diffこの基本形では、作業ツリーとインデックスの差を確認できます。新しく作った未追跡ファイルの内容は、この表示だけでは確認できないため、ファイル自体も開いて読みます。Git公式：git diff
手順3：READMEをステージングする
git add README.mdほかの作業が混ざっている場合にも、まずは対象ファイルを明示すると、今回の記録の範囲を意識できます。
手順4：今回コミットする内容を確認する
git diff --cached
git statusgit diff --cachedでは、インデックスと直前のコミットの差を確認します。--stagedも同じ意味で使えます。git diffと見比べると、未選択の変更と、今回記録する変更を分けて確認できます。Git公式：git diff
手順5：メッセージを付けてコミットする
git commit -m "READMEに記事作成の開始手順を追記"
git status最後に状態を確認します。検討中のarticles/draft.mdをステージングしていなければ、その修正はコミット後も手元に残ります。コミットが成功したからといって、未記録の作業がすべてなくなるわけではありません。
→git status：変更したファイルを確認
→git diff：未ステージングの差分を確認
→git add README.md：READMEだけを選択
→git diff –cached と git status：今回の記録内容を確認
→メッセージを付けてコミット
→git status：コミット後の状態を確認
→記事原稿の修正は手元に残り、今回のコミットには入らない
→記事原稿の修正は手元に残り、今回のコミットには入らない
6. ステージング後に編集すると、どうなるか
ここは、最初に混乱しやすいところです。git addで選ばれるのは、その操作をした時点の内容です。 その後にファイルを編集しても、追加の修正が自動的にステージングされるわけではありません。Git公式：git add
たとえば、次の順番で作業したとします。
- READMEに「原稿はarticlesフォルダにあります」と書き、保存する。
git add README.mdでステージングする。- さらに「画像はimagesフォルダにあります」と追記し、保存する。
- 再度ステージングせず、基本形の
git commitを実行する。
この場合、コミットに入るのは手順2で選んだ内容です。手順3の追記は、手元のファイルにはありますが、そのコミットには入りません。
| 確認する場所 | この例で見える内容 |
|---|---|
| 手元のREADME | 原稿の説明と、画像の説明の両方 |
| ステージングエリア | 原稿の説明を追加した状態 |
| 新しく作るコミット | 原稿の説明を追加した状態 |
手順3の追記も同じコミットに含めたいなら、コミット前にもう一度git add README.mdを実行し、git diff --cachedで確認します。同じファイルがgit statusの「コミット予定」と「未ステージング」の両方に出ることもあります。Git公式：git status
→git add README.md：原稿の説明を追加した状態を選ぶ
→画像の説明を追記して保存
→画像の説明も同じコミットに含めたいか
→基本形のgit commit：原稿の説明を追加した状態を記録
→画像の説明の追記は手元に残り、そのコミットには入らない
→もう一度git add README.mdを実行
→git diff –cachedで確認
→コミット：原稿と画像の説明を追加した状態を記録
7. 選び直しと、コミットのまとめ方
ステージングを取り消しても、編集を消す必要はない
すでにコミット履歴があるリポジトリで、READMEを今回の記録から外したい場合は、次のようにします。
git restore --staged README.mdこの操作はインデックスを直前のコミットの状態へ戻し、手元の編集内容は残します。変更を取り消すのではなく、今回のコミットに含める選択を解除するための操作です。Git公式：git restore
一方、--stagedを付けないgit restore README.mdは作業ツリーを戻す操作で、手元の未記録の編集を失うことがあります。選択を解除したいだけなら、オプションまで確認して使いましょう。
一つの目的を、一つのコミットにする
この記事では、コミットを「一つの目的が説明できる大きさ」にまとめることを提案します。
| まとめ方 | あとから読んだときのわかりやすさ |
|---|---|
| READMEの手順修正を一つにまとめる | 何を改善した記録か説明しやすい |
| 誤字修正と無関係な機能追加を一緒にする | 目的や確認範囲をつかみにくい |
| 一つの修正を必要以上に細かく分ける | どこまでで修正が完了したか追いにくい |
同じ目的なら、複数のファイルが一つのコミットに入っても構いません。たとえば、使い方を変えたときに、処理の修正とREADMEの更新を一緒に記録すれば、その状態の説明と実際の動作が対応します。
また、git add .は現在のフォルダ以下の変更を広くステージングするため、作業途中の修正まで含まれることがあります。便利な操作ですが、最初はファイル名を指定して選び、コミット前に差分を読む習慣を付けると理解が進みます。Git公式：git add
8. まとめと理解度確認
- 保存は、手元のファイルを更新すること。
- ステージングは、次のコミットに反映する変更を選ぶこと。
- コミットは、選んだ状態を説明付きで履歴に残すこと。
- pushは、手元のコミットを共有先へ送ること。
最初は「状態を確認する → 変更を選ぶ → 選んだ差分を確認する → 記録する」という流れを覚えましょう。コマンドの名前と、それがどの場所に作用するかを結び付けることが大切です。
自分の言葉で説明してみる
- READMEを編集して保存しただけで、Gitの履歴は増えますか。
- READMEと記事原稿を編集し、READMEだけをステージングしてコミットすると、原稿の編集はどうなりますか。
- ステージングした後、同じファイルに追記した内容は、自動的に次のコミットへ入りますか。
- コミット予定の変更を確認するには、どのコマンドを使いますか。
- 編集内容を残したまま、READMEのステージングを解除するにはどうしますか。
解答例
- 増えません。履歴に残すには、コミットが必要です。
- 今回のコミットに原稿の修正は入りません。修正内容は手元に残ります。
- 入りません。含めたいなら、追記後に再度ステージングします。
git diff --cached、またはgit diff --stagedを使います。- すでにコミット履歴がある場合、
git restore --staged README.mdを使います。
参考資料
- Git公式：変更をリポジトリに記録する
- Git公式：git add
- Git公式：git commit
- Git公式：git status
- Git公式：git diff
- Git公式：git restore
- Git公式：リモートでの作業
資料確認日：2026年10月11日。
コメント