git のブランチ命名とコミットメッセージのルール

所属企業で代々引き継がれている(と思う) git のブランチ命名とコミットメッセージのルールを汎用化してみた。

ブランチ

形式：<type>-<scope>/<task-number>-<name>

具体例

scope を使用する場合

• feat-ui/ABC-123-add-nice-feature

scope を使用しない場合

• fix/ABC-123-fix-bad-bug
• refactor/ABC-123-remove-chaos

type

type	説明
feat	新しい機能追加
fix	バグの修正等
refactor	リファクタリング

scope

モノレポやチームによっては何か定義してもいいかも。不要な場合もある。

task-number

JIRA だと ABC-123 とか。チケットの運用方法（チケットがどこからも参照されない、本文の情報量が少ない等）によっては不要な場合もある。

name

何をするブランチなのかが分かる文言を書く。add-nice-feature とか。

コミットメッセージ

形式：<type>(<scope>): <task-number> message

具体例

scope を使用する場合

• feat(ui): ABC-123 X の機能を実装

scope を使用しない場合

• docs: ABC-123 README の記述が古くなっていたので変更

type

type	説明
feat	新しい機能追加
fix	バグの修正等
refactor	リファクタリング
docs	ドキュメント
package	npm パッケージ関連
test	テストコード関連

バグ修正と同時にリファクタにもなってるとか、機能実装と同時にテストコードを書いている場合はどうするんだとか色々例外ケースはありそうだが、まあ雑にどれかを選んでおけば十分じゃないかなと思う。

scope, task-numer

ブランチと同様

message

何をしたコミットなのかが分かる文言を書く。多分（日本語話者のチームでは）日本語で書く人が多い。

そんなにコミットメッセージって大事？

自分は大事な場合”も”あると考えている。自分の経験でいうと実際に、リリースから 5~10 年ぐらい経過しているプロダクトの運用保守をしたときには blame で行単位のコミットメッセージを読むと調査の役に立つことが多かった。

if 文の分岐 1行だけでも、長期間運用されていると様々な理由で変更される。最初のリリースからの不具合の修正、仕様変更、別の機能追加に伴う改修など...

なぜそのコミットが行われているのか、関連するチケットや PR は何なのか、改修した際にどういう検証をしたのか等が分かるのは本当に助かった。

どちらかというとコミットメッセージ自体というかチケットや PR に情報が集約されている前提で、そこにコミットメッセージからアクセスできると、（長期間の運用保守が想定されるプロダクトなら）嬉しいね、ということかもしれない。

なので、 1 年続くか不明なプロダクトならコミットメッセージやチケット上の情報整理にあまり時間を費やさない方が賢い選択かもとは思う。