前提：
ブランチを作成できるバージョン管理ソフトを使用（Git、Subversion、TFS等）
・リリース対象が一つの場合（納品先別にリリース対象が変わらない、または変わることが少ない）
・新規開発時：
マスターブランチから開発ブランチを作成し、開発ブランチに開発内容をチェックインしていく
・リリース：
開発ブランチからマスターブランチへマージして、マスターブランチをリリース対象にする
・リリース後（保守、改修時）：
リリースする単位でブランチを作成し、そこに修正や新規機能をチェックインしていき、完了時にマスターブランチにマージしてリリースする
＊メリット：
・共通部分の修正がマージして反映しやすい
・管理するリポジトリが一つなので管理がしやすい
＊デメリット：
・リポジトリへの変更が全ての納品先に影響する可能性がある
・納品先ごとにモジュールを変える場合は管理が煩雑になる可能性がある
・リリース対象が複数（納品先別にリリース対象が違う、基本機能はだいたい同じだが、機能やリリースのタイミングが違う）
・新規開発時（共通仕様部分）：
マスターブランチから開発ブランチを作成し、開発ブランチに開発内容をチェックインしていく
・リリース：
開発ブランチからマスターブランチへマージして、納品先ごとにリポジトリを複製して、新規リポジトリを作成する
・リリース後（保守、改修時）：
納品先のリポジトリにリリースする単位でブランチを作成し、そこに修正や新規機能をチェックインしていき、完了時にマスターブランチにマージしてリリースする
＊メリット：
・納品先ごとにリポジトリが違うため、他リポジトリの修正影響を受けない
・他納品先修正の影響を受けないため納品先ごとのカスタマイズがしやすい
＊デメリット：
・共通部分の修正を反映しにくい（場合によってはリポジトリごとにチェックインする必要がある可能性がある）
・管理するリポジトリが複数になるので一元管理はしにくい