柔軟な機能のためのGitワークフロー
私たちのチームは、コードベースを維持するためにgitflowアプローチを使用しています。しかし、私たちが苦労しているケースが1つあります。
次の場合、developから作成された2つの機能ブランチ（feat/A、feat/B）があります。 feat/Aが完成したので、それを開発にマージします。この機能は現在developにあり、masterへのマージがテストされるのを待っています。
そして今、feat/Bをマスターに入れることは非常に重要です（通信エラー、クライアントはそれがすでに存在することを予期していましたが、何であれ）。この場合、feat/Bは100％終了していませんが（これが、今のところdevelopにマージされない理由です）、現在のバージョンは安定しており、すぐに使用できます。
それで、どうやってそれに対処しますか？
次のことを行うように指示されるため、gitflowを当てにすることはできません。
- Feat/Bを
developにマージします developをmasterにマージします（release/Xについては触れませんが、原則は同じです）
しかし..覚えておいてください、developには製品に投入する準備ができていない特技Aが含まれています。したがって、developをmasterにマージすることはできません。
私が持っている解決策は次のとおりです。
- Feat/Bを
developにマージします - Feat/Bを
masterにマージします
したがって、この方法では、マスターには特技Aが含まれていません。このソリューションは機能しますが、大規模なプロジェクト（何十人もの開発者が同じリポジトリで作業している）ではスケーラブルなプラクティスではないようです。今、私たちは3〜4人の開発者なので、お互いにすばやくコミュニケーションをとることができますが、大規模なチームでは実際には不可能です。
Gitflowモデルでは、この状況は修正プログラムと見なされます。この場合、マージでdevelopの準備ができていない他の変更がmasterから取り込まれないと仮定すると、処方箋はまさに提案したソリューションです。 _。マージwould不要な変更を取り込む場合は、rebasefeat/B最初にmasterに。
これを修正プログラムとして扱うことをお勧めします。リベースfeat/B off master以降のチェリーピックは、マスターを開発するか、開発にマージするために変更されます。