分岐にはいくつかの用途があります。最も一般的な用途の1つは、かつて共通のコードベースを持っていたプロジェクトを分離することです。これは、メイントランクに影響を与えずにコードを試すのに非常に便利です。
一般的に、2つのブランチタイプが表示されます。
機能ブランチ：特定の機能が破壊的であるため、開発チーム全体が初期段階で影響を受けたくない場合は、この作業を行うブランチを作成できます。
修正ブランチ：メイントランクでの開発が継続している間、修正ブランチを作成して、ソフトウェアの最新リリースバージョンへの修正を保持できます。
分岐の原理と、それらをいつ使用するかについて説明している次の記事をご覧ください。
一般的に、分岐（VCS-バージョン管理システム-機能）の主な目的は、コードisolationを達成することです。
少なくともoneブランチがあり、これは順次開発に十分であり、同じ一意のブランチで記録（コミット）されている多くのタスクに使用されます。
しかし、そのモデルはすぐにその限界を示します：
開発作業（リファクタリング、進化、バグ修正など）があり、現在の開発ブランチと同じブランチでそれらの変更を安全に行うことができないことに気付いた場合（APIを壊したり、壊れるコードを導入したりするため）すべて）、thenには、anotherブランチが必要です。
（2つのコードセットは後でマージされますが、レガシーコードの新しいコード（isolateに））
それがあなたの答えです。
1つのブランチで2つの開発作業を追跡および記録できない場合は、ブランチする必要があります。
（維持するために恐ろしく複雑な履歴がない）。
ブランチは、ソースコードで作業しているのが自分だけである場合でも、多くの場合でも便利です。
ただし、「開発者ごとに1つのブランチ」を作成しないでください。
「分離」の目的は、開発努力を分離することです（「次のバージョンを開発しましょう。私たちのソフトウェア」または「バグ23を修正しましょう」などの具体的な情報、
「リソース」を分離しない。
（「VonC」という名前のブランチは、他の開発者にとっては何の意味もありません。「VonC」がプロジェクトを離れた場合はどうなりますか？それをどうするつもりですか？
「bugfix_212」と呼ばれるブランチは、たとえばバグ追跡システムのコンテキストで解釈することができ、開発者はそれを使って何をすべきかについて少なくともある程度の考えを持ってそれを使用できます）
ブランチはタグではありません（SVNは Revision System であり、 バージョン管理機能の提案を試みます ）安価なファイルコピーを使用してディレクトリを分岐およびタグ付けするなど：タグが分岐であることを意味しません）
ブランチを定義するということは、 マージワークフロー も定義することを意味します。ブランチを終了したら、どこでブランチをマージするかを知る必要があります。
そのため、Practical Perforce（Laura WINGERD-O'Reilly）の第7章は、さまざまな種類のブランチ間でワークフローをマージするための優れた紹介（VCSに依存しない）です。 "" - ソフトウェアの進化 "（pdf）
用語codeline（特定のポイントでタグを介して、またはブランチに戻る重要なマージを介してコードの重要な進化ステップを記録するブランチ）を定義します。
メインラインモデル（リリースを記録するための中央コードライン）を紹介し、分岐のさまざまな目的について説明します。
- アクティブな開発ストリーム：順次さまざまな開発が行われるときの永続的なコードライン
- タスクブランチ：より具体的なタスクの短命ブランチ（バグ修正は古典的なものですが、完了が複雑であることがわかっているマージ作業のためにブランチを定義することもできます。メインの現在の開発ブランチに問題を引き起こすことなく、そのタスクブランチでコミットしてテストします）
- ステージングブランチ：いくつかの運用前特定のデータまたは設定ファイルを使用して、リリースを準備する.
- プライベートブランチ、アドホックブランチ、およびスパースブランチ：非常に小さなタスクの場合、正式な完了またはテストレビューを待たずに進行中の作業をコミットできるようにします。
これにより、「早期にコミットし、頻繁にコミットする」ことができます。
VCSに関するその他の興味深い概念： 基本概念
（元々はClearCaseについてでしたが、VCSでも有効です）
21世紀のSCMはすべて次のことを伝えています。
これが新機能、バグ修正、テストなどに関係なく、作業するすべてのタスクのブランチ。これはトピックブランチと呼ばれ、SCMでの作業方法を変更します。
あなたが得る：
- より良い分離
- トレーサビリティの向上->個々のチェンジセットではなくブランチにタスクを関連付けます。これにより、必要な回数だけ自由にコミットでき、「タスクごとに1回のチェックイン」のような制限を課しません。
- タスクは独立しており（通常は安定したベースラインから開始するため、コードにのみ焦点を当て、人々のバグを修正するのではなく）、ある時点で統合するか、後で統合するかを選択できますが、常にバージョン管理
- メインラインにアクセスする前に、コードを簡単に確認できます（事前コミットのでたらめではなく、バージョン管理から）
できるツール：
できないツール：
- SVN
- CVS
- VSS
- TFS
- Perforce
また、使用しているSCMツールにも依存します。最新のSCM（git、Mercurialなど）を使用すると、必要に応じてブランチを簡単に作成および破棄できます。これにより、たとえば、作業中のバグごとに1つのブランチを作成できます。結果をトランクにマージしたら、ブランチを破棄します。
SubversionやCVSなどの他のSCMには、はるかに「重い」分岐パラダイムがあります。つまり、ブランチは、20行のパッチよりも大きいものにのみ適していると見なされます。ブランチは、以前または将来の製品バージョンのように、開発トラック全体を追跡するために従来使用されています。
特にトランクに影響を与えずに中間的な変更をコミットする場合、コードベースに大幅な変更や実験的な変更を行う必要がある場合。
使用しているSCMのタイプによって異なります。
新しい分散バージョン（gitやMercurialなど）では、常にブランチを作成し、とにかくマージしています。誰かがメインラインのビルドを壊したり、ネットワークがダウンしたり、修正が行われた後で変更をマージしたりするので、しばらくの間は別のブランチで作業することがよくあります。 。
分散システムで何が行われているかを理解するのに最も役立つドキュメント（短くて読みやすい）は、 nderstandingMercurial です。
中央リポジトリ（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 を参照してください。それぞれの詳細およびその他のベストプラクティスについて説明しています。
分岐にはさまざまな目的があります。
- 機能/バグの分岐。機能/バグ修正が完了したときにトランクに戻される動的でアクティブなブランチ。
- 静的ブランチ（Subversionのタグですが、本質的には「通常のブランチ」です）。たとえば、リリースの静的なスナップショットを提供します。 couldに取り組んでいたとしても、そのままです。
あなたがそれを感じるたびに。
ブランチは公式リポジトリの一部であるため、集中化されたSCMを使用する場合、おそらくあまり頻繁に使用することはないでしょう。また、マージは本当に痛いことは言うまでもなく、実際には多くの実験を必要としません。
OTOH、ブランチと分散SCMのチェックアウトの間に技術的な違いはなく、マージはずっと簡単です。より頻繁に分岐するように感じるでしょう。
分岐の必要性も発生する場合があります。
すべての技術を残して.....
マージしやすいとわかったら分岐してください！
マージは常に、プロジェクトでの作業の実行方法に影響されることに留意してください。
これが達成されると、他のすべての三次問題が発生します。
現在のブランチに基づいて、そのブランチの次のリリース（以前ではない）に基づいて変更を加える必要がある場合。
たとえば、私たちは通常、トランクに取り組んでいます。リリースの頃には、誰かが現在のリリースでは望まない変更を加える必要があります（通常はリリース後のリリース前かもしれません）。これは、私たちがブランチするときです。リリースを独自のブランチに置き、トランク上の次のリリースの開発を継続します。