分散バージョン管理ツールにおけるブランチ戦略

分散バージョン管理ツールにおけるブランチ戦略やマージ・リベースの使い方に関するリンクをメモ。

【元ネタ】
(分散)バージョン管理システムの組織化

[Git] 使い分けできていますか？マージ（merge）&リベース（rebase）再入門

SVNでは、プライベートなワークスペースにチェックアウトして、ソースを修正する。
その履歴は例えばEclipseの環境だけでしか保持できない。

GitやMercurialでは、プライベートブランチは全て、masterからクローンされたブランチになる。
作業履歴を残すのも簡単。

すると、それらブランチをmasterへどのタイミングで、どのようにマージしたら良いのか、という問題が出てくる。
上記2つの記事では、ブランチの考え方とマージ方法について、その考え方を書いていてとても参考になる。

以前は複数の製品ラインの開発、つまりソフトウェアプロダクトラインで現れており、ブランチの制御が難しいという問題がずっとあった。
また、運用保守と新規開発の2本のソースを同時並行で修正しなければならない問題もあった。

だが、複数ブランチによる並行開発は、今の時代はとても当たり前。
GitやMercurialでは、開発者の人数分だけブランチがあり、masterにコミットする時は、開発者のプライベートブランチ(もしくはトピックブランチ)から、完成版のパッチだけをマージすることが可能になった。
masterのソースの履歴を常に綺麗に保つために、ブランチの履歴を削除したり統合したりするなど、コミット履歴の改変も可能だからこそ、そのような芸当もできる。

第4回品川Redmine勉強会で丸山さんの発表を聞いていて一番嬉しかった事は、構成管理パターンの参考資料として「パターンによるソフトウェア構成管理」だけでなく「Redmineによるタスクマネジメント実践技法」もあげられていたこと。
チケット駆動開発の面白さは、構成管理パターンとチケット管理の密な連携にあるので、もっとまとめてみたいと思っている。

Redmineのブランチ戦略