Gitプロジェクトの組織
私の会社では現在、メインバージョンコントロールとしてSVNを使用しており、Gitへの移行を進めています。そうすることは、構造の再編成を行う絶好のチャンスです。
その前に、現在の状況と使用例について説明しましょう。 1つのメイン製品と、カスタマイズされた20種類のクライアントがあります。つまり、クライアントAが自分のニーズに合わせてカスタマイズされたプロジェクトのモジュールを必要とする場合、それを実行します。
そのため、現在、独自のリポジトリを持つデフォルトのバージョンが用意されています。各クライアントには、デフォルトのリポジトリとは別の独自のリポジトリがあります。ロジックは、composer.jsonを介したクライアントリポジトリが特定のタグ付きデフォルトバージョンで表示されることです。一部の内部ロジックでは、クライアントプロジェクトでオーバーライドが優先されるため、カスタマイズに関してメインプロジェクトに触れないでください。 SaaSは可能ではありません。オンプレミスインストールが必要です。
これが、私たちのニーズに合ったモデルとして現在私が見ている唯一の方法ですが、1つではなく20個のリポジトリを維持する必要があるのはかなり面倒です。
ソリューションとそれらが機能しない理由
- 私の最初のアイデアはgitサブモジュールを持つことでした。ただし、リポジトリを統合できなかったため、これは現在の状況とまったく同じです。
- その他のアイデアは、
Clientsフォルダーを含む単一のリポジトリーを用意し、ビルドするプロジェクトに応じて特定のフォルダーを取得するようにJenkinsを設定することでした。ただし、クライアントには更新がいつどのように行われるかについての厳しい要件があり、強制することはできないため、これは失敗します。つまり、クライアントがv1.0を持っている場合、修正を提供する契約を結んでいますが、クライアントはv2.0に行く義務はありません。したがって、この構成では、開発が進んだ場合、v1.0をターゲットにすることはできません。 - 最後に重要なことですが、各ブランチが個別のクライアントになるGitフローをセットアップする計画がありました...したがって、各クライアントにmaster、dev、featureブランチもあり、1つのリポジトリに約
20*3=60ブランチがあることを意味します。これはいくつかの厳しいルールで管理できますが、v1.0に20のクライアントがあり、そのうちの1つがバージョンのバグに気付いた場合、マスターで修正を行い、その修正を各ブランチに手動で伝達する必要があるため、ここに問題があります。さらに悪いことに、デフォルトのマスターが開発を続けており、現在v2.0にいる場合、クイックフィックスを導入すると、コミットを選択して他のXブランチに伝達することになります。
ここに表示されていない、私のモデルに合う他の解決策はありますか？
私にとって、それは単一のリポジトリとクライアントごとのリポジトリの間の決定です。あなたが言ったように、クライアントごとのブランチのアイデアは私には合理的ではないように見えます（複雑すぎる、利点がない）。
今、私は両方のアプローチで作業しており、複数のリポジトリよりも単一のリポジトリの利点は私にあります：
- 開発の容易さ：1つのチェックアウトですべてのクライアントを取得し、20のワークスペースをセットアップする必要はありません（gitサブモジュールも役立ちます）
- タグとブランチはすべてのコードを保持します。
v1.0は1つだけです。私がそれを正しく理解していれば、すべてのクライアントで同じバージョン番号を使用するので、それはあなたにとって利点です。
他の人がすでに2.xを使用しているのに、顧客がまだ1.xブランチを使用しているという懸念がありました。これにはブランチを使用することをお勧めします。 masterブランチに2.xコードが含まれている場合でも、別のブランチの1.xコードで作業し、そのブランチからリリースを開始できます。
あるプロジェクトでは、これを「世代」と呼びました。 masterがありましたが、ブランチgeneration/1.xにも取り組んでおり、バグ修正、リリース、または機能ブランチを開始しました。世代間（またはマスター）のコミットはいつでもチェリーピック（SVN：「マージ」）できます。最後に、1人の顧客が2.xに移動した場合、彼のディレクトリをmaster（または適切な世代）に移動できます。
私にとって、主な懸念はスケーリング（またはレポサイズ）です。クライアントの数が増えるか、コードベースが大量のディスク領域を使用する場合、1つのレポの処理が難しくなる可能性があります。
1つの主要な製品と、カスタマイズされた20種類のクライアントがあります。
この種の分離は、ソース管理がサポートするように設計されているものではありません。クライアントごとに1つのリポジトリが必要です。
クライアントごとにコードベース全体を複製するのではなく、コードを変更して、コードを可能な限り多くのライブラリー*に分割し、それぞれに独自のリポジトリーを作成する必要があります。すべてのクライアントで共有できるライブラリの数を最大化することを目標としているため、ライブラリごとに1つのリポジトリのみが必要です。
*責任の境界と疎結合について賢明である
私は結び目を切り、まったく異なるソリューションを提供します。
異なるリポジトリーから異なるクライアントに異なるコードを出荷する代わりに、すべてのコードを統合し、バージョンを出荷し、構成を介してカスタマイズを制御するか、または顧客が望むものと矛盾しない場合は、機能または拡張機能として1つのクライアントのカスタマイズを出荷します他のクライアント用。
もちろん、これはビジネス上の決定の一部ですが、アプリケーションの詳細がそれをサポートしている場合は、フロートする価値があるかもしれません。