複数のデプロイ可能なgitブランチ
私のジレンマはGITフローについてです。
異なる方法でデプロイできるアプリケーション（ステージングリリース、QAリリース、本番リリース）があると仮定しましょう。
アプリケーションにはprofilesステージングバージョンまたは本番バージョン（実行可能ファイルがどのブランチであるかには依存しません）として同じバイナリで実行されるため、作成するのは本当に役に立たないと思いますつの異なる展開可能なブランチですが、バイナリの目的を明確にする必要があるため、正しいと考える同僚もいます。
私にとって間違っているのは、stagingブランチをチェックアウトしたら、ステージングとしてデプロイを強制する必要があることです（本番バージョンを選択することは引き続き可能です）。この問題は避けられないので、3つの展開可能なブランチは役に立たないと思います
これは彼らが考えている状態です：
- ブランチマスター：バイナリ+すべてのプロファイル
- ブランチステージング：同じマスターソース
- ブランチqa：同じマスターソース
彼らはただアイデアを整理したいだけです（私はそうは思いません）
両方とも正しいですか？
必要な場所に必要なブランチをデプロイします。
さて、明らかに、機能ブランチを本番環境にデプロイするつもりはありません。ただし、最新のビルドをマスターから開発にデプロイすることは問題にはなりません。
Git-flowの開発ブランチは、メインラインになることです。通常のプロセスでは、そこから分岐してマージする必要があります。このプロセスの唯一の例外は、本番環境から電流を取得する必要があるホットフィックスブランチの例外です。
その修正プログラムをもう少し見て、3つの場所がある場合の展開プロセスを考えてみましょう。おそらく、新しいホットフィックスをdevにデプロイし、そのブランチでいくつかのコミットを行い、それをQAにデプロイしてからprodにデプロイします。
Git-flowを使用した通常のリリースプロセスでは、developmentブランチの開発サーバーからビルドが行われる可能性があります。 releaseにブランチすると、ブランチのヘッドが開発サーバーに移動し（リリース作業に取り組んでいる開発者が現在の状態を確認できるようになります）、特定のタグ付きブランチがに移動します。 QA。 QAがタグ付けされたビルドの1つを承認すると、そのタグのリリースブランチがmasterにマージされ、次にmasterがタグ付けされ、本番環境にデプロイされます。
おそらく開発用に複数の環境が必要になります。 releaseのヘッドは1つのデプロイメント環境であり、developmentのヘッドは別のデプロイメント環境であり、featureのヘッドでさえ別の1つまたは5つである可能性があります。
任意のデプロイメント環境プロファイルの任意のブランチを構築できるはずです。現在の本番環境を開発サーバーにデプロイすることは実行可能であるはずです。
Git-flow自体は、物をデプロイする場所と直交しています。それは、さまざまなブランチが果たす役割のセットが制限され、定義されていることを確認することです。役割を制限することにより、各ブランチが実行していることと、その時点での状態について推論することが容易になります。
Git-flowが特定のものが展開される場所について言おうとしているのは、masterの先頭が本番であるということだけです。環境内のどこに展開するかについての他のことは、サイト固有の問題です。 Git-flowは、本番サーバー、ステージングサーバー、QAサーバー、開発サーバー、および数十の機能サーバーを使用する場合と同様に、1つの本番サーバーと開発者がローカルサーバーに他のすべてのデプロイを行う場合と同様に機能します。
特定のサーバーへの展開を行うための手順は、完全にそのサーバーのローカルワークフローまでです。