より進んだ運用についての章を追加する：バグ修正ブランチ・タグ

.gitignore

@@ -1,2 +1,2 @@
 ~$*
-
+.*/

15.team-use-3.md

@@ -22,7 +22,7 @@
 
 ### 解決策
 
-この問題に対処するための運用方法が「リリースブランチ・タグ（Release tag/branch）」です。
+この問題に対処するための運用方法が「リリースブランチ・タグ（Release branch/tag）」です。
 
 ![リリースブランチ・タグ](images/chapter-15-1.jpg)
 
@@ -36,7 +36,7 @@
 
 1-2 : トランクで開発が進む
 
-3 : 出荷用にリリースブランチをトランクをコピーして作成する
+3 : 出荷用のリリースブランチをトランクをコピーして作成する
 
 4 : リリースブランチとは別にトランクで作業が進む
 
@@ -59,7 +59,49 @@
 
 ## <a name="bugfix-branch-and-tag"></a>2. バグ修正ブランチ・タグ
 
-(WIP)
+### 問題
+
+バグ修正を行う際、その修正が何のために行われ、どのように変更されたのかを把握する必要があります。
+
+また、その変更作業は、対象となる成果物以外とは独立して行わないと、予期せぬ影響を与える恐れがあります。
+
+### 解決策
+
+この問題に対処するための運用方法が「バグ修正ブランチ・タグ（Bugfix branch/tag）」です。
+
+![バグ修正ブランチ・タグ](images/chapter-15-2.jpg)
+
+図15-2 バグ修正ブランチ・タグ
+
+バグ修正専用のブランチを作ることで、対象となる成果物以外への影響をある程度防ぐことができます。
+
+また、バグ修正前後のスナップショットをタグとして残しておくことで、この2つのタグの差分を見れば、そのバグ修正で行われた変更が確認できます。
+
+### 運用手順
+
+1-2 : トランクで開発が進む
+
+3 : バグ修正用のブランチをトランクをコピーして作成する
+
+4 : バグ修正前の状態のスナップショットをタグとして残す
+
+5, 8 : バグを修正してバグ修正ブランチにコミットする
+
+6, 9 : トランクはバグ修正ブランチとは独立して開発が進む
+
+7 : 別のバグ修正用ブランチを変更して作成できる
+
+10 : バグの修正が完了する
+
+11 : バグ修正後の状態のスナップショットをタグとして残す
+
+12 : バグ修正ブランチをトランクにマージする
+
+### トランクへのマージ
+
+トランクへのマージの際、実際にマージされる内容は3と10のコミット間の差分になります。したがって、6, 9のトランク上のコミットでバグ修正対象に変更がないか、あっても5, 8, 10のバグ修正ブランチ上のコミットとファイル内の変更箇所が違えば、問題なくマージできます。
+
+変更箇所が同じだった場合は、マージの際に競合が発生してしまいますが、[14章の4.競合の解決](14.team-use-2.md#resolve-conflict)の手順で、メンバーと調整してあるべき形にしてコミットしてください。
 
 ## <a name="vendor-branch"></a>3. ベンダーブランチ