はじめに
さて、2018年も4月を迎え、新年度が始まりました。
このタイミングで新チーム体制となる職場も多いことでしょう。
筆者も例外ではなく、新たなプロダクト方針の下、開発フローを整える必要がありました。
そんな中、必ず考えなくてはならないことの1つとして ブランチルール があるかと思います。
今回はその ブランチルール に特化した記事を書き留めていきます。
なぜブランチルールを考えるのか
そもそも『なぜ ブランチルール を考えなくてはいけないのか？』と疑問に思う方もいるでしょう。
例えば、開発者一人でアプリケーションの開発業務をするのであれば、以下でも特に問題ないかもしれません。
masterブランチから任意の名称のブランチを切る- 切ったブランチで完成するまで作り続ける
- 作り終わったら
masterにマージする
しかし、そこに 『新たなメンバーの参画による引き継ぎ業務』 が入ったらどうなるでしょうか？
『アプリケーションの内容だけ引き継いで、ブランチルールは引き継がなくても良い』
(と言うか、ブランチルールなんてないようなものなので引き継げない…)
と簡単に切り離せるものでしょうか？
業務でこれまでの経緯を知る必要が出てきた時に、恐らくそれは成り立たないことでしょう。
であるならば、例え一人での開発だったとしても ブランチルール を明確にしておいて損はないと思います。
さらに、『複数人で案件を並行させながら開発する』必要が出てきた場合には最早議論の余地はないでしょう。
もしもそこに ブランチルール が存在しなかったとしたら、代わりにそこには必ず 障害 が存在していると思うべきでしょう。
一般的なブランチルール
前段はこのくらいにして、一般的なブランチルールを見ていきましょう。
git-flow
まずは何と言っても有名なのが git-flow でしょう。
これはVincent Driessen氏が提唱しているブランチルール(ブランチモデル)です。
※ A successful Git branching model より抜粋
各ブランチは以下の役割を持っています。
git-flow の良いところは、
- 長期間かかる案件の開発に向いている
- 各ブランチの役割が1つ1つ明確に分かれており、(ルールを覚えれば)作業に迷わない
だと思っています。
github-flow
続いてこちらも超有名 github-flow ですね。
これは git-flow のような複雑性は皆無と言っても過言ではないくらいシンプルな ブランチルール です。
各ブランチは以下の役割を持っています。
github-flow の良いところは、
- リリースサイクルの早い開発に向いている
- シンプルなブランチ運用であるため、作業に迷わない
開発現場で必ず生まれる既存ブランチルールのオマージュ
git-flow や github-flow など優秀な ブランチルール があることがわかりました。
が、しかし、開発現場ではなかなかそのままの ブランチルール を利用するということが意外にもないのではないでしょうか。
その理由の1つとして、『プロダクトフェーズへの ブランチルール の依存』が考えられます。
以下、具体的に求められうる事象を取り上げます。
- ライバルを追う立場のプロダクトは、勝ち手の見えている大規模機能を早く提供する必要がある
- 並行して大規模な追加機能を開発することが求められる
- 並行して小さな改善と大規模な追加機能を開発することが求められる リリースサイクルの長さが明らかに異なる案件が混ざっている
こういった現場の状況に耐えうる ブランチルール はどういったものが考えられるでしょうか？
例えば…
feature/案件名/masterブランチを作成し、それらにはdevelopと同じ役割を与える
feature/案件名/masterから機能追加単位でfeature/案件名/xxxxブランチを切って開発を進めるdevelopブランチを用意せず、featureブランチはreleaseブランチにマージする
など様々な手段があるかもしれません。
上記はあくまでも一例ですが、各開発現場にとって最適な ブランチルール は必ず存在するはずです。
オマージュする/しないが善悪なのではなく、プロダクトを推進する上での善悪で判断することで、メンバーの納得感を得ることもできるでしょう。
まとめ
さて如何でしたでしょうか？
最近、「ブランチルールを考えて、相談して、図示化して…」ということが多かったので、少し整理してみました。
筆者の現場でも必ずブラッシュアップが発生すると思っているので、また考え方が変わったらブログに書いていこうと思います。
と言ったところで本日はここまで。