Gitを使用するときに新しいブランチまたは新しいリポジトリを開くタイミングを決定する方法は？
現在、X社の製品を作るプロジェクトに取り組んでいます。私が取り組んでいるチームは、同様のサービスを多くの企業に販売しており、コードの40％が再利用され、60％が特定の会社向けにカスタマイズされた機能を提供しています。以前は、最近gitを使用するよう提案するまで、バージョン管理はありませんでした。 Gitを導入した後、お互いの作業を繰り返しコピーして貼り付ける必要がないことを嬉しく思いますが、新しいプロジェクトを以前の製品のリポジトリの新しいブランチ（つまり、すべての製品の1つのリポジトリ）として開くと少し混乱します別の会社へ）または新しいスタンドアロンのリポジトリ（つまり、異なる製品用の1つのリポジトリ）として
通常、さまざまな企業の製品をマージすることはありませんが、よくある機能がよく見られる場合は、それらの機能をさまざまな企業のすべての製品に（年に1回または2回）ギフトとして追加したい場合があります。この場合、新しいリポジトリを開くか、新しいブランチを開始する方が良いでしょうか？
コードの40％は再利用され、60％は特定の会社向けにカスタマイズされた機能です
これが実際にできるようになるまでには少し時間がかかるかもしれませんが、その40％を抽出して独自のリポジトリーにすることが目標だと思います。これは、作業するメインライブラリ/フレームワークです。
その後、残りの60％はクライアントごとに専用のリポジトリに置くことができます。
あなたのコードベースは「レガシー」として認定されているようですので、Michael Feathersのレガシーコードで効果的に動作するを自分とチームで入手することを強くお勧めします。これは、コードをテスト対象にするための手法を提供します。これは、コードをライブラリーに抽出する計画を作成するためにも使用できます。
これからどうやって始めますか？これが私がすることです：
- すべてのクライアントを独自のリポジトリにする（または、GithubやGitlabなどを使用してgitリポジトリを管理していて、クライアントに複数のリポジトリがある場合は、クライアントごとに組織を作成できますが、クライアント）。
- 私がよく再利用しているクラスを取り出し、それを抽出します（オブジェクト指向のアプローチを想定していますが、機能的なアプローチでも同様の原則が必要です）。これを使用して、ライブラリー・リポジトリーを開始します（これにより、1日目から役立ちます）。まだ完全なクラスがない場合は、クラス化されていないコードからクラスを作成する方法を示すため、ここでFeathersの本が登場します。その間、基本的なテストを追加して、期待どおりに動作することを確認できます。
- この抽出を独自のものとしてコミットします。これをテンプレートとして使用して、すべてのリポジトリに変更を複製できます。
- 共有パーツを見つけたら、それらを抽出して、このライブラリリポジトリに追加します。
- ライブラリが大きくなり、一部のクライアントでは使用されているが他のクライアントでは使用されていないものを見つけた場合、モジュール化アプローチに取り組み、大きな機能を独自のリポジトリに抽出し、「モジュール」または「プラグイン」としてメインシステム。あるいは、特定のアイテムのグループ（認証や支払い処理を扱う束など）のテーマがある場合は、それらを独自のリポジトリーに抽出できます。正確には、この段階でどのように進むかは、コードの性質とそれを使いたい方向によって異なります。
このシステムの利点は、共有アイテムをライブラリに追加し、それを機能させるために必要なすべてのフックを配線するだけで済み、すべてのクライアントが利用できることです。コピーパスタは必要ありません。
なぜこれは枝の代わりに？技術的には、ブランチはスタンドアロンのリポジトリと大差ありませんが、慣例はそれらを区別します。リポジトリは完全なプロジェクトであり（サブモジュールまたはスクリプトを介して依存関係を参照する）、ブランチは通常、プロジェクトの特定の状態です。機能を追加したり、バグを修正したり、別の種類の変更を加えたりするときに分岐しますが、システム自体は同じと見なされます。プロジェクトが別のリポジトリと見なされた場合（この場合は、独自のカスタマイズなどを備えた別のクライアントの場合）、新しいリポジトリを作成します。
この良い例は、Oracle OpenOfficeとLibreOfficeです。 LibreOfficeはOpenOfficeのフォークであり、同じ人々によって保守さえされています。ただし、LibreOfficeは、技術的にOpenOfficeと同じであったとき（最初に分岐されたとき）でも、別の製品と見なされていました。その後、チームはOracleブランドを取り除き、LibreOffice独自の開発パスを開始しました。これは、現在OpenOfficeとは異なります。 LibreOfficeに加えられた変更はOpenOfficeのブランチに入る可能性がありますが、LibreOfficeは別のプロジェクトと見なされるため、代わりに独自のリポジトリーが必要でした。
あなたの質問には2つの別々の問題があります：
- 同じリポジトリで新しい製品を起動しますか、それとも新しい製品を開きますか？
これは好みの問題です。一部の製品は、すべての製品を単一の巨大なレポに保持します。一部の製品は、個別のユニットごとに新しいレポを開きます（単一のファイルのみが含まれている場合でも）。両極端の健全なバランスを見つける人もいます。
とりあえず、共通ライブラリを1つのリポジトリに配置し、関連のない最終製品をそれぞれ独自のリポジトリに配置します。
- 新しいブランチを開くか、新しいリポジトリを開きますか？
これが問題になることはありません。あなたは同じリポジトリに新製品を置くことに決めるかもしれません。その場合、新しい（機能）ブランチを開き、そこで製品の開発を開始し、安定したら、それをメインブランチにマージして戻し、機能ブランチ。
ほとんどの場合、gitブランチは長いコミットと考えることができます。最終的にそれらはメインブランチにマージされ、あなたはそれらを削除します。
一方、永続的な保守ブランチがあります。ただし、それらの機能開発は行いません。
だから私の答えは：新しい製品を同じリポジトリに追加する（メイン製品にも新しい製品が存在する）か、新しいリポジトリを作成するかを決めることができます。ただし、分岐メカニズムを悪用して、同じリポジトリ内で別の製品を開発しないでください。
チェックアウトすることをお勧めします AtlassianのGitチュートリアル
概念的には、選択に大きな違いはありません。共通の祖先がある限り、2つのリポジトリからブランチをフェッチし、それらの間で自由にマージ/差分/何でもできます。
主な違いはアクセス制御です。リポジトリレベルでのアクセス制御は非常に簡単で、ブランチレベルでは非常に困難です。クライアントにコードのみへのアクセスを許可する場合は、独自のリポジトリを作成する必要があります。
もちろん、両方を行うことができます。内部的には、顧客ごとに1つのブランチを作成し、そのブランチだけを顧客がアクセスできる外部リポジトリにプッシュするスクリプトを作成できます。
ただし、顧客ごとに別個のブランチを維持することは、一般にコードを設計する最良の方法ではありません。後でメンテナンスするのが非常に難しくなります。コードをすべてmasterにある再利用可能な共通モジュールに分割すると、通常ははるかに保守しやすく、モジュールを取り込む小さなカスタムパーツが各顧客に提供されます。できるだけ多くのコードを共通モジュールに挿入してみてください。