web-dev-qa-db-ja.com

Gitマルチレベル階層のフォーク管理

次のGit階層構造があり、各子は親からフォークされます。階層全体で役立つ何かをClient1で構築する場合、望まないことを前提として、変更を親にプッシュする最良の方法は何ですか（1つ上のレベルにあるか、ルートに至るまで）。すべてのクライアント固有のカスタマイズをチェーンにプッシュします。

現在、理想的なソリューションは必要な最高レベルで開発を行うことかもしれませんが、モジュールは、すべてのカスタマイズがインスタンス化されるチェーンの下流でのみ実際にテストできます。

例えば。 Client1リポジトリでModule-Newを開発し、それをコアにプッシュする必要がある場合、Client1のカスタマイズをコアで望まない場合、それを実行するための最良の方法は何ですか？一方、元々COREでModuleAを直接開発していた場合、変更をダウンストリームのClient1までプッシュして、Module-Newをテストする必要があります（すべての変更を繰り返す）。

これらのルールを確立するのに役立つGitワークフローやその他のツールはありますか？現在、GitFlowsを使用して、すべてのリポジトリのマスター、開発、機能ブランチを管理しています。また、リモートリポジトリへの直接プッシュを無効にする方法はありますか？

                            CORE
                              |
                ------------------------
            Product 1               Product 2
                |                       |
            ----------              ----------
        Client1     Client2     Client3     Client4
           |-v1.0   
           |-v1.1
           ...
architecturegitgithubworkflowsgitflow
4
Manish Jain

使用しているテクノロジーに応じて、リポジトリのダイレクトプッシュを無効にできます。プッシュの防止は、gitフックを使用してある程度行うことができますが、gitlab/github/bitbucketを使用している場合は、ブランチを保護する方法があるはずです。

すべてのブランチが保護されており、開発者が新しいブランチを作成できない場合、リポジトリにプッシュする方法はありません。このように、「マージリクエスト/プッシュリクエスト」またはその呼び出し方法を使用して開発を処理する必要があります。

実際に何を管理しているかは不明であるため、次の方法では解決しない場合があります。私の場合、すべてのクライアントにインストールされているコア製品があります。コア製品は異なるバージョンでインストールされている可能性があります。また、追加のモジュールを側面に取り付けることができます。どちらの方法でも、通常、クライアントのカスタマイズは、既存のモジュール（コアモジュールを含む）を拡張するクライアント用の特定のモジュールをインストールすることによって行われます。私の場合、クライアント向けのカスタマイズがコア製品に反映されることはありません。必要な場合は、モジュールをコア製品に移動するだけです。

カスタムモジュールが複数のクライアントで共有されている場合、各モジュールリポジトリのマスターでマージされる特別なブランチを使用することがあります。

結局のところ、コードが各モジュールのリポジトリのマスターブランチにバブリングしないと、かなり複雑になる可能性があります。私たちの場合、ほとんどの作業は、ビルドアウトを使用してリポジトリとマージおよび依存関係を管理することで実現されます。

私の意見

Gitリポジトリを使用して依存関係を処理することは、リポジトリをフェッチするだけの方が簡単に見える場合でも、開発に限定する必要があります。 Gitリポジトリは非常に大きくなる可能性があり、リポジトリが大きく、インターネット接続が不安定な場合、フェッチが失敗することがあります... Gitは部分的なフェッチを許可しないため、99％で失敗した場合は、とにかく0％から再起動する必要があります。

展開に関しては、パッケージマネージャーにそれを行わせる方が理にかなっていると思います。彼らは存在し、彼らは通常彼らの仕事をうまくやっています。パッケージマネージャーを使用する利点は、モジュールに付属する可能性のある変更の履歴全体をダウンロードする必要がないことです。通常、パッケージマネージャーはhttpを使用した部分的なダウンロードを許可しているため、インターネットに障害が発生した場合に後で更新を一時停止できます。優れたパッケージマネージャーを使用すると、クライアントごとに独自のプライベートパッケージサーバーをホストすることもできます。クライアントごとに類似しているモジュールはすべて中央サーバーにプッシュでき、カスタマイズされたパッケージはすべてクライアントごとにパッケージサーバーにプッシュできます。

パッケージのビルドプロセスとそれぞれのサーバーでのパッケージの展開を自動化する方法があれば、これはすべて問題ありません。

このように、クライアントが「パッケージ更新」のようなことを行う場合、クライアントサーバーでパッケージをチェックしてから中央サーバーでチェックし、これから適切なバージョンを取得できます。古いパッケージを削除する必要はなく、クライアントは必要に応じてセットアップをダウングレードできます。

私の推測では、それは誰かが実装できる最も良いものだと思いますが、私が知る限り、それを行うための標準的な方法はありません。 python卵、その他のdebianパッケージなどでそれをしている人がいると聞きました。しかし、各実装には固有の問題があります... debianパッケージはWindowsや非debianディストリビューションでは機能しません。 .. pythongの卵は、javascriptなどのpython .. npmパッケージにかなり限定されています。ユニバーサルパッケージマネージャーがあり、それを実装するだけの簡単な場合。

1
Loïc Faure-Lacroix

ソース管理を使用してクライアントごとのコードのカスタマイズを管理することはお勧めできません。これは、ソース管理が行うように設計されているものではありません。

たとえば、あなたの場合、「新しいモジュール」がブランチのカスタマイズに依存しているかどうかを判断する方法はありません。したがって、それをマージして機能することを期待することはできません。

正しいアプローチは、プロジェクトをコンポーネントに分割し、クライアント用にカスタマイズされた新しいコンポーネントを作成することです。クライアントインスタンスをデプロイするときは、DIと構成を使用して、標準コンポーネントではなくカスタムコンポーネントを使用することを指定します。

すべてのコンポーネントは個別のリポジトリであり、パッケージマネージャーを介して公開されるため、他のプロジェクトに取り込むことができます

カスタマイズされたコンポーネント間で共通の機能が使用されている場合、これらは再び分割され、共通のコードは独自のモジュールにあり、カスタマイズされたコンポーネントはそれを参照します。したがって、コードを「レベルを上げて」移動したいシナリオでは、共通コンポーネントを編集して機能を追加し、カスタムコンポーネントを編集してコードから機能を削除しますが、共通コンポーネントの新しいバージョンを参照します。機能が含まれています

1
Ewan