は

Question

私はTFVCの土地からGitリポジトリに私のソースコードを移動する、と私はそれをクリーンアップする時間です考え出し、適切にそれを行う - 現時点ではコピーの多くは/あり貼り付けるあなたがする場合は金本位制と見られている -

私のプロジェクトでは、「メイン」ソリューションを持っています。しかし、私のプロジェクトは、2つのコンテンツの違いによって、異なるビジネスに適応可能であり、いくつかのビジネスロジックは（私が比較的疎結合の方法であると考えている）互いに異なる秘密のビジネスロジックを含んでいます。

私は「マスター」の構築、および異なるリリースを維持するための最善の戦略を知りません。

リリースごとに複数のブランチを持つリポジトリを作成するか、別のリポジトリに分割します（ただし、新しいコードをマージすることはできませんので、理想的ではありません）。

私は過去に「リリース分離の戦略を踏襲しています：恐ろしいの視覚のため申し訳ありません

F1 ------ 
     |--MASTER---------------- 
F2 ------   |---v1.4  |---v2.0 
        |    | 
        |--HF1  |--E1 

を、私の展開から来るどこマスターは、F1/2の特徴となり、V1.4/v2.0はサポートが必要なリリースで、HF1はそのリリースをサポートしているもので、E1はそのリリースに追加されたものです。

修正プログラムは、マスターの方に戻ってマージされるだろう、とマスターが生きて行くために十分な、新しいテスト機能を充填したとき、我々は新しいリリース（V3.0）を作成します。これは十分に安定している場合

問題は、私はこのモデルが私のホワイトレーベル

F1 ------ 
     |--MASTER(main client)---------------- 
F2 ------      |---client2  |---client3 
           |    | 
           |----v1.0  | 
           | |--E1   |--v1.1 
           |----v2.0   |----HF1 

に適合させることができるかわからない、である私は知りません。

すべてのビルドを横断している機能がある場合、私はMasterの左側から始めて、各リリースの新しいバージョンを突き抜けて、その後のマージ問題を調整できます。

私はバグ（すなわちHF1）を持っている場合、私は枝のLOTを渡ってそれをマージしなければならないが（まあ、少なくとも、サポートされているリリースとDEV /マスター支店）

は、この理想的ですか、私はつもりです完全に間違った方法？

Answer 1

私はそれを「フォークマスター戦略」と呼んでいます。別の新聞に販売されているソフトウェア製品を所有するこの仮想例で

      (The Times) 
          ----MASTER--- 
      WSJ-MASTER---| | | |---FT-MASTER 
       |  |  | |  |  | 
       |  |  | |  |  | 
       | WSJ-RELEASE | |  |  FT-RELEASE 
      |---  |  | |  |    | 
      |  WSJ-HF1 | |  FT-FR1  |---FT-HF1 
    WSJ-FR1--|     | |      | 
      |  TIMES-BF1--| |--TIMES-RELEASE  |---FT-HF2 
    WSJ-BF1--|     |    |    
        TIMES-FR1--|    |--TIMES-HF1 

、タイムズは、当社のコアプラットフォームと考え、我々はわずかな変化（したがって二股マスター）を生成します。

私たちはウェブサイトの1つのバージョンのみをサポートしているため、「リリース分離」は必要ありません。 「マスター」の左側には、すべて新しい開発（コードベースの大幅な変更のための機能強化/バグフィックス/フォーク）があります。右側

は、私たちは常に生産にあるものと一致している「リリース」の枝を持っているので、我々は簡単にホットフィックスのためにそれを分岐することができます。

は最後の数日間のためにそれを使用します（私はそれが時間の哀れな量だ感謝）とこれまでのところは良いです！