はじめに
git-flow定義をした話を紹介します。
元々会社の開発部では、git-flowが策定されていませんでした。
正確にいうと、開発部全体の方針が決まっておらず、サービスごとに
「こんなかんじだな」という方針がありますが、みんなバラバラでした。
会社にそろそろ決めてほしいなあ・・と思い、打診してもらっていたのですが、はや一年・・・。
いつになったら決まるんだ！！！ということで、うちのチームはうちのチームで策定することにしました。
（ここで流派が生まれてしまう）
元々、チームではgit-flowすらもなくて、master直PUSHも結構ありました。
それでいいのかい？！っていうツッコミどころは多々あります。
後に、マージリクエストルールも私が定義することになるわけですが・・。
どんな〜やつにしたか
大体これと一緒ですね。
自分のチームにデザイナさんはいないので、デザイナさん向けのブランチなどは特に用意せず。
master, develop, featureという単位にし、masterの直接PUSHは禁止。
場合によってはhotfixを作るぐらいで。
git-flowがそもそもなかったので、慣らしから始めました。
ただ、gitのコミット、MR、どのブランチから派生して、みたいなのも大事なんですが、そもそも
コミットや、ブランチ名、MRのお作法などがカオスだったので、そこの運用をもっと重要視しました。
ブランチ名のルールも定義することにしました
元々は、
20231201_fix_hogehoge_for_win
みたいなテキトーなネーミングでした。時系列で見やすいっちゃ見やすいですけど、ざっくばらんにブランチが乱立、どんな規則名なのかもわからないし、酷いときには個人名が入ってることもあります。
面倒なので、JIRAのチケットの名前一律にすることにしました。
これによるメリット・デメリットは以下です。
メリット
- チケットに紐づいているため、なんのタスクであるか明快
- ブランチの名前のセンスを求められない（脳筋命名）
デメリット
- 同じような名前なので、チケットIDを意識しないと間違える
- 名前を見ただけだとなんのブランチかは判断付かない
commit prefixを定義
commit時において、どんな修正をしたのか、明確になるようにprefixを付けてもらうことにしました。
| prefix | 説明 |
|---|---|
| ci | ビルド関連 |
| docs | ドキュメント修正 |
| feat | 機能追加 |
| fix | バグ修正など |
| perf | パフォーマンス対応 |
| refactor | リファクタ |
| style | 誤記修正、スペルミス修正等（ソースコードの挙動に影響がないもの） |
コミットをするときも、今までいた会社でよくないなあ・・・って思ったコミットコメントが
update
っていう、こういうコミットですね。
なんの対応したのか全然わからんっていう。
もっと文章で書きなさいよ、っていうツッコミまちのコミットありますよね。
ああいうコミット文章だけは避けてもらうことにしました。
MR時のコメントのprefix
これを入れることで、どんな意図でツッコミをしてくれているのか、明確にします。
| prefix | 説明 |
|---|---|
| imo | 私の意見では。in my opinion |
| must | 必須でやってもらえると |
| want | やってもらえたら嬉しい |
| nits | nitpick 細かい指摘だが |
| q | 質問 |
| typo | スペルミス |
| tbd | to be determined 後で決める |
MR時のテンプレート
これも一応用意しました。
あったほうが楽かな〜って部分があったので。
ただし、あったほうがいいなというのは、どちらかというと自動的なレビュワー指定ですね。
テンプレート作成の方法自体は、gitlabかgithubによってお作法は少し違いますが、
テンプレートの中で、
@ほげほげ のように記述すれば、メンションされてレビュワー指定が自動的にできるようになるので便利です。
ただし、チームが流動的に変わってしまう場合だと少し難儀かな。
運用してみて
そこそこルール化したので、masterへのpushしちゃう文化に少し染まってたけど、大丈夫かな？ってのはありましたが、masterへの直pushを設定で禁止することで、MRを否が応でも出さないといけないものにしました。
これの場合なるはやで対応するのが難しくなる部分は、まああります。
ただ、コードの品質の担保をしたり、チームでのMR、それに対してのツッコミ、を活発化する上ではなくてはならないものかな〜と。
そもそも、誰も見てくれてないのに、masterにpushって、怖いでしょ？っていう布教が必要というか。
導入はしてよかったなと思います。
次は、コーディング規約に対して、自動的に設定できるツール選定や、仕組みをやりたいところですね。
で、MR出す前に、そこがciで自動チェック入るような感じにしたいかなあ。