古いタグからのgitの修正に関するベストプラクティス

Question

最近、gitでオープンソースプロジェクトの作業を開始し、Vincent Driessenのbranching modelに従って作業することに決めました。

私はこのモデルの背後にある理由を理解しており、それは良い選択のように広く推奨されていることがわかりました。

私はこのモデルには欠けていて、オンラインで見つけることができませんでしたが、古いリリース（タグ）用に修正プログラムを作成する必要がある場合には、この方法をお勧めします。

たとえば、私のマスターには最新のバージョン-2.0が含まれています。バージョン1.5と1.0のタグがあります。今、バージョン1.0で作業している顧客がそのバージョンのバグを発見したが、バグ修正が含まれている新しいバージョンに更新することは望ましくなく、単純にhotfix \ patchが必要な場合（ここで正しい用語がわからない場合） 。モデルによれば、この状況は処理されず、ホットフィックスはホットフィックスブランチ上で修正され、メインライン（master \ dev）にマージされます。しかし、私の例では、顧客は、（可能な限り）新しい機能なしでバグを修正するコミットの最小限のセットだけを望んでいます。

この場合、最善の方法は何ですか？タグ1.0から専用ブランチを作成し、チェリーピックコミットを作成する必要がありますか？問題を修正した最初のコミットから分岐し、それが簡単な場合は元に戻す必要がありますか？私はこのブランチを永遠に生き続けなければならないのですか？

私は場合に何をすべきかを知ることに興味がある：バグはすでにどこかで1.5と2.0

これは新しいバグであるとすべきとの間に、たとえば、以降のバージョンで修正されて

1. マスターに併合することもできます。

異なる分岐モデルのベストプラクティスへの参照は大歓迎です。

Answer 1

1. バグはすでにどこかで、たとえば、以降のバージョンで修正された1.5〜2.0

開発は、（例えば、合理的な流れを、次のされている場合：レトロ互換性、増分拡張を、など）、ユーザーのための最善の解決策は、最新のバージョンをチェックアウトすることです。

そうでなければ、タグ1.0から新しいブランチを作成し、そのブランチにサブバージョン（1.0.1）としてタグ付けして修正プログラムを選択する機会を考慮する必要があります。

次のコミットまたは少なくとも次のタグに同じポリシーを適用する必要があります。作成する必要があるタグリスト[1.0,1.2,1.3,1.5]を指定して、バージョン1.5でリリースされる修正プログラムを想定します。サブバージョン[1.0.1、1.2.1、1.3.1]。

2. これは新しいバグであり、マスターにマージする必要があります。

通常、修正プログラムは、マスターブランチのHEADが指すコミットから適用されます。

あなたのプロジェクトは他の人と共有され、同期ポイント（プッシュ/プル）に競合が生じるため、書き換え履歴はお勧めできません。最も合理的なソリューションを選択しますが、コミュニティと共有したコミットにはパッチを当てることはありません。

Answer 2

このバグはバージョン1.0でも見つかりましたが、実際は新しいものです。古いバージョンにはバグがないことを誰も確信できないので、新しいバグを発見するには、最新バージョンで修正する必要があります。あなたの状況のた​​めに、は2.0に基づいてバグを修正する必要があります。

masterブランチは（あるいは私たちは本番環境にそれを呼び出す）でホストされているメインコードであるので、あなたはmasterブランチにマージhotfixsブランチにバグを解決してからなければならないので。その後、古いタグ2.0を削除し、新しいマージされたコミットのタグ2.0を追加します。