git commitの使い方ガイド：基本操作からConventional Commitsまで

「コミットメッセージ、何を書けばいいかわからない」「あとで見返したとき、何を変更したか思い出せない」そんな経験はありませんか。git commitはGitの中でも最も頻繁に使うコマンドですが、正しく使いこなせているエンジニアは意外と少ないものです。

この記事では、git commitの基本操作から実践的なベストプラクティスまでを解説します。コミットメッセージの書き方やチーム開発で役立つConventional Commitsについても紹介するので、日々の開発ワークフローを改善するヒントが見つかるはずです。

git commitとは

git commitは、Gitリポジトリへ変更を記録するコマンドです。ステージング領域（インデックス）に追加された変更を、スナップショットとして保存します。このスナップショットがコミットと呼ばれ、プロジェクトの履歴を構成する基本単位となります。

コミットには一意のハッシュ値（SHA-1）が割り当てられ、いつでもその時点の状態に戻ることができます。つまり、コミットは「セーブポイント」のような役割を果たします。適切にコミットを行うことで、バグが発生したときに原因を特定しやすくなり、チームメンバーとの協業もスムーズになります。

基本的なワークフロー

Gitでコミットを行うには、まずファイルをステージングする必要があります。ステージングとは、次のコミットに含めるファイルを選択する作業です。

# ファイルを編集
vim app.js

# 変更をステージング
git add app.js

# コミットを作成
git commit -m "Add user authentication feature"

git addでステージングしたファイルだけがコミットに含まれます。複数のファイルを変更した場合でも、関連する変更だけを選んでコミットできるのがGitの強みです。

ステージングをスキップする方法

すでにGitで追跡されているファイルであれば、-aオプションでステージングをスキップできます。

# 変更されたファイルを自動的にステージングしてコミット
git commit -a -m "Fix login validation bug"

ただし、新規ファイルは-aオプションでは追加されません。新しいファイルを含める場合は、必ずgit addを実行してください。

主要なオプション

git commitにはさまざまなオプションがあります。よく使うものを紹介します。

-m：メッセージをインラインで指定

最も基本的なオプションです。エディタを開かずに、コマンドラインでメッセージを指定できます。

git commit -m "Update README with installation instructions"

-v：変更内容を確認しながらコミット

エディタにdiff（変更差分）を表示してくれるオプションです。何を変更したか確認しながらメッセージを書けるので、より正確なコミットメッセージを作成できます。

git commit -v

--amend：直前のコミットを修正

コミット直後にタイポを見つけたり、ファイルを追加し忘れたりしたときに使います。

# メッセージを修正
git commit --amend -m "Fix typo in error message"

# ファイルを追加して修正（メッセージは変更しない）
git add forgotten-file.js
git commit --amend --no-edit

注意点として、--amendはコミットのハッシュ値を変更します。すでにリモートにプッシュしたコミットを修正すると、他のメンバーと履歴が食い違う原因になります。ローカルのコミットにのみ使用してください。

--dry-run：コミット対象を確認

実際にコミットせずに、どのファイルがコミットに含まれるかを確認できます。

git commit --dry-run

コミットメッセージの書き方：7つのルール

良いコミットメッセージは、将来の自分やチームメンバーにとって貴重な資産になります。Chris Beamsが提唱する7つのルールを紹介します。

ルール1：件名と本文を空行で分ける

1行目は件名（タイトル）、空行を挟んで本文を書きます。これによりgit log --onelineなどのコマンドで件名だけを表示できます。

Add user authentication with JWT

Implement JWT-based authentication to replace
session-based auth. This change improves
scalability and enables stateless API design.

ルール2：件名は50文字以下

50文字を超えるとGitHubなどで省略表示されます。簡潔に変更内容を伝えましょう。

ルール3：件名の最初を大文字に

英語でコミットメッセージを書く場合、最初の文字は大文字にします。

ルール4：件名末尾にピリオドをつけない

件名はタイトルなので、ピリオドは不要です。

ルール5：件名は命令形で書く

「Fix bug」のように命令形で書きます。「Fixed bug」や「Fixing bug」ではありません。確認方法として、「If applied, this commit will __」に当てはめて自然な文になるかチェックしましょう。

良い例: If applied, this commit will "Add validation for email field"
悪い例: If applied, this commit will "Added validation for email field"

ルール6：本文は72文字で折り返す

ターミナルでの可読性を保つため、本文は72文字程度で改行します。

ルール7：本文は「何」「なぜ」を説明する

「どう実装したか」ではなく「何を変更したか」「なぜ変更が必要だったか」を書きます。コードを見れば「どう」はわかりますが、「なぜ」はコミットメッセージにしか残りません。

Conventional Commits

チーム開発では、コミットメッセージの書き方を統一することで、履歴の可読性が大幅に向上します。Conventional Commitsは、構造化されたコミットメッセージの仕様です。

基本構文

<type>(<scope>): <description>

[optional body]

[optional footer]

使用可能なtype

typeはコミットの種類を示すプレフィックスです。主なものを紹介します。

実際の例

# 新機能の追加
feat(auth): add OAuth2 login support

# バグ修正
fix(parser): resolve null pointer exception on empty input

# ドキュメント更新
docs: update API reference for v2 endpoints

# リファクタリング
refactor(api): simplify error handling logic

破壊的変更（BREAKING CHANGE）の記述

後方互換性のない変更を行う場合は、明示的に記述します。

# 方法1: フッターに記載
feat(api): change authentication endpoint

BREAKING CHANGE: /auth/login endpoint now requires email instead of username

# 方法2: typeの後に!を付与
feat!: remove deprecated API endpoints

Conventional Commitsのメリット

Conventional Commitsを採用することで、CHANGELOGの自動生成やセマンティックバージョニングの自動化が可能になります。また、git log --grep="feat"のようにコミットを検索しやすくなり、コードレビューの効率も向上します。

よくあるミスと対処法

git commitに関するよくあるミスと、その解決方法を紹介します。

間違ったブランチにコミットした

mainブランチに直接コミットしてしまった場合の対処法です。

# 正しいブランチを作成（現在のコミットを含む）
git branch feature/correct-branch

# mainブランチを1つ前のコミットに戻す
git reset HEAD~ --hard

# 正しいブランチに切り替え
git checkout feature/correct-branch

コミットを取り消したい

変更を残すか破棄するかで、使うコマンドが異なります。

# 変更を残したまま取り消し（ステージングも維持）
git reset --soft HEAD~

# 変更を残したまま取り消し（アンステージ状態に）
git reset --mixed HEAD~

# 変更も含めて完全に取り消し
git reset --hard HEAD~

すでにリモートにプッシュしたコミットを取り消す場合は、git revertを使います。これは新しいコミットとして「取り消し」を記録するため、履歴を書き換えずに済みます。

git revert <commit-hash>

機密情報をコミットしてしまった

APIキーやパスワードをコミットしてしまった場合は、まずその認証情報を無効化することが最優先です。プッシュ前であればgit resetで取り消せますが、プッシュ後の場合はgit filter-branchやBFG Repo-Cleanerで履歴から完全に削除する必要があります。

Git Hooksでコミット品質を自動化

Git Hooksを使うと、コミット時に自動でリンターやテストを実行できます。

pre-commit

コミット前に実行されるフックです。

#!/bin/sh
# .git/hooks/pre-commit

npm run lint
npm run test

commit-msg

コミットメッセージを検証するフックです。Conventional Commits形式を強制する例を紹介します。

#!/bin/sh
# .git/hooks/commit-msg

if ! grep -qE "^(feat|fix|docs|style|refactor|perf|test|build|ci|chore)(\(.+\))?: .+" "$1"; then
    echo "Error: Commit message must follow Conventional Commits format"
    exit 1
fi

推奨ツール

手動でフックを設定するのは面倒なので、以下のツールを使うと便利です。

Huskyを使えば、package.jsonでGit Hooksを管理できます。lint-stagedと組み合わせることで、ステージされたファイルのみにリンターを適用できます。commitlintはConventional Commits形式を強制するツールで、チーム全体のコミットメッセージ品質を担保できます。

まとめ

git commitはシンプルなコマンドですが、使い方次第でプロジェクトの保守性が大きく変わります。

基本操作として、git addでステージングしてからgit commitを実行します。-mオプションでメッセージを指定し、-vで変更内容を確認しながらコミットできます。--amendでローカルのコミットを修正できますが、プッシュ済みのコミットには使わないでください。

コミットメッセージは50文字以下の命令形で書き、「何」「なぜ」を説明します。チーム開発ではConventional Commitsの導入を検討してください。Git HooksとHusky、commitlintを組み合わせることで、コミット品質を自動的に担保できます。

適切なコミットを習慣化することで、将来の自分やチームメンバーが感謝する履歴を残せます。

参考リンク

公式ドキュメントとして、Git公式 – git commitとGit Book – Recording Changesが基本的な情報源になります。

コミットメッセージのベストプラクティスについては、How to Write a Git Commit MessageがChris Beamsによる決定版ガイドです。Conventional Commitsは構造化コミットメッセージの公式仕様サイトです。

トラブルシューティングにはOh Shit, Git!?!が役立ちます。緊急時の対処法がわかりやすくまとめられています。