今回は、Gitをチームで運用していく際におざなりにされがちなことについて書いています。一週間前におざなりにして注意を受けたので備忘録的にまとめておきます。できなくても問題なくてもできたほうが後々助かるよね～そんなお話です。簡単に言うとコミットメッセージはルールを決めてちゃんと書こうねってことです。
どもども！最近の睡眠事情が終焉に向かっている龍ちゃんです。もともと三か月に一度のペースで睡眠障害チックなことは起きていたのですが、最近なくて油断していましたね。おそらく心と体のバランスが取れていないことが原因だと思います。少し問題ですね…お休みするかはこのブログを書いてから考えましょう。
さて、今回は「Git」にまつわるお話です。もっと踏み込んで「Git：コミットメッセージ」にまつわるお話です。余談というかこのブログの走りの部分ですが、先週ちょっとした苦言を呈されてしまいました。まぁ10:0で僕が悪くて弁護士を呼んでも勝てない状態だったわけですが、その時の勢いでブログを書いているので読んでみてください。
簡単に言うとテキトーコミットメッセージ・PR撲滅委員会を立ち上げようって話です。それについて上司とSlackで空中戦を通して一つ形になりました。今の僕みたいなミスをして、上司に怒られないように気を付けようね★ってことです。今回のブログを最後まで読んでわかることです。
- Gitのコミットメッセージテンプレート：サンプル付き
- Git上でコミットメッセージテンプレートを適応する方法
- コミットメッセージのガイドライン：上司からの金言コピペ
以上三部作となっています。さくっと五分程度で読めて、三分ぐらいで適応できるので今すぐやりましょうね～。というかテンプレこぴってコマンド一行打てば終わりっす。ほな！本題に入っていきます。
Git：コミットメッセージテンプレート
まぁ駄文を読むより結論よこせって感じですよね。というわけで僕と上司がSlackで3スクロールぐらいやり取りして作ったコミットメッセージテンプレートを張りますね。まぁ主に僕が叱られて噛みついているだけなんですけどね～
# ==== Commit Messages ====
# ==== Commit Messages(Template) ====
# Tag: [#issue number] message
# 【sample】
# feature: トップ画面とサービス画面に共通する【契約プランミニ表示コンポーネント】を作成した
# fix: #123 利用規約文言の誤字を修正した
# ==== Notice ====
# why を意識して過去形で書くのがよい
# issue がちゃんとある場合は楽だけどない場合が多いから、その辺はうまいことする
# ==== Tag ====
# feature:機能追加・更新
# refactor:リファクタリング・コードスタイル・コードフォーマット修正など
# fix:バグ修正コミットメッセージを三つのパートで構成するという方法です。Tag・Issue number・messageの三段階構成です。Tagには三つしか用意していません。上司曰く「いっぱいあってもどれつけるか考えるのが時間の無駄だし、そんな小さな変更点でタイプするのも時間の無駄」とのことです。ちなみに脚色付きなので、めちゃんこ荒く書いていますが本当は海のような優しい言葉で言われてます。三つぐらいの分類だったらさくっと分けることができるからいいですよね。
メッセージを書く際に気を付けたほうが良いことはNoticeにまとめています。「Whyを意識して過去形で書くのが良い」というのはもはや金言だと思っています。要約すると以下の言葉にまとまります。
もう脳内再生余裕ですね。どんな変更が加わったかを書きたくなる気持ちすごくわかります。そんなんだからちゃんと書くと「Change：yarn3系に対応させるためにyarnのupdateコマンドを実行するテストVer.1」だったはずなのに「Change: yaml file」なんてくそコミットをぶち込んだりするんですよね。ちなみに叱られる前に「お騒がせしましたリバートします」なんてお気持ち表明コミットぶち込んでましたね。皆さんもクソコミットメッセージには気を付けましょう。
あとテンプレート作るときには、ちゃんと書き方の例を用意しましょう。これも注意されました。テンプレートの意味ってほかの人が使えるようにするためだから、初めて読んだ人がちゃんとおんなじ表記で書けるようにしないといけないです。なので、親切に二つぐらいは例を置いておきましょう。
Git上でコミットメッセージテンプレートを適応する方法
まずは上のファイルを適当なところに保存しときましょう。ちなみにもし脳死で作業したい人がいた時のためにコピペで動くコマンド用意しておきます。
cd ~
touch .commit_template #このファイルに先ほどのテンプレートをぶち込む
git config --global commit.template ~/.commit_templateこれでオッケーです。あとは普通にコミットするときにオプションを付けなければ登録しているエディタが起動します。
git commit標準のエディタだった場合は、たぶんvimが動きます。使い方を覚えましょう。もしvimアンチがいた時のためにコミットメッセージをVSCode出かけるようにするためのコマンド置いときます。
git config --global core.editor 'code --wait'
正確に打ち込むかコピペしてくださいね。ちなみにAtomで設定したい場合のために参考にしたリンク置いときます。
コミットメッセージのガイドライン：上司からの金言コピペ
もう戦っていたというより圧倒されていたのですが、コミットメッセージのテンプレートを作ろうと心に決めた上司からのSlackをそのまま張っちゃいますね。
＜コミットメッセージのガイド＞
- なぜ変更したかがわかる内容を記載する (whatではなく、whyを記す)
- 変更内容はgitの差分でわかるので、変更の意図を記す。わかりづらい変更は補足追記 (本来わかりづらい変更をしないことが前提ですが、それでも開発中は二転三転して結果わかりづらい差分になることはあるので、その場合は補足)
- 関連情報へのリンクを記す
- タスクの元になったチケット (実装タスクのチケット、バグ修正時のバグチケット。ただし、社内メンバーしか見れない場合は記載せず、対応するのがあるなら公開タスクのチケットID)
- ライブラリなど外部依存のバグ、あるいは特殊な仕様で修正をした場合は情報ソースへのURL (公式情報が原則。どうしても公式にない場合は個人ブログなどでも可) を残す
- PJによってプレフィクスで機能追加、バグ修正、リファクタリング、コードスタイルレベルの修正などが一目でわかるようにするのもオススメ
- 機能: / 修正: / リファクタリング: / スタイル:
この域に達することができるように頑張るしかないですよね。もう心持的には無理ぽよって感じです。絶賛、精神と体のバランス崩しているので前向きな気持ちになれないです。でも文章でもらえるのは最高です。だって元気になって見返すことができますもの。
というか上司との技術的な会話や同僚との会話で生まれた内容はすべてブログに書く必要があると思っています。さすがに取引先の情報を公開することはできませんけど、それだけ個人で学ぶのと会社で学ぶのには差がありますね。こんなことならもう二年早く就職しとくべきでしたね。きっとその時には入れなかったと思いますけどね。
おわりに
さて～皆さん今日もコミットメッセージ書いてますか？今日はくそコミットを出していた僕がテンプレートを作って自分を矯正しようと頑張る決意表明みたいなものです。ノリノリで作業しているときはくそコミット出しがちですよね。くそコミット出そうとしたら怒ってくれるソフトないかなとか思っています。さて、ここまで三十分で書き上げてしまいました。今日は体調があまりよくないので文章が荒れていますね。たまには違うノリでブログを書くことも面白い取り組みだと思って暖かい目で見守ってください。
それでは～参考資料を置いておきますね。
うちのコミットメッセージが一番入門しやすいと思います。Tagは必要だとわかるようになってから増やします。今回のはどちらかというとフロントエンド用のコミットメッセージかもしれないですね。その辺はコミットの粒度とプロジェクトの進み具合で調整してね。
しれっと同僚の記事を共有しておきます。ServiceBus TriggerのAzure Functionsをローカルで認証して実行する方法【Cross Tenant】
んじゃまたね～
