0

特定の方法で動作するように複数の git リポジトリを設定する方法 (可能であれば) を理解しようとしています。基本的に、複数のクライアント用に複数のリポジトリがありますが、それらはすべてシステム ディレクトリを共有することを意図しています。1 つのクライアントのシステム ディレクトリに変更を加える場合は、すべてのクライアントのシステム ディレクトリに変更を加える必要があります。複雑なことに、CI 開発システムに使用する複数の環境があります。現在、本番環境、クライアントrev環境、qa環境、開発環境があります。これらは、ワークフローが次の環境で承認されたときに、そのワークフロー ブランチを適切な環境ブランチにマージし、そのワークフローからの変更のみをその環境に追加できることを意味するため、さまざまなブランチに適切に変換されます。

問題は、コード構造が、ベース コードであるシステム ディレクトリ、クライアント固有のコード (システム コード内のファイルの代わりに使用されるファイルを含む) を持つカスタム ディレクトリ、およびクライアント固有のディレクトリを持つように設定されていることです。構成ディレクトリ。カスタマイズを容易にする継承や拡張がないため、開発をさらに複雑にするオブジェクト指向システムを使用していないことに注意してください。

私たちの目標は、この開発システムを GIT に変換することです。私たちが抱えている問題は、その共有システム ディレクトリを維持することです。サブモジュールを試してみましたが、サブモジュールは上書きやミスポイントを防ぐために多くのメンテナンスを必要とし、クライアントのqaブランチが常に指していることを確認するための過度の退屈な作業量のため、永続的な環境ブランチではうまく機能しません.システム サブモジュールの qa ブランチのリード コミットであり、WF ブランチのリード コミットではありません。

私たちの現在の IDE は、サブツリー統合を持たない eclipse です (ただし、サブツリーについて私が読んだことは、サブツリーはサブモジュールと同じくらい複雑になる可能性があるということです)。本当に必要なのは、伝播される複数のリポジトリにまたがる並列ブランチです。たとえば、クライアント リポジトリでワークフロー ブランチを作成すると、システム リポジトリと他のすべてのクライアント リポジトリで WF ブランチが作成されます。そして、変更を加えてそのワークフローを qa にマージすると、システム リポジトリの wf ブランチも qa ブランチにマージされますが、システム フォルダーへの変更のみがあり、custom および config ディレクトリに加えられた変更は含まれません。

このようなものを機能させるための良い構造があるかどうか疑問に思っていました。私が他のサイトや情報源で読んだことはすべて、解決策はそのようにしないことだと言っていますが、その決定は私が行ったものではありません. 上層部は、現在の開発システムを維持することを決意しています。

私が考えたことの 1 つは、システム モジュールだけを含むリポジトリを作成するパススルーのようなことを行う方法があるかどうかを確認することです。次に、クライアントごとにそのレポを複製し、custom ディレクトリと config ディレクトリを追加します。次に、開発を行うときに、そのクライアントのリポジトリを複製します。この方法で、変更を加えてコミットしてアップストリームにプッシュした場合、これにより変更がトップレベルのリポジトリにプッシュされるかどうか疑問に思っていました。また、変更をプルダウンするときに、最上位のレポからずっとプルできる場合。これの反対側は、ストリームをプッシュするときにカスタムおよび構成ディレクトリを無視するが、ダウンストリームにプルするときにそれらのディレクトリが含まれるように、クライアントリポジトリに .gitignore を設定する必要があることです。

これに関する任意の考えをいただければ幸いです。また、コード ホストはプライベート gitlab サーバーです。

長くなって申し訳ありませんが、少し説明が必要な非常にユニークな (良くない) システムがあると思います。

将来の Git ユーザー

4

1 に答える 1

1

これは git の問題というよりも、組織とアーキテクチャの問題のように思えますが、やってみます。

リポジトリを作成するのではなく、クライアントごとにブランチを作成し、必要に応じてマージ/プルしてからプッシュすることを検討しましたか?

git によるデプロイはお勧めしません。git はデプロイに適した方法ではありません。その設計はオープンで、変更を記録し、コードを簡単に共有できるため、誰かが誤って資格情報をコミットした場合、何かクレイジーなことをしない限り、資格情報は永久に記録されます (そして、これらのクレイジーなことで他の人のコードが壊れてしまいます)。ほとんどの健全なユーザーは、git を使用して変更をコミットおよび共有し、特定のブランチを module/pkg/image/container/something-stable-and-constant に構築してから、そのモジュールを他の場所のクライアントにデプロイします。

それでもデプロイに使用したい場合は、git-hooksをチェックアウトしてください。ブランチが更新されたときにコードを自動的にプルするいくつかのフック (例: update または pre-receive) をセットアップできます。

もう 1 つの選択肢は、共有ディレクトリのすべてをクラウド ストレージ サービスまたはドキュメント ベースの NoSQL サーバーに移動することです。誰もが取得できる単一のソースを維持するのに役立ちます。これは完璧ではなく、最終的な一貫性によってあちこちで問題が発生することはほとんどありませんが、それだけの価値はあります。ファイルがクライアントのディスクにすぐにあることが重要な場合にのみ、それに対してアドバイスします。

于 2016-09-21T23:10:06.483 に答える