一貫したコミットメッセージを書く
クリーンなコミット履歴は、コードレビュー、bisect、チェンジログ生成を劇的に楽にします。OpenCode はステージ済みの差分を読み、チームの規約に従ったメッセージを生成します。
このレシピを使う場面
- 機能を完了し、無関係な変更がまとめてステージされている。
- チームに手動で守るには煩雑なコミットメッセージ規約がある。
- 後でも bisect や revert できるクリーンな履歴が欲しい。
前提条件
- リポジトリに OpenCode がインストールされている。
.gitmessageテンプレートまたはチーム規約(Conventional Commits、カスタムプレフィックスなど)。- ワーキングツリーに変更が用意されている。
手順
-
ステージ内容を確認する
ステージングエリアがコミットしたい内容を反映していることを確認します。
git status git diff --cached --stat -
メッセージの提案を依頼する
差分を OpenCode に渡し、Conventional Commit メッセージを依頼します。
ステージ済みの差分を読み、Conventional Commit メッセージを提案してください。フォーマットは
type(scope): subjectを使用してください。サブジェクトは命令形、72 文字以内。ボディは what ではなく why を説明してください。 -
必要に応じてアンステージして再グルーピングする
差分に複数の無関係な関心事が含まれている場合、論理的なコミットに分割するよう OpenCode に依頼します。
この差分にはバグ修正とリファクタリングが混在しています。2 つのコミットに分割する方法を提案してください。各コミットにどのファイルが属するか、それぞれのメッセージを教えてください。
-
各グループをコミットする
各グループを個別にステージし、OpenCode の提案メッセージを使ってコミットします。
git reset HEAD git add <files-for-first-commit> git commit -m "fix(parser): handle empty input without panic Previously an empty input caused a nil deref in the lexer. Added an early return and a unit test." -
履歴がきれいに読めるか確認する
直近の数コミットを見て、一貫したストーリーを語っているか確認します。
git log --oneline -10
重要なプロンプト
ステージ済みの差分を読み、Conventional Commit メッセージを提案してください。次にそれを眺め、分割すべき複数の無関係な関心事が含まれているか教えてください。含まれている場合は、各コミットにどのファイルが属するか列挙し、それぞれのメッセージを書いてください。
検証
git log --onelineがクリーンな物語として読める。- 各コミットが独立してビルドとテストを通る。
- メッセージがチームの規約に従っている(例:
type(scope): subject)。
よくある落とし穴
- 関心事を混ぜる: 「タイポ修正 + 新機能 + 再フォーマット」のコミットは安全に revert できません。常に先に再グルーピングしてください。
- 曖昧なサブジェクト: 「fix stuff」や「update code」は将来の自分に何も伝えないません。具体的なサブジェクトを常に要求してください。
- ボディのコンテキストを忘れる:
whyは差分から分かることは稀です。OpenCode に 1〜2 行のボディを書かせてください。
関連ドキュメント
関連レシピ
- refactor-codebase —
reason.git.to-refactor - bug-hunting —
reason.git.to-bug - project-scaffold —
reason.git.to-scaffold
関連ドキュメント
次のステップ
- refactor-codebase —
next.git.to-refactor