コミットメッセージは、未来の自分やチームのメンバーへの「手紙」です。
git log を見たときに、何を・なぜ変更したのか がすぐに分かるように書きましょう。
空の内容のタスクを追加できないようにする ← 1 行目: 要約（何をしたか）
todo.sh add "" を実行すると、内容が空のタスクが ← 3 行目以降: 本文（なぜ・どのように）
追加されていた。空白以外の文字を含まない内容は
エラーにする。
Refs #1 ← 関連する Issue
- 1 行目（要約）: 変更内容を簡潔に書きます。日本語なら 30〜40 文字程度、英語なら 50 文字程度が目安です。末尾に句点（。）は付けません。
- 2 行目: 空行にします。
- 3 行目以降（本文）: 必要に応じて、変更の理由や背景、注意点を書きます。小さな変更なら省略して構いません。
git commit -m "..." では 1 行目だけを書けます。本文も書きたいときは、-m を付けずに git commit を実行してエディタで書くか、-m を 2 回使います。
git commit -m "空の内容のタスクを追加できないようにする" -m "todo.sh add \"\" で空のタスクが追加されていたため。"| 悪い例 | 理由 | 良い例 |
|---|---|---|
修正 |
何を修正したのか分からない | done コマンドで存在しない番号を指定したときのエラーを修正 |
update |
同上 | README に delete コマンドの使い方を追加 |
いろいろ変更 |
複数の目的の変更が混ざっている | 目的ごとにコミットを分ける |
バグ修正しました。テストも追加しました。あとタイポも直しました。 |
長すぎる・混ざっている | 空の内容のタスクを追加できないようにする と README の誤字を修正 に分ける |
変更の種類を先頭に付けると、git log で変更の種類が一目で分かります。
Conventional Commits という書き方が広く使われています。
| 接頭辞 | 用途 | 例 |
|---|---|---|
feat: |
新しい機能 | feat: タスクを削除する delete コマンドを追加 |
fix: |
バグの修正 | fix: 空の内容のタスクを追加できないようにする |
docs: |
ドキュメントのみの変更 | docs: README に使い方を追記 |
test: |
テストの追加・修正 | test: done コマンドのテストを追加 |
refactor: |
動作を変えないコードの整理 | refactor: 番号のチェックを関数にまとめる |
chore: |
設定やツールなど、その他の変更 | chore: CI の設定を更新 |
接頭辞を使うかどうかは、チームのルールに従います。この教材のリポジトリでは使っています（CONTRIBUTING.md 参照）。
コミットメッセージや Pull Request の本文に #番号 を書くと、GitHub 上で Issue へのリンクになり、Issue の画面にもそのコミットが表示されます。
| 書き方 | 効果 |
|---|---|
Refs #1 |
Issue #1 に関連付ける（Issue は閉じない） |
Closes #1 / Fixes #1 / Resolves #1 |
main（デフォルトブランチ）に取り込まれたときに Issue #1 を自動で閉じる |
Issue を自動で閉じるキーワードは、コミットメッセージよりも Pull Request の本文 に書くのが一般的です。
- 1 つのコミットには 1 つの目的 だけを含める
- 後から 1 つのコミットだけを取り消せる 単位が理想
- 「機能の追加」と「無関係な文言の修正」は分ける
- テストが通らない中途半端な状態は、なるべくコミットしない（作業ブランチ上で、途中経過を保存するためのコミットは問題ありません）