背景
会社はGithubでGitflowを管理しています。最近開発の業務が大幅増えてきて、ブランチの数も以前より何倍になりました。Gitブランチについて、現状は下記となります。
1. 大きな機能に対して、featureブランチを作成して、細かい機能は更にチケットを切ってfeatureブランチ向けのPRを作って作業します。
2. テスト環境のデポロイやリリースのために、github actionでスクリプトを作って、毎回featureブランチ向けのPRがマージされたら、自動的にデポロイやリリース用のブランチへPRを生成します。
3. 毎回リリースの直前にfeatureブランチの内容を確認して、リリースを行うとなります。
気がついたところ
最近はGitブランチの管理で下記の何点に気が付きました。
1. Sub-featureと所謂細かい機能を改修するブランチが多いので、ブランチの管理が難しくなる。更に考慮漏れや用件追加によって、命名が似ているブランチも増えて来ました。例えば、チケットAに向けのブランチticket_a。一回マージして、また新しい改修を追加したい場合は、ticket_a_fix、ticket_a_add_XXX、ticket_a_remove_XXXなどのブランチが作成されました。
2. 毎回新規のfeatureブランチを追加する際に、github actionのスクリプトを変更しなければいけないとなります。例えば、今期のsprint_aがリリースされたら、来期のsprint_bを追加する必要があります。
3. featureブランチのnamespaceが混乱になりました。featureブランチの命名規則がまたありませんので、基本は改修内容に元ついて命名します。結果としては、毎回リリースする前に今期リリースの内容をちゃんと確認しないとリスクが高いと思います。
4. github actionのブランチ管理が難しい。github actionでブランチやPRを管理したいの場合は、featureブランチを全部揃う必要があると思うので、実装や更新は確認するコストがあります。
Gitフォルダーの運用
Gitflowで正式的にメンションしていなかったですけど、下記の３つくらいのGitフォルダーを作って運用した例が多いと思います。
- feature[s]
- hotfix[es]/fixes
- release[s]
ref: https://dev.to/hardkoded/how-to-organize-your-git-branches-4dci
まとめ
- namespaceがフォルダー名でしっかりと分割されているので、Sub-featureの数が多いでもfeatureブランチの命名は混乱されてないになると思います。
- フォルダー名によって、github action側でfeatureブランチなどの制御が簡単にできます。