git addとgit commitの違いがわからない人のための実践ガイド

こんにちは、とまだです。

git addとgit commitの違いって、最初はわかりづらいですよね。 「なぜわざわざ2段階に分けるの？」と疑問に思いませんか？

実はこの仕組みには、とても実用的な理由があるんです。

今回は、Gitの基本操作であるステージングとコミットについて、実践的な視点から解説します。

Gitの基本的な仕組みを理解する

バージョン管理システムとは何か

プログラムを書いていると、日々ファイルを修正します。 新機能を追加したり、バグを修正したり。

でも時には「さっきまでのコードのほうが良かった」と後悔することもあります。

Gitは、そんな場面で力を発揮するツールです。 ファイルの変更履歴を時系列で保存し、必要に応じて過去の状態に戻せます。

リポジトリという概念

Gitでは、プロジェクトの履歴を保存する場所を「リポジトリ」と呼びます。

自分のパソコンにあるのが「ローカルリポジトリ」。 GitHubなどのサーバーにあるのが「リモートリポジトリ」です。

普段の作業は、ローカルリポジトリで行います。 そして必要に応じて、リモートリポジトリと同期を取ります。

ステージングエリアの役割

なぜステージングが必要なのか

Gitの特徴的な仕組みが「ステージングエリア」です。 これは、コミットする前の一時的な保管場所のようなものです。

たとえば、5つのファイルを修正したとします。 でも、そのうち3つだけを先にコミットしたい。

ステージングエリアがあれば、必要なファイルだけを選んでコミットできます。 この柔軟性が、Gitの大きな強みです。

git addの実際の動作

git addコマンドは、変更をステージングエリアに追加します。

git add ファイル名

このコマンドを実行すると、指定したファイルの変更がステージングされます。 まだコミットはされていません。

複数のファイルを一度に追加することもできます。

git add file1.js file2.css file3.html

すべての変更を追加する場合は、次のように書きます。

git add .

ただし、このコマンドは慎重に使いましょう。 意図しないファイルまで含まれる可能性があります。

コミットで履歴を記録する

git commitの基本

ステージングした変更を、正式な履歴として記録するのがコミットです。

git commit -m "ログイン機能を実装"

-mオプションの後に、変更内容を簡潔に記述します。 これがコミットメッセージです。

良いコミットメッセージの書き方

コミットメッセージは、後から見返すときの重要な手がかりです。 具体的で明確に書くことが大切です。

良い例：

ユーザー登録時のメールアドレス検証を追加
ヘッダーのレスポンシブ対応を実装
ログイン失敗時のエラーメッセージを改善

避けたい例：

修正
更新
変更

何を変更したのか、一目でわかるメッセージを心がけましょう。

実際の開発での使い方

変更状況を確認する習慣

作業中は、こまめに状況を確認することが大切です。

git status

このコマンドで、現在の変更状況が一覧表示されます。 どのファイルが変更され、どれがステージングされているか確認できます。

差分を確認してからコミット

コミット前に、実際の変更内容を確認しましょう。

git diff

ステージング済みの変更を確認する場合は：

git diff --staged

予期しない変更が含まれていないか、必ずチェックします。

部分的なステージング

ファイルの一部だけをステージングすることもできます。

git add -p ファイル名

このコマンドを使うと、変更箇所ごとにステージングするか選べます。 バグ修正と新機能の追加が混在している場合などに便利です。

よくある場面での対処法

コミットを取り消したい

直前のコミットを取り消す方法です。

git reset --soft HEAD^

変更内容はステージングエリアに戻ります。 コミットメッセージを修正したい場合などに使います。

完全に変更を破棄する場合は：

git reset --hard HEAD^

ただし、このコマンドは変更内容も消えるので注意が必要です。

ステージングを取り消す

間違えてステージングしたファイルを戻す方法です。

git reset HEAD ファイル名

ファイルの変更自体は残り、ステージングだけが解除されます。

.gitignoreの活用

管理対象から除外する

すべてのファイルをGitで管理する必要はありません。 ビルドファイルや個人設定など、除外すべきファイルもあります。

.gitignoreファイルに、除外したいパターンを記述します。

# ビルドファイル
dist/
build/

# 依存関係
node_modules/

# 環境設定
.env
.env.local

# IDE設定
.vscode/
.idea/

# OS関連
.DS_Store
Thumbs.db

プロジェクト開始時に設定しておくと、後々の管理が楽になります。

チーム開発での注意点

コミットの粒度

チーム開発では、コミットの粒度が重要です。 1つのコミットには、1つの目的だけを含めましょう。

たとえば：

• バグ修正
• 新機能の追加
• リファクタリング

これらは別々のコミットにします。 レビューがしやすくなり、問題があった場合の切り戻しも簡単です。

プッシュ前の確認

リモートリポジトリにプッシュする前に、必ず最新の状態を取得します。

git pull origin main

コンフリクトが発生した場合は、適切に解決してからプッシュします。

git push origin main

より実践的な活用方法

ブランチを活用した開発

実際の開発では、機能ごとにブランチを作成します。

git checkout -b feature/user-authentication

このブランチで作業し、完成したらメインブランチにマージします。 メインのコードを安定した状態に保ちながら、新機能を開発できます。

コミット履歴の確認

過去のコミット履歴を確認する方法です。

git log --oneline

簡潔な一覧表示で、履歴を素早く確認できます。

より詳細な情報を見たい場合：

git log -p -2

直近2件のコミットの差分も含めて表示されます。

まとめ

git addとgit commitの2段階構成は、最初は面倒に感じるかもしれません。

でも、この仕組みのおかげで：

• 必要な変更だけを選んでコミットできる
• コミットの内容を整理できる
• チーム開発での履歴管理がしやすくなる

これらのメリットがあります。

まずは基本的なコマンドから始めて、徐々に慣れていきましょう。 git statusで状況を確認し、git addでステージング、git commitで記録。

この流れを繰り返すうちに、自然と身についていきます。

Gitは開発者にとって必須のツールです。 基礎をしっかり理解して、効率的な開発を実現しましょう。