gitワークフローを手伝ってください
州内の複数の地域にデプロイされるWebアプリケーションがあります。各リージョンのアプリケーションのインスタンス。リポジトリにステージングと本番（マスター）ブランチを維持していますが、各インスタンスのコードベースを維持するための最良の方法は何かと考えていました。コアは似ていますが、アプリケーションのコアにならない可能性のある特定のリクエストを各リージョンに実行できるようにする必要があります。
現在、region_one_stagingやregion_one_productionなど、リージョンごとにブランチがあります。私たちが成長している速度で、私たちは今後数年間でここに何百もの支店を持つでしょう。
これを行うためのより良い方法はありますか？
代わりに 抽象化による分岐 によってこれを回避できます：
概要：VCSを使用して異なる懸念事項を分離するのではなく、代わりに抽象化を使用してください。
地域の違いのためにVCSで分岐を開始すると、最も一般的な例は言語または国で分岐することですが、バリアント管理として知られる滑りやすい坂道に滑り込み始めます。これは、ソース管理自体を介してバリアントを管理することは、非常に管理しにくい方法であるためです。バリアントは、管理できない数に非常に迅速に成長する可能性があるためです。
これを繰り返しましょう：
VCSでのバリアントの管理IS恐ろしい慣行であり、指数関数的な比率の技術的負債を残します！
では、代わりに何をしますか？ええと、ブランチのバリエーションにVCSを使用しません。代わりに、抽象化を介してバリエーションサポートをアプリケーションに組み込みます。あなたの場合、アプリケーションは地域によって異なるので、アプリケーションにプラグイン可能なモジュールに変化するものを作ってみませんか？またはさらに簡単です。アプリケーションがロードする各リージョンの構成ファイルを用意し、構成されたリージョンに必要な機能を使用します。すべてを複数のブランチに膨らませるのではなく、すべてを1つの同じブランチにチェックインすることができます。
これは、抽象化による分岐の逸話的で、うまくいけば実用的な例です。
私の以前の職場の1つでは、Webサイトはヨーロッパの多くの国（言語とニーズが異なる）をサポートしています。新しい機能が機能アクセスリストに登録される場所に気の利いた機能ブロッカーがありました。最初はログインした開発者だけで始まり、テスターはリリースされていない機能にアクセスできました。後で、正しい地域のログインユーザーが機能にアクセスできるなど、国や言語のチェックを追加します。
このようにして、すばやく新しい機能をプッシュするか、必要に応じて本番環境ですばやく停止することができます。アプリケーション自体によって処理されるため、マージする必要はありません。
モジュールのわずかに異なるカスタムバージョンが複数ある場合、最終的には複雑さが圧倒され、コードを効果的に共有できなくなります。前もってもう少し作業が必要ですが、モジュールの使用方法と構成方法を区別して、コードをどこでも同じにする必要があります。
これは、異なるサイトでモジュールの異なるリビジョンを使用できないという意味ではありません。 gitを使用してこれを管理する最も簡単な方法は、各モジュールを独自のサブディレクトリとリポジトリに配置し、 submodules を使用して個々のサイトに必要な部分を組み立てることです。
このようにして、おそらく開発ブランチとリリースブランチを持つ1つの「コア」リポジトリ、独自の開発ブランチとリリースブランチを持つモジュールごとに1つの機能リポジトリ、そしてサブモジュールを使用してプルする数百のサイト固有の本番ブランチとステージングブランチを持つリポジトリがあります。コアの特定のバージョンとそれが必要とするモジュールで。
たとえば、特定のサイトのfeature1モジュールに変更を加えたい場合は、そのサイトの開発ブランチをcheckoutします。次に、modules/feature1ディレクトリで作業するときは、feature1の共有サブモジュールリポジトリで作業します。変更をプッシュすると、そのモジュールを使用する他のすべてのサイトで利用できるようになりますが、最新のリビジョンをプルしてテストすることを決定するまで、実際には変更を受け取りません。
数百のリージョンがあると予想されるために数百のブランチがあり、各リージョンの変更を本当に追跡したい場合、それは悪い計画のようには思えません。
ブランチはgitで安いです。
しかし、本当にそれをしたいのですか？ VCS /デプロイメントシステムに関係なく、実行中のコードの何百ものバージョンを持つことは避けるべきもののように思われます。
1つのリポジトリに共通のコードベースを持ち、それを必要とするサーバー専用に別のコードベースにカスタムのものを含めることは可能でしょうか？
たくさんの枝があるのは何も悪いことではありません。あなたのビジネスはそれを必要としているようです。代わりに、ブランチのサブセットに対して簡単に操作を実行できるように、ブランチの命名戦略を調べてください。
これは「機能ごとのブランチ」と呼ばれます。そのためのグーグルとあなたはフィーチャートグルでトランクから作業するよりも優れた方法でたくさんのブランチで実行する方法に関するたくさんのリソースを見つけるでしょう。
コードの大幅な変更を伴うカスタマイズの場合、これは必ずしも適切ではありませんが、変更をモジュール化できる場合は、適切である可能性があります。それを行う必要がある場合は、「ファイルXへの変更のみ」を引き続き確認できます。
git log filename.c
おそらくpre-とpost- hooks、またはおそらくsmudgeとcleanフィルターを、すべてを同じだが異なるものに保つための1つのメカニズムとして見てください。
https://stackoverflow.com/questions/5769846/recommended-git-workflow-for-test-and-production-instances の質問/回答をmayワークフローに適合