コミットメッセージ

概要#

コミットには「いつ誰が何をしたか」が記録されますが、それらを要約するメッセージはコミッターがつけます。コミットメッセージはGitHubなどで複数人で参照するため、分かりやすい内容にしましょう。たとえば

• 修正
• 修正
• 修正
• 修正

のようなコミットメッセージが並んでいた場合、あとでバグの原因を探すときに原因のコミットを探しにくくなります。逆に以下のようなコミットメッセージだった場合、たとえばLPのバナーでバグがあったときに、どのコミットに原因があるのか探しやすくなります。

• ボタン修正
• main.js修正
• お気に入り機能追加
• LPにバナー追加

コミットメッセージはチームによってルールや文化がありますが、ここではGoogleが提唱し、Angularチームが採用するメッセージルールをご紹介します。

メジャーなコミットメッセージ#

作業タイプ(作業範囲): 作業内容 #関連するIssue番号

上記フォーマットに沿ってコミットメッセージを書きます。たとえばトップページにバナーを追加した場合、

feat(top): バナー追加 #3

となります。このルールにより、「どこ」に対して「なんの」作業をしたのかが一目で分かります。Issue番号はIssueページURLの末尾や、Issue一覧ページで確認することができます。

タイプ一覧#

タイプ	意味
build	ビルドシステムまたは外部の依存関係に影響する変更（スコープの例：gulp、broccoli、npm）
ci	CI構成ファイルとスクリプトへの変更（スコープの例：Circle、BrowserStack、SauceLabs）
docs	ドキュメント関係（スコープの例：README）
feat	新しい機能やページの追加
fix	バグ修正
perf	パフォーマンスを向上させるコード変更
refactor	バグを修正も機能も追加していないコードの変更（例：divをpタグに変更）
style	コードの意味に影響しない変更（空白、書式設定、セミコロンの欠落など）
test	不足しているテストの追加または既存のテストの修正

関連するIssue番号とは#

GitHubやGitLabなどのメジャーなリポジトリ管理サービスでは、機能追加やバグ修正に対しIssueというチケットのようなものを作成して管理します。コミットメッセージにIssue番号を＃を添えて追加することで、コミットログ一覧から関連するIssueにリンクが貼られ、「このコミットはどのIssueに関するものか」が追いやすくなります。

間違ったコミットメッセージをつけてしまった場合#

ターミナル
git commit -a --amend

と入力することでvimエディターが立ち上がります。テキストを編集してctrl + zzで保存するとコミットメッセージが修正されます。修正前のメッセージでプッシュしていた場合、--amendでメッセージを修正したあとプッシュしようとしたらエラーが表示されます。その場合以下のコマンドで強制Pushしてください。

ターミナル
git push -f

強制プッシュは原則使わない#

強制プッシュをするとリモートのバージョンを無視して自分のバージョンを最新としてリモートのブランチを更新します。他の人の作業があった場合、それが自分の作業で上書きされてしまいます。このため生命線となるmasterブランチはリポジトリ管理者によって保護され、強制プッシュができなくなっているケースがほとんどです。

保護がないケースにおいても強制プッシュはよほどのことがないと行わないようにしてください。ちょっとしたコミットメッセージのミスぐらいであれば無理して直す必要はありません。