GitFlow：最初に、または製品リリース後にマスターにマージしますか？
GitFlowを学ぶと、私が読んだドキュメントや記事で取り上げられていない懸念がいくつかあります。
ある時点で、developブランチのコードをQA /ステージング環境にデプロイし、厳密にテストする必要があります。したがって、GitFlowを使用して、releaseブランチをdevelopから切り離し、次にreleaseを上記のステージング環境にデプロイします。
まず、何かをすぐに明確にしたかったのです。特定のプロジェクト/リポジトリがこのプロセスを初めて実行するとき、実際にはreleaseからこの新しいdevelopブランチをfork/createすることになりますyes？そして、将来的には、あなたは単にmergingdevelop into release、yes？
したがって、QAはステージング環境のreleaseブランチをテストし、すべて問題なく見えるようになり、製品にデプロイする準備が整いました。あなたは：
- 製品にデプロイしてthen
releaseをmasterにマージしますか？ ; または releaseをmasterにマージし、then製品にデプロイしますか？
前者の場合はneedにreleaseブランチをprodにデプロイし、次にprodにデプロイしてからmasterにマージするように思われるので、質問します。大丈夫に聞こえますが、実稼働環境と非実稼働環境は同じではなく、ステージングチョークで完全に正常に実行されるコードは、2番目に実稼働サーバーで起動します。 GitFlowがhotfix branchの概念をサポートしていることを知っていますが、それらはマイナーな修正のために予約されています。ロールバック/バックアウトリリースを必要とする複雑な修正の場合、「ダーティコード」（何らかの理由でprodを壊すコード）がmasterにマージされました。
後者の場合、マージして製品リリースリクエストを入れてから実際に製品がデプロイされるまでに、数時間または数日かかることがあります（特に、製品のデプロイを実行するためにIT/Opを含める必要がある場合）。 。そしてこの間、「機能X、Y、Zは製品版にある」というmasterブランチがありますが、実際にはそうではありません。
GitFlowが実際にこれを何らかの方法で解決するのか、またはどちらの場合の既知の回避策があるのかと思います。
作成するリリースブランチは、作成する機能ブランチと同様に、存続期間の短いものです。リリースが完了したら、ブランチを削除します。たとえば、release/0.1.0ブランチ、作業を行い、マージします。
本番環境にデプロイするときは、常にマスターブランチからコードを取得します。つまり、デプロイする前に、まずリリースブランチをマスターにマージします。
GitFlowは、後退ではなく、前進するためのものです。したがって、特定された問題の修正を作成するためにホットフィックスが使用される理由。
本番環境に入るまでの時間に関しては、これはGitFlowの懸念事項ではありません。この分野で多くの助けになるとは思いません。これは、使用する分岐戦略に関係なく、問題になります。
私が取り組んでいるプロジェクトは非常に無秩序で、決定は分の問題で変わるので、私の戦略はできるだけ先延ばしにするソフトウェア構成管理の決定です。
特に、マスターへのマージ：本番環境にデプロイした後にのみマスターにマージしますと、スモークテストが機能した確認メールfineがあります。このようにして、決定の変更、デプロイのロールバック、技術的な問題、または発生する可能性のある問題のリスクを管理することで、混乱を受け入れます。
最初は本番環境に移行する前にマスターに統合しましたが、技術的な問題、ロールバック、管理の決定がぎりぎりで発生したため、多くの問題が発生したため、戦略を変更しました。年。
最終的に、本番環境に移行した後に何らかの回帰が見つかった場合、それはhotfixであり、そのように処理する必要があります:)
実際、この新しいリリースブランチを開発からフォーク/作成します。そうですか？
それは正しいです。初めての唯一の選択肢は、メインブランチからreleaseブランチを作成することです。これは、QA /ステージング用にデプロイし、後で本番環境にデプロイするものです。
そして、将来、他のすべての時間で、開発をリリースにマージするだけですよね？
場合によります。 Gitフローの説明によると、リリースブランチは短命ブランチです。 developからのみ分岐し、masterにマージされる場合があります。理論的には、リリースが完了した後、releaseをdevelopにマージし、その後削除する必要があります。リリースにマージする必要があるのはhotfixだけです。これはいい流れです 記事 フローについてです。
これは、チームごとに異なります。私はGitFlowの説明に正確に従っているチームと、releaseを削除して、それを初めてのように開発から再作成することを選択したチームで作業しました。
製品にデプロイし、リリースをマスターにマージしますか？;またはリリースをマスターにマージしてから製品にデプロイしますか？
理論的には、マスターはalwaysに本番対応のコードを含める必要があり、本番にデプロイされるものはexactlyマスターブランチの内容。とは言っても、特にyourチームで何が機能するかについては、完全な答えは得られないでしょう。
たとえば、私は現在、CI/CDパイプラインを使用してチームで作業しているため、前にマージする以外に選択肢がありません。展開は、masterから自動的に行われます。リリースが離れすぎているチームをいくつか見て、代わりにreleaseブランチをデプロイし、その後マージすることに自信を持っています。これにより、release-> masterマージ中に発生する人為的エラーの展開を回避できます（これには、時間の経過とともに蓄積される厄介な競合が含まれる可能性があります）。
GitFlowがすべての可能なシナリオとコンテキストをカバーしているわけではない可能性があるので、あなたはあなたに最適なソリューションを選択するべきだと思います。