これまでSVNの基本的な使い方とタグ、ブランチの操作方法について学んできました。
ただ、実際の開発において、バージョン管理はより高度で複雑な運用が求められます。 この章では、開発の現場で発生する問題と、それに対してどのようにバージョン管理を運用していくのか、いくつかの例を使って紹介します。
開発した成果物を出荷した後も、仕様変更や障害改修などを行い、継続して再出荷していく必要があります。 そんな時、現在どのバージョンが出荷されているのかを適切に把握していないと、ユーザーから報告された障害が既に改修済みなのかどうかが分からなくなってしまいます。
また、出荷先の環境に合わせた設定変更（例えば、サーバーの名前の変更など）が必要な場合、毎回手作業で行っていると作業が漏れる可能性があります。
この問題に対処するための運用方法が「リリースブランチ・タグ（Release branch/tag）」です。
図15-1 リリースブランチ・タグ
出荷（リリース）したバージョンと同期するブランチを作成し、出荷時のスナップショットをタグにしておくことで、トランクとは別に出荷バージョンをすぐに再現できるようにします。
また、出荷先の環境に合わせた変更を事前に行ってコミットしておくことで、出荷時の設定変更作業の漏れを防ぐことができます。
1-2 : トランクで開発が進む
3 : 出荷用のリリースブランチをトランクをコピーして作成する
4 : リリースブランチとは別にトランクで作業が進む
5 : 出荷先に合わせてリリースブランチ上で設定変更を行う
6 : リリースのタイミングのスナップショットを、リリースタグ1としてリリースブランチから作成する
7-8 : リリースブランチ・タグとは別にトランクで作業が進む
9 : 再度のリリースに向けて、トランクの変更をリリースブランチにマージして取り込む
10 : 再リリースのタイミングのスナップショットを、リリースタグ2としてリリースブランチから作成する
11- : またトランク上で作業が進む
- はじめてのReleaseブランチ運用（svn編）
https://www.slideshare.net/masaru_b_cl/releasesvn
バグ修正を行う際、その修正が何のために行われ、どのように変更されたのかを把握する必要があります。
また、その変更作業は、対象となる成果物以外とは独立して行わないと、予期せぬ影響を与える恐れがあります。
この問題に対処するための運用方法が「バグ修正ブランチ・タグ（Bugfix branch/tag）」です。
図15-2 バグ修正ブランチ・タグ
バグ修正専用のブランチを作ることで、対象となる成果物以外への影響をある程度防ぐことができます。
また、バグ修正前後のスナップショットをタグとして残しておくことで、この2つのタグの差分を見れば、そのバグ修正で行われた変更が確認できます。
1-2 : トランクで開発が進む
3 : バグ修正用のブランチをトランクをコピーして作成する
4 : バグ修正前の状態のスナップショットをタグとして残す
5, 8 : バグを修正してバグ修正ブランチにコミットする
6, 9 : トランクはバグ修正ブランチとは独立して開発が進む
7 : 別のバグ修正用ブランチを変更して作成できる
10 : バグの修正が完了する
11 : バグ修正後の状態のスナップショットをタグとして残す
12 : バグ修正ブランチをトランクにマージする
トランクへのマージの際、実際にマージされる内容は3と10のコミット間の差分になります。したがって、6, 9のトランク上のコミットでバグ修正対象に変更がないか、あっても5, 8, 10のバグ修正ブランチ上のコミットとファイル内の変更箇所が違えば、問題なくマージできます。
変更箇所が同じだった場合は、マージの際に競合が発生してしまいますが、14章の4.競合の解決の手順で、メンバーと調整してあるべき形にしてコミットしてください。
(WIP)
