4

私は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 のワークフローを使用している他のユーザーは、この状況にどのように対処しましたか?

4

1 に答える 1

0

クライアントを現在のバージョンに移行できない場合、7.2 タグから新しいブランチを開始することはできません。

ただし、72bug ブランチのバグを修正してリリース 7.2.x ブランチと現在の機能ブランチの両方にマージするのではなく、現在の機能ブランチのバグをgit cherry-pick修正してから、修正を にバックポートするために使用することをお勧めします。リリース 7.2.x ブランチ。これにより、履歴がきれいに保たれるため、現在の開発が、1 つのクライアントのニーズのために突然古いバージョンに依存しているように見えることはありません。

于 2013-06-06T19:58:37.650 に答える