SVNとGitのブランチ運用について!マージミスが怖い

SVNとGITでのブランチ運用を考えた場合GITのほうがメリットがあります。

SVNの何が問題なのか?

例えば 「あるライブラリを1.xから2.xにVersionUpする」 という作業を考えてみます。

作業タスクは以下のようになるでしょうか。

  1. 既存ライブラリの削除(2.xで削除されたファイルが残らないように)
  2. 2.xのライブラリをプロジェクトに取り込み
  3. 1.xから2.xで変更となったAPIの反映
  4. Licence表記の変更(必要があれば)

これらの変更タスクはそれぞれ独立していると考えて良いでしょう。
(それぞれのタスクに明確なゴールがある)

SVNの場合は すべての作業が間違いなく完了しないとコミットできません。

GITはブランチが簡単に切れる

一般的に広く知られているものではない(と私は思うのです)が、
SVNのブランチ(とマージ)にはかなりの「制約」や「コスト」を伴います。

  • 子ブランチと親ブランチ間のマージは自動で出来るが、それ以外(孫 <–> 子)についてはできない
  • Gitに比較してブランチを作るコストは大きい

なぜブランチが必要なのか?

じゃあ、そもそもブランチってなんで必要なのでしょうか。
それは 他の開発者に影響をあたえず、自分に与えられた開発作業をコミットしていくためです。

ふむ、考えてみると 実にアタリマエのことです。
そう考えると「ブランチを切る」ってのはむしろ自然な考えで、逆にブランチを切らないほうが不自然な考え方に思えてきます。

そういう 発想転換が出来ると、今度はブランチを自由に切りたくなってきます。

releaseブランチ

命名規則
release/[バージョン番号]
  • developブランチから生まれる
  • 一通りの作業が終わればmasterブランチに取り込まれる

リリース準備に入った状態を示すブランチです。このブランチが、developブランチから生まれた瞬間、プロダクトは機能追加を止めてbugfixなどの調整に専念し、次バージョンをリリースするための準備に入ります。

とはいえ、ここまで紹介したブランチと比べると幾分優先度が低いブランチと言えます。リリース準備の仕上げと、先行開発がかぶらない(人的リソースが多くない)場合などは、releaseを切らずにdevelopのまま仕上げて、masterブランチにmergeしてしまえばよいでしょう。

そんなことを言いつつ、個人的にはrelaseブランチを切ることは推奨しています。なぜならreleaseブランチを切ることによって、マネジメントやプランニングの職能に「開発陣はリリース準備に入った!機能追加はSTOP!」という意思表明を行えるからです。実際、それはこのブランチの本来の存在意義に則しています。必要な機能が揃った上で、リリース準備に入るという宣言的な役割のブランチだからです。

releaseブランチを切る場合は、developブランチと並走することになりますが、developブランチはリリース後のmasterブランチをrebaseすることで、リリース作業分の変更を合流させるようにします

まとめ

ブランチ運用について随時更新します。

(Visited 33 times, 1 visits today)

シェアする

  • このエントリーをはてなブックマークに追加

フォローする