以前、gitブランチの名前の付け方について紹介したことがあります。
ブランチ4本
いま定着しているブランチは、次の4つのブランチです。プロジェクトによっては、master、developだけのこともあります。
(1) master
製品ブランチ
(2) develop
リリース前の確認用ブランチ
(3) personals/aoki/develop
開発者ごとの作業ブランチです。developからブランチします。
(4) personals/aoki/123
一時的な作業ブランチです。最後の数字はチケット番号です。personals/aoki/developですでに作業中のとき、別チケットの作業をしたいときの一時的なブランチです。developからブランチします。コミットして、developへマージしたら、すぐに削除します。
メインブランチ1本
「継続的デリバリー」という本では、複数人で開発していても、メインブランチ１本を推奨しています。ブランチ間のマージが面倒になるため、またメイン以外のブランチは自動テストしないことが多いためです。また、少なくても1日に1回、たいていは1日に数回コミットすることも推奨しています。
今は使わなくなった方法も教えて
ボツ1、ブランチ名に機能の名称をつける
チケットにする前の実験的な機能を試したいときに、ブランチ名に機能の名称をつけたことがあります。
例えば、
develop_camera
develop_news
コレという名前を考えるのが面倒でした。チケットを起こしてチケット番号をつけたほうが楽です。そもそも実験的なので放置することも多く、何をやっていたかを覚えていないこともあります。チケットにアイデアをメモしておくと、何をやっていたか思い出しやすくなります。
ボツ2、複数の作業ブランチ
gitは簡単にブランチ作成できることもあって、
personals/aoki/123
personals/aoki/124
personals/aoki/125
といったように、複数の作業ブランチを作成していたことがあります。
masterやdevelopから各ブランチへのマージが手間でした。ブランチが多いほどconfictしやすくなります。
例えば、personals/aoki/123の作業が一段落したら、
personals/aoki/123 から develop へマージ、
develop から personals/aoki/124 へマージ、
develop から personals/aoki/125 へマージ、
する必要があります。
さらに、他の開発者が develop へ push したら、
develop から personals/aoki/123 へマージ、
develop から personals/aoki/124 へマージ、
develop から personals/aoki/125 へマージ、
する必要があります。
このようにブランチ切り替えとマージ操作が多くて面倒でした。あまり作業しないブランチはどこまで作業したのか忘れやすく、あらためて作業ブランチを作ってやり直すこともありました。同時に作業するチケットは１つ、作業ブランチも１本のほうがいいと思いました。
新しい記事で、git-flow、GitHub Flow、GitLab Flowのブランチ名をまとめました。
