今回は、プロジェクトを進めていくうえで注意されたことについて悲しみながらまとめていきたいと思います。しっかりとSlackで3スクロールの文量ぐらいやり取りをしていましたね。注意された経緯を簡単にまとめつつ悪かった点の反省会をしていこうと思います。
どもども最近注意されることに喜びを感じている二年目の龍ちゃんです。今日は『中途二年目』じゃないの？と確認されました。ちょっとうれしかったです。大学院時代の二年間が会社だったととらえると確かに中途入社かもしれません。でも技術的には素人に毛が生えた程度なので、どうせなら技術で間違われるぐらいのスキルを身に着けていきたいものです。
それでは、さくっと本題に入っていこうと思います。今回は『Gitの運用で注意された話』について書いていきたいと思います。運用といっても一人の開発者目線でのお話です。なので「branchの切り方」「commitメッセージ」「PRの書き方」などの話について書いていこうと思います。悪かった点の振り返りを書いていきたいと思います。
ちなみにですが、反省してコミットメッセージのテンプレート化を行いました。ブログにまとめてます。
それでは入っていこうと思います。
branchの切り方
まずは何も言わずに以下の図を見てください。これは僕が注意されたときにやっていたbranchの切り方です。
これは怒られますね。だって「branch」の切っている意味がないですもの。いや～作っているときの僕は意味があると思ってたのです。Slackが飛んできて、レビュワーからしたら地獄という説明を受けました。
上の図が地獄な点については「feature/C」を見ればわかります。このブランチには「A・B」の両方のコミットが反映されています。僕はこれを一日の内に8件ほどのPRを発行して怒られました。最後に作ったPRさえマージをすればよいのに8件に分割して「A～H」までのブランチを発行して送付したわけです。しかもそのPRを発行しつつ、別件の作業で「develop」ブランチに変更を加えていたのでコンフリクトを発生しまくりだったわけです。そりゃ上司から注意のSlackが飛んできますよね。そのまま原文を張ります。
ブランチの切り方が悩ましくなっています。developからfeature Aブランチ、feature Aからfeature Bブランチというブランチの切り方をされているので、派生元ブランチに手が入った場合に各ブランチに取り込む必要が生じてしまうのと、各PRでの差分にノイズ（他のブランチ由来の差分）が入ってくるのでわかりづらいというデメリットが生じます。 PJとしてブランチ運用は、Github flowベースで行こうという話だったので、今後はdevelopから派生をお願いします。
これは完全に僕が悪いですね。だってGithub Flowベースで運用していくと決まっているんですもん。それなのにガン無視して「branch」を切りまくっていたのです。これは10:0で僕が悪いですね。今後はきちんとルールを守っていきたいと思います。
コミットメッセージ
次に注意されたのが、「コミットメッセージ」になります。これは、ルールが決まってなかったのですが「お気持ち表明」のようなコミットを出していたので注意されました。原文を以下に張っておきます。
今後の話として、コミットメッセージを書けるように改善をしていきましょう。全体的に意味のないコミットメッセージになってしまっています。例えば、
Change fileどのファイルを変更したかはgitが管理しているので、どのファイルを変更したかというコミットメッセージは相手に伝える情報がないものです。タイプする秒数が勿体ないです。
Change yarn v1見ればわかることをコミットメッセージに書く必要はなく、大事なことはなぜ変更したのかです。
お騒がせしたのでリãリバーとでいったんリセット主語がなく、何のことを言っているのか第三者にはわからないです。今いる人は「あれのことかな？」と推し量ることができたとしても取引先や将来保守する人にとっては全く意味不明です。
これはCI/CDを組んでた際に荒れたコミットメッセージを出し続けていたので見つかってしまいました。この時は心が荒れていたので雑なコミットメッセージになっていたことを反省しています。コミットメッセージについては、世間でも「ちゃんと書け！」との声を見ています。そんな声を頭の隅っこに追いやってコミットメッセージを乗りで書いているとよくないとのことで、コミットメッセージのルールが必要であると感じました。この時言われた内容としては「WhatではなくWhyを書く」でした。何をしたかは、Gitの機能でわかるからなぜこの変更をしなければいけなかったという点に注目して伝える必要があるとのことです。この言葉は金言です。
やはりルールを定めないと自由に書いてしまうので、最初にルールを作成するべきでした。そんなコミットルールについては今後のブログのネタにしていこうと思います。対応としては「コミットメッセージテンプレートの作成」になります。
テンプレートについてはブログにもまとめてますし、参考にしたサイトも置いておきます。
PRの書き方
これは「コミットメッセージ」とも関係しているのですが、上司に「PRの書き方をちょっと勉強しようか」とさらっと言われたことがあったので書いています。基本的に「コミットメッセージ」とおんなじ感じで「何を書くかルールを定めずに自由に書いた」ということが起因しています。自由に書いていた時代のPRが以下になります。
local開発用のAzureAD設定
Description：local開発用のAzureAD設定/AzureAD側でファイルごと切り分けました抽象度が高すぎて何をしたPRなのかわからないというのが上司に言われたことです。これは対処法がわからなかったのですが、一緒に働いている先輩社員のPRを見て修正することにしました。結果として、「PRのテンプレート化」を行いました。持つべきものは先輩社員だなぁ～と思います。これについても別のブログか「コミットメッセージ」のブログでまとめて書く予定です。
悪かった点
それでは悪かった点についてまとめていきます。
以上がざっくりとまとめた内容になります。まぁ要するに人に見せるための資料であることを意識を持とうということと、ルールは早めにということです。
ちなみにブランチの切り方は、レビューの速度やプロジェクトの進み方で動的に変わるようです。これはレビュワーと相談して適切な粒度に分解していく必要があります。
少なくともこうやって指摘をもらえることはとてもうれしいことですね。今後の経験として心に刻んでいきましょう。
まとめ
今回は開発者として必要な知識のベースがアップしたように感じます。一人で開発していたら絶対に得ることのできない知識を得ることができたので気分上々です。この辺は開発に入る前に知っておきたいところですが、開発を始めて失敗しないとわからない部分でもあるので悩ましいです。
Gitを使っていますが、まだまだ上手に使えていないとも感じているのでこれからもいっぱい失敗して覚えていきます。先輩社員や同僚には大変迷惑をかけてしまいます。未来の同僚たちに今から土下座しておきます。
過去記事を載せておきますね。
