【初心者向け】Git コミット (git commit) とステージング (git add) の基本を徹底解説
はじめに
Gitは、ファイルの変更履歴を管理するためのソフトウェアです。
プログラミング初心者や、これから開発の現場に足を踏み入れようとする皆さんにとって、バージョン管理は欠かせない考え方です。
Gitを使いこなすと、自分が行った変更点をいつでも振り返ったり、必要に応じて過去の状態に戻したりすることができます。
しかし、最初は「ステージングってなに？」「コミットとは？」と戸惑う方も多いかもしれません。
ここでは、そのような疑問を解消し、基本的なGit操作をしっかり理解するお手伝いをします。
この記事を読むとわかること
- ステージングとコミットの基本的な役割
- 実際の開発現場で行われるGit操作の流れ
- よく使うコマンドの意味と使い方
- 実務でありがちなトラブルにどう対処するか
- バージョン管理をスムーズに運用するコツ
Gitとは何か
バージョン管理システムとは
プログラムのファイルやドキュメントは、時間とともに少しずつ内容が変わっていきます。
たとえばWebサイトのコードを修正して新しい機能を追加したり、誤字脱字を直したりと、ファイルにはさまざまな変更が加わります。
そうした変更を手動で管理していくのは、混乱やミスのもとになりやすいものです。
そこで誕生したのが、バージョン管理システムと呼ばれる仕組みです。
これは、ファイルがどのように変更されたかを、時系列でデータとして残し、必要に応じて過去の状態に戻すなどの操作を可能にします。
Gitは、そのバージョン管理システムの中で現在もっとも広く使われているツールの一つです。
大きな特徴は、開発者のパソコンにもローカルリポジトリと呼ばれる履歴を保存し、インターネット上にあるリモートリポジトリともやり取りできる点です。
リポジトリとローカル作業フォルダの関係
Gitでは、変更履歴を管理するデータベースのことを「リポジトリ」と呼びます。
リポジトリには、自分が変更したファイルの差分や、コミットと呼ばれる“履歴のまとまり”が順番に記録されていきます。
ローカル環境（自分のパソコン）のリポジトリ内で完結して作業することもできますし、GitHubなどのリモートリポジトリに対して変更を送る（プッシュする）ことも可能です。
通常は、プロジェクト用のフォルダを作ってそこをGitリポジトリ化します。
このフォルダを作業フォルダ（ワーキングディレクトリ）とも呼び、コード修正や新しいファイルを追加するなど、日々の作業はこの場所で行います。
ステージングとコミットの違い
ステージングエリアとは何か
Gitには ステージングエリア (インデックスとも呼ぶ)という独特の仕組みがあります。
これは、リポジトリに対して「次にコミットしたい変更を一時的にまとめておく場所」です。
たとえば、複数のファイルを一度に編集した場合でも、コミットに含めたいものだけを“ステージ”に追加することができます。
ステージングは、「このファイルの変更は次のコミットに含める」という指定を行う作業です。
変更したファイルを直接リポジトリに記録するのではなく、一度ステージに“保留”してからコミットするため、粒度を細かく管理しやすくなります。
コミットとは何か
コミットは、実際にリポジトリへ変更点を記録する行為です。
写真のスナップショットを撮るようなイメージで、コミットするタイミングで「ここまでの変更」をひとまとめにして履歴として保存します。
このコミットに名前をつけるのがコミットメッセージです。
コミットメッセージをしっかり書いておくことで、あとから自分やチームのメンバーが変更内容や意図を理解しやすくなります。
Gitでは「いつ、誰が、どんな内容を、どんな理由で変更したか」がコミット単位で残されます。
これがGitの強みであり、後からコードを見返すときや、バグ修正時などに大きな助けとなります。
Gitの基本操作フロー
git add → git commit の一連の流れ
Gitで日常的に行う操作は、次のような手順になることが多いです。
- 作業フォルダでファイルを修正・追加・削除する
- 変更内容を「git add」でステージングする
- 変更をまとめて「git commit」で履歴に記録する
ステージングとコミットは分かれているので、複数ファイルのうち特定のファイルだけ先にステージングしたり、逆にステージングを取り消したりすることができます。
そこがGitの柔軟さにもつながっています。
変更内容を確認するgit status
コミット前に自分がどのファイルを修正したか、あるいは新しく作ったファイルをGitが認識しているか、確認したくなることがあります。
そのときによく使うのがgit statusコマンドです。
git status
このコマンドを実行すると、ステージングされていないファイル、すでにステージングされたファイルが一覧表示されます。
これによって、どのファイルがまだaddされていないかを見落とさずにすみます。
ファイルの変更をステージングする
ファイルを追加したときの流れ
ファイルを新たに作成し、Gitで管理したい場合はgit addを使います。
たとえば新しいHTMLファイルを作り、それを次のコミットに含めたい場合は次のようにします。
git add index.html git commit -m "Add new index.html"
こうすると、index.htmlの追加が一つの履歴としてコミットされます。
複数のファイルをまとめてステージングしたい場合は、git add .でカレントディレクトリ以下の変更を一気にステージングすることが可能です。
部分的にステージングしたい場合（git add -pなど）
あまり知られていない機能として、ファイル全体ではなく一部だけをステージングする方法も存在します。
コードの変更が多岐にわたるとき、まずはバグ修正の変更だけをコミットし、後から機能追加の変更を別のコミットに分けたい場合などに役立ちます。
そのときに使うのがgit add -pです。
git add -p
このコマンドを実行すると、変更の差分ごとに「ステージングするかどうか」を対話的に選択することができます。
こうしてコミットを細かく分けておくと、後から履歴を追いやすくなり、原因調査やバグ修正の際にも役立ちます。
コミットのタイミングとメッセージ
こまめにコミットする理由
Gitのコミットは、ソースコードの「スナップショット」を残すことです。
慣れないうちは、どのタイミングでコミットを行うべきか迷うかもしれません。
一般的には、意味のあるまとまりができあがったらコミットするのがおすすめです。
たとえば「ボタンをクリックしたらフォームが送信されるようになった」といった、ある程度の完結した変更単位でコミットします。
一気に大きな変更をしてからコミットすると、何か問題があった際にどの部分でミスが起きたのか把握しづらくなります。
逆に一回のコミットが小さすぎると履歴が散らばり、後で見返すときにわかりづらくなるケースもあります。
重要なのは、後から変更内容を振り返るときに把握しやすい大きさでコミットをまとめることです。
わかりやすいコミットメッセージを書くコツ
コミットメッセージには、変更内容や目的を簡潔に書いておくと後で見返すのが容易になります。
たとえば「Fix login bug」や「Implement user registration form」など、何を変えたかがぱっと見でわかるようにすることが大切です。
コミットメッセージが長くなりそうな場合は、以下のようにメッセージの1行目を要約、2行目以降で補足説明を書くやり方もあります。
git commit -m "Fix session bug in login screen Remove unnecessary sessions and fix cookie expiration"
ただし初心者の場合は、1行で簡潔に書いても問題ありません。
コミットを読み返したときに内容を思い出せるようなキーワードを盛り込む意識を持つと良いでしょう。
失敗をリカバリーする方法
コミットを取り消したいとき
初めてGitを使うと、間違えた変更をコミットしてしまうことがあります。
そんなときにもGitには巻き戻す方法が用意されています。
たとえば、まだリモートにプッシュしていないコミットであれば、git reset --soft HEAD^で直前のコミットを取り消しながら、変更自体はステージングに戻すことが可能です。
git reset --soft HEAD^
すると、一つ前の状態までコミットが巻き戻り、編集内容はステージングエリアへ戻ります。
別のやり方として、git revert <コミットID>を使う方法もあります。
git revertは新たに「取り消しを行った」ことをコミットとして追加するため、履歴の整合性が保たれるのが特徴です。
これはチーム開発でもよく使われるリカバリー手段の一つです。
ステージのやり直し
「間違ってaddしてしまったので、もう一度やり直したい」というケースもあります。
そういった場合には、git resetコマンドを使ってステージングした内容を取り消せます。
git reset HEAD <ファイル名>
こうすると、そのファイルのステージングが外れた状態（修正だけは残った状態）に戻ります。
初心者のうちは、このリセット作業を怖がる方もいるかもしれませんが、いったんコミットさえしていなければ、歴史を破壊するわけではありません。
あくまで「ステージングの取消し」に過ぎないので安心してください。
実務でよくあるステージングとコミットの使い方
チーム開発でのステージングの便利さ
チームで開発していると、同じリポジトリを複数人で共有します。
ここでは、勝手にファイルをコミットする前に「何をコミットしようとしているのか」をきちんと把握しておく必要があります。
ステージングエリアがあることで、コミットに含める変更を意図的にコントロールできるのは大変助かります。
たとえば、慌ててコマンドを打った際に、テスト用のログ出力や、消し忘れたデバッグ用コードをうっかりコミットする事故を防ぐためにも、git statusやgit diffで差分をチェックしつつ、必要なものだけをステージングするのが一般的な流れです。
この習慣はチーム全体の品質管理にも関わるため、実務では重視されがちです。
大規模プロジェクトでの粒度の考え方
大規模なプロジェクトでは、1つの機能追加でも多くのファイルを触ることがあります。
そのときに小分けにコミットをしておかないと、後から履歴を振り返るときにどこで何を変更したのかを追えなくなることがあります。
「機能AのUI追加」「機能Aのバグ修正」「機能Aのテストコード更新」のように、目的ごとに変更をステージングしてコミットを分けるのが好ましいです。
これにより、問題が起きたときに該当のコミットだけ取り消す、といった柔軟な対応がしやすくなります。
.gitignoreの役割
ステージに含めたくないファイルを管理する
Gitプロジェクトには、.gitignoreという設定ファイルを置くことがあります。
ここに書かれたパターンに合致するファイルは、git add .をしてもステージングに含まれません。
コンパイル後のファイルやビルドによって生成されるディレクトリ、OS依存の隠しファイルなどは、Gitで管理してもあまりメリットがありません。
むしろ不要なファイルのコミットはリポジトリを肥大化させ、更新時にも混乱を招く恐れがあります。
だからこそ**.gitignore**ファイルを設定して、あらかじめ「これは不要」と指定しておくのです。
初心者が陥りがちなミス
初心者がよくやってしまうのが、「.gitignoreに追加したつもりだけど、すでにコミット済みのファイルがリポジトリに含まれている」という状況です。
一度コミットされてしまったファイルは、.gitignoreに書いても自動では削除されません。
この場合は手動でgit rm --cached <ファイル名>を使ってステージから外す必要があります。
うっかり大容量のファイルをコミットしてしまった後で気づくケースもあるので、最初の段階でしっかりと設定しておくと良いでしょう。
ブランチとコミットの関係
ブランチを切って作業するメリット
ステージングやコミットをより活用するには、ブランチを意識するといいでしょう。
ブランチを使うと、メインの作業ラインとは別の枝分かれしたラインで変更を行い、後から統合することができます。
大きな機能追加や実験的な修正をするとき、ブランチを切ってコミットを積み重ねていくのが一般的です。
これによって、メインブランチを安定した状態に保ちながら新しい変更を進められます。
また、変更内容を後からまとめてメインブランチに取り込むかどうか、チームでレビューすることも容易になります。
実務ではブランチごとにコミットを積む運用が一般的
実務環境では、多くの場合「1つのタスク（または機能開発） = 1ブランチ」というイメージで作業します。
新しいブランチを切って作業を開始し、その上でコミットを積み重ね、問題なく動くことが確認されたらメインブランチ（または開発用ブランチ）に統合する流れが一般的です。
コミットメッセージや、コミットの粒度がきちんと管理されていると、後で差分をレビューするときにも「どのタイミングで何をしたか」が明確にわかりやすくなります。
リモートリポジトリへのプッシュ
コミットしてからリモートに反映する基本手順
ステージングしてコミットを作成すると、そのコミットは自分のローカルリポジトリ内に記録されます。
この状態ではまだ、GitHubや社内サーバーにあるリモートリポジトリには反映されていません。
リモートリポジトリに変更を反映するのがプッシュ(push)です。
git push origin ブランチ名
このコマンドを実行すれば、今までローカルに積み重ねてきたコミットがリモートに送られます。
リモートとのコンフリクトを防ぐポイント
チーム開発では、自分だけでなく他の人も同じリポジトリを使っているため、プッシュ前にgit pullして最新の変更を取り込む必要があります。
これを怠ると、リモート側にある変更との競合（コンフリクト）が起きやすくなります。
実務では、次のような流れを習慣化しておくとスムーズです。
- ローカルで作業をしてコミットを作る
- プッシュ前に
git pullしてリモートの最新を取得し、必要があればマージ（統合）する - 問題がなければ
git pushで変更を反映する
もし競合が発生した場合は、コンフリクト部分を解消してから再度コミットしてプッシュする流れになります。
ステージング・コミット・プッシュはあくまで開発の基本の流れです。
実際のチーム開発では、コードレビューを挟む運用やブランチ運用のルール設定など、さらにいくつものステップや決まりが追加されることがあります。
しかし、まずはステージングとコミットがしっかり理解できれば、Gitの全体像をつかむ上で大きく前進できるでしょう。
まとめ
Gitでバージョン管理を行う際には、 ステージング (git add) とコミット（git **commit）**が要となります。
ステージングは「次のコミットに含める変更を選別する作業」、コミットは「選んだ変更を履歴として記録する作業」です。
この2段階の手順を踏むことで、複数の変更が混在する状況でも、柔軟に管理できるようになります。
さらに、コミットの履歴をしっかり残せば、後から何をいつ変更したかをすばやく振り返ることができます。
チーム開発においては、ステージングされた内容を正確に把握し、適切なコミットメッセージを書き、必要に応じてブランチを活用することで、開発効率とコード品質を保ちやすくなります。
初めのうちはコマンドを忘れがちで混乱するかもしれませんが、実際に使いながら少しずつ覚えていくうちに自然と身につくはずです。
あせらずコツコツと、ステージングとコミットの流れを習得して、バージョン管理を味方につけていきましょう。