GitHub Flowはマスターにマージする前に本番環境にデプロイします：2番目の機能が最初の機能をオーバーライドしませんか？

GitHubフローを理解するために、ここで見られるように、コードレビューの後、機能は最初に本番環境にデプロイされ、次にマスターにマージされます。

最初の機能と同じコミットから分岐した2番目の機能があり、それも本番に直接デプロイされている場合、本番には最初の機能が含まれなくなります。

learngitbranching.js.orgで作成

c2がデプロイされたら、c2またはc4とマージする前にc3をどのようにデプロイできますか？

GitHub Flowはこの問題をどのように処理しますか？

明白な解決策は、本番環境にデプロイする前に、機能をマスターにリベースする必要があることです。ただし、これは人為的なミスが発生しやすくなります。リベースを忘れた場合、プロダクションには機能がありません。

特にGitHub Flowの使用経験のある方からの回答をお願いします。どのようにこの問題を抱えていませんか？

朗報！GitHubにはそれに関する記事があります！

彼らは3つの安全対策を識別します：

• テストに合格していることを確認してください。これは、ほとんどの展開ワークフローの一部であると期待されます。しかし、それは彼らが強調する「安全」対策の一つです。
• 必要に応じてデプロイメントパイプラインを「ロック」：機能ブランチが本番環境でデプロイまたは検証されている場合、他の誰もデプロイメントを開始できません。
• デプロイされたすべてのブランチに、デプロイ済みのすべての変更セットが含まれていることを確認してください。 これを行う方法はもう少し複雑です。彼らが言うことはここにあります：

この要件を確認するためにGitHub APIを使用します。github.comアプリケーションのエンドポイントは、現在本稼働で実行されているSHA1を公開します。これをGitHub Compare APIに送信して、マスターとプロダクションSHA1の「マージベース」、つまり共通の祖先を取得します。次に、これを、展開しようとしているブランチと比較して、ブランチが追いついていることを確認できます。マスターとプロダクションの共通の祖先を使用することで、ブランチにのみ存在するコードをプロダクションから削除できます。マスターに到達したが、まだデプロイされていない変更は、デプロイ前にブランチをマージする必要はありません。

ブランチが遅れていることが判明した場合、マスターは自動的にブランチにマージされます。これは、本日提供する新しい「マージAPI」を使用して行います。このマージにより、他のプッシュスタイルのイベントと同様に、新しいCIビルドが開始され、合格するとデプロイが開始されます。

マージAPIは基本的に標準のマージを実行しますが、サーバー側で実行します。

あなたのソリューションはおそらくそれほど洗練されている必要はありません。結局のところ、次のことを合理的に保証する必要があります。

• テストに合格
• 一度に1人だけがデプロイします
• マスターは展開前に機能ブランチにマージされます

この問題はあなたに起こりましたか、それとも理論的な質問ですか？

変更されたコードのみをプッシュするようにマージする場合、Gitは「十分にスマート」です。「問題」があると、マージの競合が発生します。

すべての新しい機能は、他の機能に基づく機能ではない開発ブランチに基づいています。

マージの競合を最小限に抑えるために行うことの1つは、頻繁にマージすることであり、機能を開始する前に、常に最新の開発をプルします。（私たちはマスターにコミットするのではなく、常に開発ブランチにコミットします。これはたまにマスターブランチにマージされます）