従来のGit分岐モデル内で環境固有の変更を適用するにはどうすればよいですか？
私は古典的な分岐と展開モデルを言っていると理解しています（以下の小さな変形例）：
- 開発ブランチに変更を加えます
- マージ開発>ステージングブランチ、ステージングサーバーにデプロイ、テスト
- devのマージ>本番ブランチ、本番サーバーのデプロイ。
- ステージングまたは本番ブランチで直接コミットしないでください。 devからこれらのブランチへの変更のみをマージします。
私の問題はポイント（4）にあります。開発、ステージング、本番のどちらで実行しているかによって異なるファイルがいくつかあります。これらには、robot.txt、サーバー起動ファイル（ステージングはHerokuにあり、プロダクションがEC2にあるときにProcfileで起動するなど）などが含まれます。展開バージョン固有であり、アプリケーションバージョン固有ではありません。
上記の分岐モデルは、完全なデプロイメントの実行直後に、本番=ステージング= devと言っているようです。ただし、異なる環境間の調整のためのスペースは残されません。
これは業界でどのように解決されますか？
=====考えられる解決策=======
各環境で環境変数を使用する。コード構成スイッチのジョブを実行します。私はすでにこれを使用していますが、これがアプリケーションコードの外にある変更にどのように影響するかはわかりません。
ステージングブランチとプロダクションでコミットとしてデプロイメントの変更を直接追加し、開発からのアプリケーションの変更をマージします（たとえば、ステージングでは、本番とは異なるバージョンのrobot.txtが維持されます）。矛盾するようです（4）
- Gitは、コードのさまざまなバリアントの管理には適していません。
- Gitはデプロイメントメカニズムではありません。
- Gitは単なるソースコード管理システムです。
git Pushを栄光のFTPコマンドとして使用するときに失われる1つのことは、ソースコードがソースコードであり、展開するものとは必ずしも同じではないということです。これは、ソースコードを直接実行できるインタープリターシステムにも当てはまります。
これを解決する1つの方法は、必要なファイルを収集して特定のターゲットにデプロイするビルドおよびデプロイメントプロセスを導入することです。 Gitのソースツリーは、開発モードで実行するには有効な状態になる可能性がありますが、本番環境のターゲットでは、異なる構成ファイルが使用されます。たとえば、必須ではありませんが、Dockerイメージはこのような展開形式にすることができます。
デプロイターゲット（Herokuなど）がGit経由でのデプロイを想定している場合、デプロイされる状態を含むソースコードとは別のリポジトリまたはブランチを使用することが可能です。これはややハックに感じますが、実際には非常にうまく機能します。ただし、このブランチ/リポジトリには、バージョン管理が必要なソースコードは含まれていません。これは、ほとんどの場合、実際のソースコードの複製（いつでも再構築できる）であるためです。したがって、これらのブランチをプルーニングすることが望ましい場合があります。また、デプロイされたコミットと対応するソースコードコミットの間の直接の関連付けが失われます。 Herokuは、Gitを乱用しない他の展開タイプも提供する可能性がありますが、私はそれらを認識していません。
配備ターゲットで配備前のスクリプトを実行できる場合、それは別のソリューションになります。このようなスクリプトにより、必要な環境をセットアップできます。このスクリプトを機能させるには、このスクリプトを他のターゲットで無視するか、実行されているターゲットを検出できます。
いずれの場合でも、リリースプロセス中に、devにマージされることが予期されないデプロイメントターゲット固有のコミットを追加することは、アンチパターンです。これらはマージで削除されるか、他のブランチの履歴の一部になることはありません。 Gitは、他のブランチをマージしたい場合に、1つのブランチにのみ存在する一連の変更を維持するのは得意ではありません。