3

ひどい質問のタイトルで申し訳ありませんが、もう少し冗長に説明してみます。

私は自分のソフトウェア プロジェクトに Git を使用しています (ただし、この場合、特定のソフトウェアは重要ではないと思います)。多くのプロジェクトと同様に、さまざまなリリースを予定しています。リリースがあるときは、おそらくコミットにタグを割り当てます。たとえば、「1.0」などです。時が経ち、コードがハッキングされ、最終的に別のタグが付いたリリースがあります - 今回は「2.0」です。

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

では、この種の動作をサポートするためには、どのようなスキームを用意すればよいでしょうか: 古いバージョンで変更を加えることができるようにすることです。git describeコマンド (" ")の出力のため、Git はあるレベルでタグをリリースと同一視しているよう[latest tag]-[commits since the tag]-[current commit hash]です。では、タグを完全に使用することはおそらく避けられません。

タグとブランチの組み合わせはいいアイデアだと思いますが、なぜかこれでは詳細が頭に浮かびません。

4

3 に答える 3

1

ブランチが必要です - メイン (マスター) ブランチで進行中の開発を続けながら、リリース タグで始まるブランチでメンテナンス修正とリリースを行います。

于 2009-01-18T23:10:56.787 に答える
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コマンドを使用して、ブランチを操作する他の多くの方法をサポートしています。

于 2009-01-19T00:31:03.363 に答える
1

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

ヘッド/トランク/マスター (「現在の」開発ブランチの名前が何であれ) から離れて作業し、さまざまなメンテナンス ブランチにバグ修正をマージできます。メジャー リリースまたはマイナー リリースが完了するとすぐに、メンテナンス用のブランチを作成します。

あなたが望むものを達成するための多くの方法があります。

于 2009-01-18T23:41:47.910 に答える