Gitでは、変更をcommitとして記録します。しかし、何でもまとめてcommitすればよいわけではありません。良いcommitは、あとから読んだ人が変更理由を理解しやすい単位です。
一言でいうと
良いコミットは、「1つの目的」にまとまっていて、あとから変更理由を追える記録です。
良いコミットの条件
| 条件 | 説明 |
|---|---|
| 目的が1つ | 機能追加と無関係な整形を混ぜない |
| 差分が読める | レビューしやすい大きさ |
| メッセージが具体的 | 何をしたかがわかる |
| 戻しやすい | 問題があればそのcommitを取り消せる |
悪いコミットの例
update
fix
いろいろ変更
作業
これでは、あとから履歴を見ても何をしたかわかりません。
差分も、機能追加、バグ修正、フォーマット、README更新が全部混ざっていると読みにくくなります。
良いメッセージの例
feat: add login form
fix: handle empty search keyword
docs: update setup instructions
test: add user service tests
英語でも日本語でも構いませんが、目的がわかるようにします。
fix: 空の検索キーワードで全件表示される問題を修正
粒度の考え方
良い粒度は、次の問いで確認できます。
- このcommitだけで説明できるか
- このcommitだけを戻しても意味があるか
- レビューする人が数分で読めるか
- テストや確認方法を説明できるか
commitは作業時間の区切りではなく、意味の区切りで作ります。
分けた方がよい例
次の変更は、分けた方が読みやすいです。
| 変更 | 分ける理由 |
|---|---|
| ログイン機能追加 | 機能として大きい |
| README修正 | 実装とは別目的 |
| フォーマット変更 | 差分が大きくなりやすい |
| テスト追加 | 実装と対応関係を見やすくする |
よくある誤解
| 誤解 | 実際 |
|---|---|
| commitは最後に1回でよい | 履歴が読みにくくなります |
| 細かければ細かいほどよい | 意味のない小分けは逆に読みにくいです |
| メッセージは適当でよい | 後から調査するときに困ります |
| 動けば何でもよい | レビューと保守も重要です |
まとめ
良いcommitは、1つの目的にまとまり、差分が読めて、変更理由がわかる記録です。作業時間ではなく意味の区切りでcommitを作ります。大きな変更、README、フォーマット、テストは、必要に応じて分けると履歴が読みやすくなります。