私はAdam Dymitruk の git workflowを読んでいますが、それはすべて理にかなっています。
議論が見つからないことの 1 つは、古いリリースのバグを修正することです。7.0、7.1、7.2、7.3、7.4、7.4.1、7.4.2、7.8、8.2、および最新の 8.3 にタグが付いた「マスター」ブランチを想像してください。
特定のクライアントの本番環境はバージョン 7.2 で、バグが見つかったため修正する必要があります。
8.3.1 で修正してクライアントを 7.2 から 8.3.1 に移動することは、クライアントには受け入れられません。
では、これに推奨されるワークフローはありますか?
7.2 タグからマスター ブランチのフォークを作成し、このブランチを release-7.2.x と呼びます。次に、'release-7.2.x' をマスター ブランチを扱うように扱います。ベースラインから機能ブランチを作成します (72bug)。バグなどを修正し、最終的に機能ブランチを「release-7.2.x」にマージし、ビルドを行い、7.2.1 タグを作成し、本番環境に投入します。'release-7.2.x' はマスターと同様に永久に存続するため、7.2.x に対する修正は release-7.2.x で行うことができます。
もちろん、現在の作業のために 7.2 からの修正を失いたくないので、現在のマスター ベースライン (8.3) から機能ブランチを作成し、バグ ブランチ (72bug) をこの機能ブランチにマージすることができます。この機能ブランチは、現在のリリース サイクル/スプリントの他の機能と同様に扱われます。したがって、サイクルの終わりには、最新のベースライン (8.4) にバグ修正が含まれます。
Adam のワークフローを使用している他のユーザーは、この状況にどのように対処しましたか?