こぴぺったり

gitコミットメッセージのテンプレート10選 ― そのまま使える実例とポイント

feat / fix / refactor などのプレフィックスを使った実用的なgitコミットメッセージのテンプレート集。Conventional Commits準拠のフォーマットでコピペできます。

夜中にコミットしようとして「とりあえず update」と打ってしまう日、誰しもあると思います（- -;

ただこれ、自分用ならまだしもチーム開発だと半年後の自分も読めない地雷コミットになるんですよね。

そこで型として使われているのが Conventional Commits（type(scope): subject 形式）。
これに沿って書いておくと、git log --oneline を眺めるのも changelog を自動生成するのも一気にラクになります。

以下のテンプレは全部、1行目を50文字以内に収めるように設計済み。
詳しい本文を足したいときは、空行を1行はさんでから書いてください！

1. 新機能の追加（feat）

用途: 機能追加・新規エンドポイント・新画面など、ユーザーに見える価値の追加

feat(auth): add password reset flow

scope には変更したモジュール名を入れます（auth / api / ui など）。

本文に「なぜ」を書いておくと、半年後の自分を助けられるのでおすすめです（^^b

2. バグ修正（fix）

用途: 不具合・期待と違う挙動を直したとき

fix(cart): prevent quantity from going below 1

バグの「現象」じゃなくて 「修正後の挙動」 を主語にすると読みやすくなります。

fix: cart bug よりは fix(cart): prevent ... の方が、ログだけ見て中身が想像つくんですよね。
過去に fix: bug だけで commit したコミットがあって、半年後に原因調査で読み返したとき「何のバグだっけ…」と diff を全部追う羽目になったことがあります。あの30分は本当に無駄だった…。

3. 内部実装の整理（refactor）

用途: 挙動を変えずに可読性や保守性を改善したとき

refactor(parser): extract token validator into separate module

refactor は 外部挙動を変えないことが条件です。

挙動が変わっちゃってる場合は feat か fix を使う方がベター。リファクタと一緒にバグ修正をやると、後から差分が追えなくなるので分けておくのがコツです（^^;

4. ドキュメント更新（docs）

用途: README、コメント、APIリファレンスなどの更新

docs(readme): add troubleshooting section for windows users

コードに変更がなく、文書だけの場合に使います。

コードコメントの更新も docs 扱いにするチームが多いので、迷ったら docs で大体OKです！

5. テスト追加・修正（test）

用途: 既存コードの挙動に対するテスト追加や既存テストの修正

test(payment): cover refund timeout edge case

落ちてたテストを直すなら fix、新しいテストの追加なら test、と使い分けるのが慣習です。

「テスト＝品質保証」じゃなくて「テスト＝仕様の記述」と捉えると、書きやすくなるかも（^^b

6. ビルド・依存・雑務（chore）

用途: 依存パッケージ更新、設定ファイル変更、CI調整など

chore(deps): bump vite from 5.4.10 to 5.4.12

依存パッケージ更新は chore(deps) か build(deps) が定番。

Dependabot が自動で吐くPRもこのフォーマットなので、自分で打つときもそろえておくとログがキレイになります！

7. パフォーマンス改善（perf）

用途: 速度・メモリ使用量の改善

perf(list): memoize row renderer to skip 80% of re-renders

数値で効果が書けると、後で見返したときに「あ、これは効いたやつだ」って一瞬で思い出せます。

地味だけど、こういう一手間が後々効いてくるんですよね（^^b

8. コードスタイル調整（style）

用途: フォーマッタ実行、インデント整形、空行調整など挙動に影響しない見た目の修正

style: run prettier on src/

prettier や eslint --fix の結果コミットによく使います。

コードの動作には影響しないのが原則なので、ロジック変更を紛れ込ませないように気をつけましょう（- -;

9. コミットの取り消し（revert）

用途: 過去のコミットを取り消す `git revert` を実行したとき

revert: "feat(auth): add password reset flow"

This reverts commit 1a2b3c4d5e6f.
Reason: causes infinite redirect on safari.

自動生成されるrevertメッセージのままでもOKですが、Reason: 行を1つ足すと未来の自分を助けられます。

「なぜrevertしたか」が残ってないと、また同じ機能を実装しちゃうリスクがあるので…（^^;

10. 詳しい本文を伴うコミット

用途: 背景や決定理由を残したい大きめの変更

feat(billing): switch invoice numbering to per-year sequence

The previous global counter caused gaps when invoices were
voided across fiscal years, making audits painful. Per-year
sequences (2026-0001, 2026-0002...) keep numbering monotonic
within each year and reset cleanly on Jan 1.

Closes #482

フォーマットは下記の3段構成が基本形です。

  • 1行目：50文字以内のサマリ
  • 空行
  • 本文：1行72文字目安
  • 空行
  • フッタ：Closes #... などのチケット連携

これに従っておけば、git log --oneline も gh pr view もキレイに見えます（^^b

関連する例文集