とりあえず動いたから git commit -m "update" でいいか
修正内容が多いけど、まとめて git commit -m "fix" にしちゃおう
チーム開発に入りたての頃、誰もが一度はやってしまう書き方ですよね。ですが、数週間後の自分や、あなたのコードをチェックする先輩エンジニアにとって、これほど不親切なものはありません。
いざバグが見つかったときに「どのコミットが原因か分からない」と絶望したり、プルリクエストのレビューで「このコミット、何を変えたの？」と指摘されて気まずい思いをしたり……。そんな悩みの種である「コミットメッセージ」には、実は世界共通の「正解」があります。
Gitのコミットメッセージは、単なる作業の保存ラベルではなく、プロジェクトの歴史を記録する大切な「設計書」の一部です。ルールを知っているだけで、あなたの評価は「ただコードが書ける人」から「チーム開発を円滑にできるプロのエンジニア」へと一気に引き上がります。
この記事では、現場でそのまま使える「Gitコミットメッセージの鉄則」を分かりやすく解説します。
この記事を読み終える頃には、もうコミットボタンを押す前に迷うことはなくなります。自信を持って「伝わる履歴」を残せるようになり、チーム開発をもっとスムーズに、もっと楽しく進めていきましょう！
Gitコミットメッセージの基本ルールと書き方
「とりあえずコードが書けたから保存しておこう」という感覚でコミットをしていませんか？個人開発ならそれでも通用しますが、チーム開発においてコミットメッセージは「未来の自分とチームメイトへの手紙」です。
ルールが曖昧だと、あとで不具合が見つかった際や、数ヶ月前の仕様を追いかける際に、膨大な時間を無駄にすることになります。まずは、プロがなぜ「書き方」にこだわるのか、その理由から見ていきましょう。
なぜコミットメッセージにルールが必要なのか
結論から言えば、「コードを読む前の文脈（コンテキスト）を共有するため」です。
- レビュー効率の向上： レビュアーはコードを見る前にメッセージを読みます。意図が明確なら「なぜこのコードを書いたのか」を推測する時間が省け、承認までの速度が上がります。
- バグ調査の高速化： 障害発生時、原因となった変更を特定する唯一のヒントはコミット履歴です。ルール化されていれば、検索性が高まり、即座に原因を突き止められます。
- 保守性の確保： 「修正」としか書かれていないコミットは、後から見た時に「消してもいいコードなのか」が判断できず、技術的負債を生む原因になります。
良いコミットと悪いコミットの違い
現場で「仕事ができる」と評価されるコミットと、指摘対象になるコミットを具体例で比較します。
❌ Bad：内容が不明瞭な例
git commit -m "update"
git commit -m "修正"
git commit -m "ログイン機能の調整"
なぜBadなのか： 「何を」「なぜ」変えたのかが全く分かりません。後から履歴を見た時に、コードを一行ずつ読み解く必要があり、エンジニアの工数を奪う最悪の書き方です。
✅ Good：意図が伝わる例
feat: ログイン画面にバリデーション機能を追加
- メールアドレスの形式チェック処理を実装
- 未入力時にエラーメッセージを表示するよう変更
- ユーザーの誤入力を防ぎ、認証エラー率を低下させるのが目的
なぜGoodなのか： 1行目で「新機能の追加」であることが分かり、本文で「変更内容」と「その目的」が補足されています。これならコードを見ずとも変更の全体像が把握できます。
日本語と英語どちらで書くべき？現場の判断基準
結論は、「プロジェクトの既存ルールに従う」のが鉄則です。判断に迷った場合は以下の基準を参考にしてください。
- 日本語が適しているケース： メンバー全員が日本人で、スピード感と意思疎通の正確さを最優先する場合。受託案件の多くはこちらです。
- 英語が適しているケース： OSS活動や、将来的に海外メンバーが参加する可能性があるプロジェクト。また、GitHubのポートフォリオを強化したい場合。
最近の日本の現場では、「Prefix（接頭辞）は英語、内容は日本語」というハイブリッド形式が、検索性と理解しやすさを両立できるため非常に好まれています。
1行目50文字・命令形など世界共通の基本フォーマット
世界中のエンジニアが共通認識として持っている「美しいコミット」のための型があります。これを守るだけで、あなたのコミットは一気にプロらしくなります。
- 1行目は50文字以内： GitHubなどのツールで一覧表示した際、末尾が省略されずに表示される限界の長さです。
- 1行目の最後には句読点（.）を入れない： タイトル（件名）としての扱いであるため、不要です。
- 2行目は必ず「空行」にする： ツールが1行目を件名、3行目以降を本文として正しく認識するために必須のルールです。
- 英語の場合は「命令形」で書く：
Added（追加した）ではなくAdd（追加せよ）と書くのがGitの伝統的な作法です。
次は、メッセージの書き方と同じくらい重要な、「どのタイミングでコミットを切るべきか」という粒度の話に移ります。
◆◇◆ 【衝撃価格】VPS512MBプラン！1時間1.3円【ConoHa】 ◆◇◆
レビューしやすいコミット粒度と履歴管理の考え方
メッセージの書き方をどれほど工夫しても、1つのコミットに複数の変更を詰め込みすぎると、ルールの価値は半減してしまいます。ここでは、エンジニアがレビュー時に最も重視している「コミットの切り方」と「履歴の整え方」の極意を解説します。
1コミット1トピックの判断基準
「どのタイミングでコミットすればいいか」という問いに対するプロの答えは、「1つのコミットには、1つの論理的な変更だけを含める」です。これを「アトミックコミット（原子コミット）」と呼びます。
❌ Bad：複数の目的が混在している例
git commit -m "feat: ログイン機能の実装とバグ修正、CSSの微調整"
なぜBadなのか： もしログイン機能に致命的な不具合が見つかり、その変更だけを差し戻したい（revert）と思っても、同時に入れた「バグ修正」や「CSS調整」まで消えてしまうからです。
✅ Good：1つの目的で完結している例
git commit -m "feat: ログインボタンのバリデーションロジックを追加"
なぜGoodなのか： 変更の目的が1つに絞られているため、万が一の差し戻し作業が安全かつ容易になります。
コミット前に「この変更を一言で説明できるか？」と自問してください。「〜と、さらに〜も直した」のように接続詞が増える場合は、コミットを分けるべきサインです。
git log が読みやすくなるコミット設計
後から履歴を追いやすくするためには、「時系列のストーリー」を意識してコミットを積み上げることが重要です。
理想的な git log の並びは以下の通りです：
feat: フォームの基本構造を作成feat: バリデーション処理を実装test: バリデーションのテストコードを追加docs: フォーム仕様書を更新
このように細かく、かつ論理的な順序で刻まれていると、レビュアーはあなたの思考プロセスを追体験できるため、確認作業の負荷が劇的に下がります。
squash merge・rebase 後のメッセージ整理方法
開発の試行錯誤の中で生まれた「ミス修正」や「タイポ修正」といった細かすぎるコミット（汚い履歴）は、そのままメインブランチに残すべきではありません。
- Squash Merge（スカッシュマージ）： プルリクエストをマージする際に、複数の細かいコミットを1つに統合する手法です。これにより、メインブランチの履歴を「1つのPR ＝ 1つの機能単位」として美しく保つことができます。
- Interactive Rebase（git rebase -i）： マージ依頼を出す前に、自分の手元でコミット履歴を書き換える手法です。不要なコミットを消したり、メッセージをより適切な表現に書き直したりできます。
経験済みエンジニアは、作業中は自由にコミットを打ちますが、提出前には必ず「他人が読みやすい形」に履歴をリフォームしてからレビューを依頼しています。
月額99円から。容量最大1TB！ブログ作成におすすめのWordPressテーマ「Cocoon」も簡単インストール
Conventional Commitsとprefix運用
「なんとなく fix: を使っているけれど、これで合っているのかな？」という不安を解消するのが、世界的に広く採用されている規約 「Conventional Commits（コンベンショナル・コミット）」 です。これに従うだけで、あなたのコミット履歴は一気に「機械的にも人間的にも読みやすい」プロ仕様に変わります。
Conventional Commitsとは？仕様とメリットを5分で理解する
Conventional Commitsは、コミットメッセージに特定の「型」を持たせるためのシンプルな規約です。
基本の型：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]- メリット1：履歴の自動整理 メッセージの先頭にある
type（prefix）を見るだけで、何が行われたかが一瞬で判別できます。 - メリット2：自動化との相性 規約が統一されているため、変更履歴（CHANGELOG）の自動生成や、セマンティックバージョニングとの連携が容易になります。
prefix（feat / fix / refactor / docs / chore / test）の意味と使い分け
実務で頻繁に使う主要なprefixをまとめました。迷ったらこの表を確認する習慣をつけましょう。
| prefix | 意味 | 使うタイミング（具体例） |
|---|---|---|
| feat | 新機能 | 新しいボタンの追加、APIエンドポイントの新規作成など |
| fix | バグ修正 | 表示崩れの修正、計算ロジックのミス修正など |
| refactor | リファクタリング | 動作は変えず、コードの構造を整理・綺麗にした時 |
| docs | ドキュメント | READMEの修正、コメントの追記、JSDocの作成など |
| style | スタイル | コードの意味に影響しない修正（インデント、セミコロン、フォーマット） |
| test | テスト | 単体テストの追加、既存テストの修正など |
| chore | 雑務 | ビルド設定の変更、ライブラリの更新、設定ファイルの編集など |
| perf | パフォーマンス | 実行速度の向上、メモリ使用量の削減など |
紛らわしい prefix の判断基準（refactor / chore / style など）
若手エンジニアが最も頭を悩ませる「使い分け」の判断基準を明確にします。
1. 「refactor」 vs 「chore」
- refactor: 「アプリケーションのソースコード」自体を、より良く書き換えた場合に使います。
- chore: 「アプリケーションの外側」の変更に使います。例えば、npmパッケージのインストールや、GitHub Actionsの設定変更、
.gitignoreの編集などがこれにあたります。
2. 「refactor」 vs 「style」
- refactor: ロジック（計算式や関数構成）の整理に用います。
- style: 見た目（インデント、改行、セミコロンの有無）のみの変更に用います。Prettierなどの自動整形ツールを適用しただけの時は
styleです。 - 注意： CSSのデザイン変更は、新機能なら
feat、修正ならfixに分類されるのが一般的です。
3. 「fix」 vs 「refactor」
- fix: 「今、壊れているもの」を直す時に使います。
- refactor: 「壊れていないが、将来のためにコードを綺麗にする」時に使います。
- 判断のコツ： もしバグが潜んでいるのを見つけて直した場合は、迷わず
fixを使いましょう。
💡 さらに一歩進む「スコープ」の活用
feat(auth): のようにカッコを使って 「影響範囲（スコープ）」 を指定すると、より親切です。
feat(login): パスワードリセット機能を追加fix(header): スマホ表示時のロゴのズレを修正
次は、「具体的なコマンド操作と、そのまま使えるテンプレート集」を紹介します。
通信無制限なのに工事不要！【SoftbankAir】
実務コマンドとテンプレート集
知識として書き方を理解したら、次は「いかに効率よく、正確にアウトプットするか」が重要です。ここでは、日々の開発スピードを落とさずに、質の高いメッセージを残すための実践テクニックを紹介します。
git commit -m／複数行メッセージ／-amend の基本コマンド
メッセージを入力する際、1行の短い文章だけで済ませていませんか？ 複雑な修正ほど、複数行で背景を説明する必要があります。
1. 複数行のメッセージを入力する
コマンドラインで複数行書きたい場合は、-m を複数回使うのが最も簡単です。
git commit -m "feat: ログインバリデーションの実装" -m "- 未入力チェックを追加" -m "- メール形式の正規表現を修正"
※ 最初の -m が件名、2番目以降の -m が本文として扱われます。
2. エディタを立ち上げてじっくり書く
コマンドを指定せずに git commit とだけ打つと、設定されているエディタ（VimやVSCodeなど）が開きます。ここでじっくり本文を推敲するのが、プロの間では一般的です。
3. 直前のメッセージを修正する（-amend）
「タイポした！」「Prefixを忘れた！」という時は、焦らず以下のコマンドを使いましょう。
git commit --amend -m "fix: 正しいメッセージに書き換え"
※ すでにリモートへ push してしまった後の修正は、チームに混乱を招くため控えましょう。
コマンドのチートシート
よく使うコマンドを一覧化しました。
基本操作
| コマンド | 説明 |
|---|---|
git commit -m "message" | 1行メッセージでコミット |
git commit | エディタでメッセージを編集 |
git commit --amend | 直前のコミットを修正 |
git commit --amend --no-edit | メッセージそのままでファイル追加 |
git log --oneline | コミット履歴を1行表示 |
git log --oneline -10 | 最新10件を表示 |
メッセージの確認・修正
| コマンド | 説明 |
|---|---|
git show HEAD | 最新コミットの詳細を表示 |
git log --grep="feat" | “feat”を含むコミットを検索 |
git log --author="Taro" | 特定の作者のコミットを検索 |
git rebase -i HEAD~3 | 直近3コミットを対話的に編集 |
緊急時の操作
| コマンド | 説明 |
|---|---|
git revert HEAD | 最新コミットを取り消し |
git revert a1b2c3d | 特定のコミットを取り消し |
git reset --soft HEAD~1 | コミットを取り消し(変更は残す) |
git reset --hard HEAD~1 | ⚠️ コミットと変更を完全削除 |
git reset --hardは変更が完全に消えます。使用前に必ずバックアップを。
便利なエイリアス設定
よく使うコマンドはエイリアスに登録すると効率的です:
# エイリアス設定
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"
使用例:
# 通常
git commit -m "feat: add feature"
# エイリアス使用
git ci -m "feat: add feature"
おすすめエイリアス:
# 綺麗なログ表示
git config --global alias.tree "log --oneline --graph --decorate --all"
# 直前のコミットを修正
git config --global alias.amend "commit --amend --no-edit"
# ステージングとコミットを同時に
git config --global alias.cm "commit -am"
そのままコピペで使えるコミットメッセージテンプレ集
何を書くか迷ったときに使える、汎用性の高いテンプレートを用意しました。これを辞書ツールやスニペットに登録しておくだけで、手が止まる時間がなくなります。
基本テンプレート
<type>: <件名>
- <変更点1>
- <変更点2>
- <なぜこの変更が必要だったか、背景やリンク>
実務で使える具体例
- 新機能追加（feat）
feat: お気に入り登録機能の非同期化 - バグ修正（fix）
fix: iOS版Safariで画像がはみ出す問題を修正 - リファクタリング（refactor）
refactor: 重複していたバリデーションロジックを共通関数に集約
Revert・Hotfix・緊急対応時に使える専用メッセージテンプレート
トラブル時ほど、焦ってメッセージが雑になりがちです。そんな時こそ、以下の型に当てはめて冷静に記録を残しましょう。
1. 変更の取り消し（Revert）
Gitの revert コマンドを使うと自動生成されますが、理由を追記するのがマナーです。
revert: "feat: 決済APIの導入"
本コミットにより本番環境でタイムアウトエラーが多発したため、一時的に切り戻し。
原因調査後、再度実装予定。
2. 緊急修正（Hotfix）
深夜や休日など、とにかく急いで直した場合は、後で誰が見ても「緊急だった」とわかるように記録します。
fix: 【緊急】本番環境のログイン不可バグを修正
原因：環境変数の読み込みミス。
影響範囲：全ユーザー。
応急処置として定数定義で対応。恒久対応は別途Issue #123 で実施。
次は、現場でよく聞かれる疑問を解消する「よくある質問（FAQ）」を紹介します。
送料無料の情報が満載！ネットで買うなら楽天市場
よくある質問（FAQ）
Gitコミットメッセージの運用を始めると、必ずと言っていいほど直面する細かな疑問に回答します。
-
コミットメッセージは絶対に英語で書かないとダメですか?
-
A. いいえ、チームの方針次第です。
英語が推奨される理由はありますが、絶対ではありません。
▼判断基準
状況 推奨言語 理由 チームが全員日本人 日本語でもOK コミュニケーション効率優先 オープンソースプロジェクト 英語 世界中の開発者が読む グローバル企業 英語 多国籍チーム対応 既存リポジトリが日本語 日本語 統一性を保つ 日本語でも prefix は英語で統一することが多いです:
✅ ハイブリッド型(推奨): feat: ログインフォームにバリデーションを追加 fix: ボタンの無効化状態が解除されないバグを修正 ❌ 完全日本語: 機能追加: ログインフォームにバリデーションを追加prefix を英語にしておけば、ツールとの互換性が保たれます。
-
コミットメッセージが長くなりすぎるのは良くないですか？
-
1行目（件名）は視認性のために短くあるべきですが、本文（3行目以降）は何行長くなっても問題ありません。むしろ、複雑なロジックの意図や「なぜこの方法を選んだのか」という背景は、しっかり書き残すべきです。数カ月後の自分やチームメイトにとって、それはコードそのものと同じくらい貴重な資料になります。
-
日本語で書くとき、文末は「です・ます」にすべきですか？
-
結論から言えばどちらでも構いませんが、「〜を修正」「〜を追加」といった体言止め（または言い切り）の方が、履歴一覧で見た時にスキャナブル（走査しやすい）でスッキリするため好まれる傾向にあります。
-
誤字脱字を見つけただけの小さな修正にもprefixは必要ですか？
-
はい、必要です。その場合は
docs:（コメントの修正など）やstyle:（コードの意味を変えない修正）を使いましょう。どんなに小さな変更でも、prefixがあるだけで「システム全体に影響がない変更だ」とレビュアーが安心して確認できるため、心理的な負担を減らせます。
-
merge コミットのメッセージはどう書けばいいですか?
-
A. 基本的にデフォルトのままでOKです。
GitHub の場合
Pull Request をマージすると自動生成:
Merge pull request #123 from feature/login-validation feat: add login validationこれで十分です。手動で変更する必要はありません。
squash merge の場合
複数コミットを1つにまとめる:
デフォルトでは全コミットメッセージが連結されますが、手動で要約に書き換えることを推奨:
# デフォルト(冗長): feat: add login validation * feat: add login form * fix: typo in validation * refactor: extract logic # 推奨(簡潔): feat: add login validation メールアドレスとパスワードの形式チェック機能を追加。 エラーメッセージは i18n で多言語対応。 Closes #123rebase merge の場合
各コミットが個別に main に追加されるため、事前に各コミットメッセージを整理しておく必要があります。
まとめ
Gitのコミットメッセージは、単なる作業の記録ではありません。チームメンバーや未来の自分に対する「思いやり」であり、あなたの技術力を証明する立派なアウトプットです。ルールを守った美しい履歴は、レビューをスムーズにし、トラブル時の解決速度を劇的に高めてくれます。
最後に、これだけは今日から実践してほしいエッセンスを「重要ポイント」としてまとめました。
最初は「どのprefixを使えばいいんだろう？」と迷うかもしれません。そんな時は、この記事の比較表をカンニングペーパー代わりにして、まずは形から入ってみてください。
ルールに従って書くことが習慣になれば、先輩エンジニアから「君のコミットは意図が明確で、安心してマージできるよ」と信頼される日が必ずやってきます。その積み重ねが、あなたのエンジニアとしての市場価値を、一歩ずつ、確実に高めていくはずです。
さあ、次のコミットからプロの基準（現場基準）を取り入れて、チーム開発をより快適に進めていきましょう！
あわせて読みたい
