TL;DR
最近になって「お、このブランチの命名規則わかりやすくてよいぞ！」という学びを得たのだが意外？と知らないひともいるっぽいので参考に書いておこうと思う。
特にこうでなければいけない…というわけではない。
今のところこの命名規則以上によいと思える命名規則に出会えてない。
こっちのほうがいいよ！とかあればコメントで教えてもらえると助かる、あるいはこの命名規則でかつて困ったことがあるも歓迎。
恐らく知ってるひとにとっては当たり前だし、今更な内容。
対象読者
git使ってブランチ作ることがあるひと。
お題:
「画像のファイルアップロード先をAWS S3に変更する」というissueがたったとする。
(ブランチ名の英語が無茶苦茶とかいう指摘はとりあえず置いておく)
Before:
以前はfeature/modify_upload_dest_of_image_fileみたいなブランチを作ってた
After
今はfeature/#1_modify_upload_dest_of_image_fileに変更。
このときブランチを作成する前に必ずissueを立てさせるという運用ルールを適用している。
良くなったこと:
- この作成されたブランチがどのissueに関連したものかが明確になった
- 1つのブランチに複数の修正を入れにくくなった
- 修正中に見つけた不具合などを修正する際にissueを立てて別ブランチで直す…という流れになった。以前はまとめて1つのブランチで直す人が少なからずいた。
- 「これ直してほしいんだけど…」という依頼に対して「issue立てて」と返せるようになった
- issue立てないと受けないという建前が出来た
- レビューしやすくなる
- issueやブランチで修正する内容が細かく、1つのことに集中する形になりやすいためコミットが大きくなりすぎないためコードレビューしやすくなる。
- ただその分、数が多くなるので改善とはいいにくい面もある。
悪くなったこと:
ただ悪い面も少なからずある、メリットに比べてデメリットは我慢というか無視してしまえるものだとは考えている。
- issue立てるのがダルい
- 変数名のタイプミスを修正する…みたいなissueを立ててしまうことがある、そういうissue立てるほどでない場合にどうすべきか？というのは今のところ個人の裁量に任せっきりであまりよくないと思ってる。
- 変数名のタイプミスが複数箇所にあるとかでなく、1箇所の場合「これのためにissue立てるのか？！」みたいな気持ちになることがある、とはいえ統一性という面ではそれでも立ててほしくて悩ましい。
- issue&ブランチ多すぎ問題
- ちょっとした修正、修正中のブランチから更に派生したブランチ、当初のissueでは想定しきれなかったケースのためのissueとブランチを作成…みたいな感じでめっちゃ増えていく。
- すぐさまマージしてしまえればいいがそうでないとブランチが溜まりに溜まって大変ノイジー。
- この場合すぐにマージできないことのほうが問題だとは思う。
- issue立てないとなにもしないのかよ！もっと自発的に動け！みたいなこと言われる
- issueないと動きません、以上。でも言ってくる側の気持ちもわかる。
- hotfixのときどうすんの？レビュー用に新規ブランチ(PR作る用途)作りたいんだけど？ってときに困る
- その場合は
hotfix/hoge_fugaとかreview/fuga_piyoみたいにすれば良い気がするがあまりスマートでない…と感じてる。 - 通常のbugfixはissue立てさせてる。
- その場合は
あとがき
きちんと厳密にルールを守らせる必要はあるがissueとブランチが1セットというのが非常に良いと感じていて、割りと話の流れでありがちな「じゃあサクッと直してよ」という口頭&当事者間で完結してしまう依頼を駆逐できる。
言った言わない、どこまでやったやってない、を減らす効果が多少なりともあると感じてる、それでも0にはならない。
あとはかつて修正したissueを参考にしようとしたときにどのブランチだったかな？みたいなときわかりやすくて良い。