🐙
Git Commit ベストプラクティス: 独りよがりなコミットはやめる
チーム開発でこう思ったことはありませんか？
・このコードは何をしたいんだろう？
・このコメントは古くない？説明通りなことが書かれてないような
・このプルリクエスト大きいな、どこから始めよう？
・このバグはどこから来てるんだろう？
上記が当てはまるのであれば、プロジェクトのコミットルールを見直す時かもしれません。
よく考えられた良いコミットは、コードベースの明確さ・保守性の確保に役立ち、チーム開発の効率を高め、デバッグをより簡単にします。
また、他の開発者だけでなく未来の自分にとってもスピーディに理解しやすく意図を伝えてくれます。
ここから最低限チーム開発で取り入れるべき、
✨Git Commitベストプラクティス✨を紹介します。
1️⃣ コミットは小さく、1つの修正にフォーカス
- 目安は約5ファイル、100行以下
- 複数の修正が混ざっている時はコミットを分ける
- 変更箇所をシンプルにわかりやすく
例：
❌ BAD（複数の修正が混ざっている）
Refactor user login and correct typo
ユーザーログインのリファクタとタイポの修正
⭕️ GOOD（各修正が分けられている）
Refactor user login
ユーザーログインのリファクタ
Correct typo
タイポの修正
2️⃣ コミットメッセージは命令（現在）形で意図を記述
- 英数字で50文字以下、最初の文字は大文字（日本語は40文字以下）
- なぜその変更を与えるのか他の開発者にもわかるようなメッセージにする
- 命令形は ”changed” “changes” ではなく ”change”
（日本語は現在形で ”変更した” ではなく ”変更”/”変更する” ）
例：
❌ BAD（命令形ではなく内容も曖昧）
Updated code
コードのアップデートをした
Fixed bug
バグを修正した
⭕️ GOOD（命令形で内容が具体的）
Add error handling for database connection
データベースコネクションの為のエラーハンドリングを追加 / 追加する
Remove debug console.log statements
デバッグ用コンソールログを削除 / 削除する
3️⃣ 理由もなくコメントアウトしたコードはコミットしない
- どうしても含む場合は理由などを必ず記載しておく
4️⃣ 作業前のブランチは最新の状態にする
- 作業中変更があった場合もベースブランチから都度取り込む
- コンフリクト防止など自分の修正以外は含まない
5️⃣ オートフォーマッターを適用
- フォーマッターによる差分が含まれると、本来の修正箇所が見にくくなる
- 万が一フォーマッターによる差分を含む場合はコミットを分ける
- Prettier拡張を入れるだけでなくVSCodeの設定も必要
6️⃣ コミット前の影響範囲と動作チェック
- エラーが出てないか、デグレが起きていないか影響範囲は全て確認する
まとめ
コミット習慣を維持することで、現在のチームのみならず将来このプロジェクトを扱う開発者にも利益をもたらします。
これらのベストプラクティスを取り入れて、一人でも幸せな開発者が増えてくだされば幸いです。
Discussion