良いコミットメッセージ - ntuf/Tips GitHub Wiki

5Wがわかれば良い

すでにわかっていること◯

◯ いつ（When）：タイムスタンプでわかる
◯ どこで（Where）：ファイル名とディレクトリ、diffで修正箇所がわかる
◯ 誰が（Who）：author（作者）でわかる
× 何を（What）：コミットのタイトル（Subject）と本文（Body）に必要
× なぜ（Why）：コミットの本文（Body）に必要
◯ どうやって（How）：コードやdiffでわかる

何を（What）、なぜ（Why）だけをコミットメッセージに書く。
仕様が分かるように書いた方がいいかも

コードの変更 仕様の変更
いつ ○ -
どこで ○ -
誰が ○ -
何を ○ -
なぜ ✖️
どうやって ○

コミットメッセージタイトル

接頭辞(?)

英語 用途
Fix: バグ修正
Improve: リファクタリング、パフォーマンス改善
Update: 仕様変更
この３種だけでいいのでは？
日本語の使用は、解釈のブレを生む。(修正、更新、改善、改修)
「追加」「削除」「改名」「移動」「交換」は差分見れば分かる

コミットメッセージ本文

  • 変更前

  • 変更後

    • どういう動きをどうなるよう変更したのか

  • 理由

    • なぜそうしたのか（修正の背景）
      • 仕様変更の起因(○○が面倒、○○がよいという顧客要望)
      • バグ：障害が発生したのか、自分で見つけたのかなど
      • リファクタリング（保守性向上の為）
      • パフォーマンス改善
      • セキュリティ向上

上のコミットメッセージは1案件1コミットを想定している。
一つの改修案件を数日かけてやって、
その日のできたところまでコミットするから、
1コミット1案件とは限らない場合がある。

cf.障害票

  • 発覚した日時
  • 事象
  • 原因
  • 対応方法
    • 暫定
    • 恒久
  • 復旧予定日時
    • 暫定
    • 恒久





（以下、削除）

英語 日本語 用途
Add: 追加: 機能の追加
Fix: 修正: 機能の修正、バグを正す
Improve: 改善: リファクタリング(clean?)、パフォーマンスチューニング
Update: 更新: 仕様変更に伴う機能の改修
Remove: 削除: 機能の削除
Rename: 改名: ファイルの改名
Move: 移動: ファイルの移動
Change: 交換:

主語は「機能」。
ソースコード行、ファイル、分岐条件、パラメタ等が主語ではない。
改善だけはプログラムの改善(リファクタリング)と機能の改善()

■不確定

  • 「修正」と「改善」と「更新」の使い分けは？
    修正：間違いを正す
    改善：間違ってないけど、さらに良くする
    更新：仕様の変更によって更新する

  • プログラムを「追加」すると機能の「改善」にもなるならどっちを使う？

    • 主語が機能。機能の追加、改善なので意味の重複はない。

  • リファクタリングは「プログラム」の改善でパフォーマンス改善は「機能」の改善ではないか？

    • その通り。改善だけは例外。

  • 「交換」の使いどころは？

    • 今はまだない。削除予定。

  • 無駄なソースファイル削除や、意味のないコードを削除するのは「削除」ではなくて「改善」

  • 機能の「追加」「修正」「改善」が「更新（アップグレード）」にもなるのでは？　

    • 「更新」は仕様変更に伴う改修だけを指す。
    • アップグレードは「更新」の意味に含まれない。
    • アップグレードはプロジェクト全体が主語になるから。

  • 仕様変更に伴って、機能を「更新」したが機能が名前にそぐわなくなり「改名」するが、これは「更新」か「改名」か

    • 機能名の場合「更新」
    • ファイル名の場合は「改名」
      • 中身が一緒なのに一方はファイルが削除され、一方はファイルが出現し、バージョン管理システム上追えなくなるから。
⚠️ **GitHub.com Fallback** ⚠️