SCMのバージョン管理とレガシーバグ修正

Question

ひどい質問のタイトルはすみませんが、もう少し詳しく説明しようと思います。

ソフトウェアプロジェクトにGitを使用しています（ただし、この場合、特定のソフトウェアは重要ではないと思います）。多くのプロジェクトと同様、さまざまなリリースを計画しています。リリースがあるときは、おそらく<！> quot; 1.0 <！> quot;のように、コミットにタグを割り当てます。時間が経ち、コードがハッキングされ、最終的には別のタグが付いたリリースがあります-今回は<！> quot; 2.0 <！> quot;。

ある日、リリース1.0と2.0の両方に存在する重大なバグに気づき、修正する必要があります。物事を難しくする（そしておそらくより現実的にする）ために、現在のマスター/トランクでそれを修正するだけではなく、誰もがそれを使用していると仮定することはできません。アップグレードしたくない。

それで、この種の振る舞いをサポートするために、良いスキームは何でしょうか：古いバージョンで変更を加えることができます。 Gitはgit describeコマンド（<！> quot; [latest tag]-[commits since the tag]-[current commit hash] <！> quot;）の出力のため、タグを何らかのレベルでリリースと同一視しているようです。おそらく、タグを完全に使用することは避けられません。

タグとブランチの組み合わせは良いアイデアだと感じることができますが、何らかの理由で、これで詳細を説明することはできません。

Answer 1

間違いなく、このためにブランチを使用することを検討したいと思います。 Gitはこの種の開発のブランチを非常によくサポートしています。

例として、線形バージョン履歴は次のようになります。

---A---B---C[1.0]---D---E---F[2.0]---G---H

1.0でバグを見つけて修正したい場合、コミットCとDの間に新しいコミットを挿入することはできません。したがって、次のようなブランチを作成できます。

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

C1とC2をコミットすると、そのブランチの問題が修正され、リリース1.1にタグを付けることができます。ここで、バージョン2.1で変更（G）を行い、バージョン1.1にバックポートして同じ変更を加えたとします。 git cherry-pickを使用して次のことができます。

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

コミットG1は、バージョン2.0ではなくバージョン1.1の上に適用できることを除いて、コミットGに関連しています。

これらの例では、ブランチ（開発の追加ストリーム）が重要な概念ですが、タグは、特定の時点でのプロジェクトの状態を参照する名前を作成する便利な方法です。 Gitは、特に強力なgit rebaseコマンドを使用して、ブランチを操作する他の多くの方法をサポートしています。

Answer 2

ブランチが必要です-メイン（マスター）ブランチで進行中の開発が継続している間に、リリースタグで始まるブランチでメンテナンス修正とリリースを行います。

Answer 3

ブランチとタグについて言及するとき、ほとんどの答えはすでにあるようです。タグは、特定の偶数（リリースなど）をマークするためにあり、ブランチは並行開発用です。特定のバージョンのメンテナンスは通常ブランチで行われ、現在のほとんどのVCSで変更セットをチェリーピックして、特定のバグ修正をヘッド/トランクからブランチにインポートしたり、その逆を行うことができます。

head / trunk / master（<！> quot; current <！> quot;開発ブランチの名前は何でも）で作業し、さまざまなメンテナンスブランチのバグ修正をマージできます。メジャーリリースまたはマイナーリリースが完了したらすぐに、メンテナンス用のブランチを作成します。

目的を達成する方法はたくさんあります。