🐣

Git習熟度が低いチームでのコミットメッセージ運用

2020/11/03に公開2件

Gitの習熟度が低いチームで運用しているGitコミットの運用スタイル。
Gitのコミットメッセージの書き方に関する記事は山程あるので、単に私がこうしてますよ、という記事。

コミットメッセージ

<type> <subject>

<body>

1行目はコミットログに表示される部分。コミットの概要を短く書く。
2行目は空行にすること。
3行目移行は必要に応じてコミットの詳細を書く。

type

コミットが何をしているかを示す動詞。
1単語で「コレをしています」と明記することでコミット単位に意味をもたせる狙いもある。
私のチームでは以下の一覧を提示しているが必ずしも従わなくてもよい。意図の明示が目的。

add : ファイルや機能の追加
update : ファイルの更新、機能修正
fix : バグなど機能に関係しない修正
delete : ファイルや機能の削除

コミットメッセージを日本語で書く場合でも先頭にtypeをつけるとよい。
日本語だと動詞が先頭に来ないので全文読まないとコミットで何をしているか分からない。また表現が曖昧になりやすいので簡潔な英単語で縛るとよい。

参考

Angularのドキュメントではtypeとして使っていいキーワードを定義しているらしい。
作業途中でのコミットの場合、先頭や末尾に[WIP]をつけるという例もあった。

subject

コミットで何をしているかを示す極短い一文。
GitHubやGitLabで表示した際に70文字程度までしか1行に表示されない。
先頭にtypeを書く事を考えるとsubject部は60文字程度が限度。

subjectが50文字では収まらないという場合、そもそも1コミットに多くの変更を含めすぎていないか再検討したほうがよい。

body

コミットの詳細。チケット番号をbodyに書く場合もある。
HowではなくWhyとWhatを書く。なんの目的で何をどのように変更したのか。

コミットの粒度・頻度

「意味のある単位で細かくコミットしよう」という程度の方針。
1案件まるごと1コミットみたいなことはやめてほしいとは言っているが、具体的な指針はない。

ある程度小さなコミットが積み重なっている方が作業的にもレビュー的にも役立つので、自ずと各自の粒度・頻度が定まるだろうと思っている。
将来的にはペアプロやモブプロを取り入れたいと思っており、その際に交代のためだけにコミット&プッシュすることも想定しているので、コミットの粒度や頻度については特に縛っていない。

日本語について

Gitの作法について調べるとコミットメッセージなどは基本的に「英語で書くべし」とされているが、個人的には職場が日本語Onlyなら日本語でいいと思っている。
Gitの導入や運用改善の前に英語が障害になるくらいならまずは日本語で進めて、Git自体に慣れたあとで必要に応じて英語に変えていけばいい。

とはいえ、以下の理由からプログラミンミングに英語を必要と感じていない状況は危険、という記事もあった。
外部公開はともかく、語彙力とかCLIで扱いにくいとか諸々の理由で英語の方が好ましいということ自体は同意。

社外秘なものでなくともコードを外部に公開する気が全くない
日本語話者以外の人材（採用、オフショアなど）に対応していない
コーディング中の命名を改善するにも英語の語彙は必要

参考サイト

書き方・マナー

例文集

Discussion

catnose

個人的にはVue.jsのコミットの慣習もおすすめです。

僕はちょっとしたREADMEの編集とかには（type の部分で）choreを使っていたりします。実際のアプリの挙動とは直接関係のない部分にfixを使わなくて済むので便利です。

y_megane

Vue.jsの規約、Angularの規約をベースにしてるんですね。知らなかったです。ありがとうございます！
機能に影響するもの(feat,fix,perf)とその他で分かれてるの、コミットメッセージ書くときに悩まずに済みそうでいいですね。