回答:
分岐にはいくつかの用途があります。最も一般的な用途の1つは、かつては共通のコードベースがあったプロジェクトを分離することです。これは、メイントランクに影響を与えずにコードを試すのに非常に役立ちます。
一般に、2つのブランチタイプが表示されます。
機能ブランチ：開発チーム全体の初期段階で影響を受けたくない特定の機能が破壊的である場合、この作業を行うブランチを作成できます。
修正ブランチ：メイントランクで開発が継続している間、修正ブランチを作成して、ソフトウェアの最新リリースバージョンに対する修正を保持できます。
分岐の原則とそれらをいつ使用するかについて説明している次の記事をチェックしてみてください。
一般的に、分岐（VCS-バージョンコントロールシステム-機能）の主な目的は、コードの分離を実現することです。
少なくとも1つのブランチがあり、これは順次開発に十分であり、同じ固有のブランチで記録（コミット）される多くのタスクに使用されます。
しかし、そのモデルはすぐにその限界を示しています。
開発作業（リファクタリング、進化、バグ修正など）を行っており、現在の開発ブランチと同じブランチでそれらの変更を安全に行うことができないことに気付いた場合（APIを破壊するか、破壊するコードを導入するため）すべて）、その後、別のブランチが必要です。
（2つのコードセットが後でマージされる場合でも、レガシーコードの新しいコードを分離するため）
つまり、これが正解
です。1つのブランチで2つの開発作業を追跡および記録できない場合は、必ずブランチする必要があります。
（維持するのに恐ろしく複雑な履歴がありません）。
ブランチは、ソースコードに取り組んでいるのがあなただけである場合や、多数である場合にも役立ちます。
ただし
、「開発者ごとに1つのブランチ」を作成しないでください。「分離」の目的は、開発作業を分離することです（「ソフトウェアの次のバージョンを開発しましょう」と同じくらい一般的、または「修正しよう」と具体的にすることができます）。バグ23 "）、
"リソース "を分離しないため。
（「VonC」というブランチは、別の開発者にとって何も意味しません。「VonC」がプロジェクトを離れた場合はどうなりますか？それをどう
するのですか？「bugfix_212」というブランチは、たとえばバグ追跡システムのコンテキストで解釈できます。 、そしてどの開発者も、彼がそれで何をすることになっているのかについての少なくともいくつかの考えでそれを使うことができます）
ブランチはタグではありません（SVNであるリビジョンのシステム機能のバージョン管理を提案しようとします：タグを意味するものではありません、分岐されて分岐し、安価なファイルのコピーを持つディレクトリをタグ付けのような複数可）
ブランチを定義するには、マージワークフローも定義する必要があります。ブランチを使い終わったら、ブランチをどこにマージするかを知る必要があります。
そのため、実用的なのPERFORCEの章7（ラウラWINGERD -オライリー）は、枝の異なる種類の間のワークフローをマージするには良い入門（VCSの不可知論）である：「」どのようにソフトウェアの進化」（PDF）
これはコードラインという用語を定義します（特定のポイントでタグを介して、またはブランチへの重要なマージを介して、コードの重要な進化ステップを記録するブランチ）
メインラインモデル（リリースを記録する中心的なコードライン）を紹介し、分岐のさまざまな目的について説明します。
VCSに関するその他の興味深い概念：基本概念
（元々はClearCaseについてですが、すべてのVCSにも有効です）
21世紀のすべてのSCMはあなたに言っています：
これが新機能であるか、バグ修正であるか、テストであるかに関係なく、取り組む必要のあるすべてのタスクのブランチ。これはトピックブランチと呼ばれ、SCMの操作方法を変更します。
あなたが得る：
それを行うことができるツール：
それができないツール：
また、使用しているSCMツールにも依存します。最新のSCM（git、mercurialなど）を使用すると、必要に応じてブランチを作成および破棄することがますます簡単になります。これにより、たとえば、作業中のバグごとに1つのブランチを作成できます。結果をトランクにマージしたら、ブランチを破棄します。
SubversionやCVSなどの他のSCMには、はるかに「重い」分岐パラダイムがあります。つまり、ブランチは、20行のパッチよりも大きなものに対してのみ適切であると見なされます。そこでは、ブランチは、以前または将来の製品バージョンのように、開発トラック全体を追跡するために古典的に使用されています。
これは、使用しているSCMのタイプによって異なります。
新しい分散バージョン（gitやmercurialなど）では、常にブランチを作成し、とにかく再マージしています。メインラインのビルドが壊れている、またはネットワークがダウンしているため、別のブランチでしばらく作業することがよくあります。修正が完了したら、変更を後でマージします。これを行うのは簡単なので、煩わしくもありません。 。
分散システムで何が行われているかを理解するのに最も役立つドキュメント（短くて読みやすい）は、UnderstandingMercurialです。
中央リポジトリを備えた古いシステム（CVS、SVN、ClearCaseなど）では、チームレベルで決定する必要があるはるかに深刻な問題であり、答えは、「許可しながら古いリリースを維持すること」メインラインで継続するための開発」、または「主要な実験の一部として」。
分散モデルははるかに優れていると私は思います。そして、支配的なパラダイムになるための優れたグラフィカルツールだけが不足しています。ただし、それほど広く理解されておらず、概念が異なるため、新しいユーザーを混乱させる可能性があります。
PerforceのLaura WingerdとChristopher Seiwaldからのアドバイスは本当に簡潔で便利だと思います。
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
それぞれの詳細な説明およびその他のベストプラクティスについては、http：//www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdfを参照してください。
分岐にはさまざまな目的があります。
現在のブランチに基づいて変更を加える必要があるとき、そのブランチからの次のリリースは予定されていません（以前ではありません）。
たとえば、私たちは通常トランクに取り組んでいます。リリースの前後に、誰かが現在のリリースに必要のない変更を加える必要があります（リリース前のこともあれば、通常はリリース後のこともあります）。これは、ブランチをリリースするときに、リリースを独自のブランチに置き、トランクでの次のリリースの開発を継続します。
すべての技術を脇に置いて.....
元に戻すのが簡単だとわかったら分岐してください！
マージは常に、プロジェクトでの作業の実行方法によって影響を受けることに注意してください。
これが達成されると、他のすべての第3の問題が出てきます。