CVSとSVNのようなリビジョン管理システムを初めて使用したとき、私は実際に "トランク"、分岐、マージ、タグ付けの概念を理解できませんでした。私は今、これらの概念を理解し始めており、実際にそれらの背後にある重要性と力を得ています。リポジトリの組織
だから私はそれを正しくやっています。これは私がこれまで考えていたことです：これは私が今まで理解していることです：あなたのコードの最新版/安定版は/ trunk /に入っていなければなりません。リリースし、リリースするとトランクにマージされます。
これはあまりにも単純なものですか？どのリポジトリレイアウトをお勧めしますか？違いがある場合、私はSubversionを使っています。
は、より多くの情報のためにSO上でこれらの二つの質問を参照してください。
私は何をして正常に標準として参照すると、次のとおりです。
トランクが含まれている必要がありますあなたのメインラインの開発、あなたの不安定なバージョン。 リリース用のリリースブランチを作成する必要があります。
のような何か：
/トランク（ここには、バージョン2.0を開発している） /branches/RB-1.0（これは1.0のリリースブランチです） /branches/RB-1.5
ます1.5でバグを見つけ、RBブランチで修正してからトランクにマージします。
this bookもお勧めします。
Ericには、ソース管理の使用と組織のベストプラクティスに関する優れた一連の記事があります。 Chapter 7 deals with branches（はい、/ trunk /および/ branches /ディレクトリをお勧めします）。
私はPERFORCEを長い間使用してきました。私のコメントはPERFORCE中心ですが、基本的な原則は半分程度の分岐を持つSCMソフトウェアに適用されます。 私は分枝的な開発慣行を使用することを非常に信じています。私は今から永遠にコードベースを表す「メイン」（別名「メインライン」）を持っています。これはほとんどの場合、安定していることが目的であり、システムが現在機能している場合はいつでもリリースを中止することができます。これらの厄介な販売員は依頼し続けます....
開発は、MAINから分岐しているブランチで行われます（通常は、既存のdevブランチから分岐することがあります）。可能な限り頻繁にMAINからデベロッパーブランチに統合して、分裂を止めすぎないようにするか、または後でより大きな統合期間のために単に予算を立てることができます。新しい機能をMAINに統合するのは、来るべきリリースに出ることが確実なときだけです。
最後に、RELEASE行があります。これは、リリースごとに異なるブランチのオプションです。 SCMソフトウェアのラベリング機能と、メジャー/マイナーバージョンの違いがどのように異なるかによって、いくつかの選択肢があります。たとえば、すべてのポイントリリースのリリースブランチ、またはメジャーなレヴェルナンバーのみを選択することができます。あなたのマイレージは異なる場合があります。
一般に、MAINから分岐してできるだけ遅くリリースします。バグ修正と直前の変更は、直ちにMAINへの統合のためにRELEASEに、または即時の統合バックアップのためにMAINへと直進できます。ハードと高速のルールはありません。最も効果的な方法を実行します。しかし、あなたがMAINに（例えば、devブランチから、またはMAINの誰かが "少し微調整"して）提出する可能性がある変更があれば、前者を行います。あなたのチームの仕組み、リリースサイクルなどによって異なります。
たとえば、私は次のようなものを持っています：
//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...
重要でないプロジェクトには、おそらく多数のDEVブランチが同時にアクティブになるでしょう。開発がMAINに統合され、主要なプロジェクトの一部になったら、できるだけ早く古いDEVブランチを終了してください。多くのエンジニアは、DEVブランチを独自の個人空間として扱い、時間の経過とともにさまざまな機能に再利用します。これを控える。
リリース後、バグを修正してから、対応するリリースブランチで修正する必要があります。 MAINでバグが修正されている場合は、MAINでコードがあまり変更されていない限り、修正は異なります。
本当にコードラインを区別するのは、それらを管理するために使用するポリシーです。たとえば、どのテストが実行され、誰が変更前/変更をレビューしたか、ビルドが中断した場合に実行されるアクションなどがあります。通常、ポリシー（したがってオーバーヘッド）はリリースブランチで最も強く、DEVでは最も弱いです。記事hereにはいくつかのシナリオがあり、他の便利なものへのリンクがあります。
最後に、簡単な構造で始めて、必要に応じて追加の&をリリースすることをお勧めします。
あまりにも多くのことを明らかにしてくれることを助けてくれるとは思っていません。