ソース管理で古いタグのパッチを作成する方法は？

Question

1年前に私のソフトウェアのバージョンをリリースし、Gitの2.3でタグ付けしたとしましょう。

だから私は機能を追加し続け、バグを修正しています。それを知る前に、ソフトウェアはバージョン3.0になっています。しかし、今ではソフトウェアのバージョン2.3にバグがあり、修正が必要な人はバージョン3.0にアップグレードする準備ができていません。

Gitに関しては、Gitリポジトリの履歴を変更することなく、2.3へのパッチの適用とバージョン2.3.1のソフトウェアの作成を管理する最も良い方法は何でしょうか。

たとえば、バージョン2.3をチェックアウトできず、パッチを適用して2.3.1でタグ付けし、新しいヘッドを作成するのでそれをプッシュアップします。

開発者はどのようにして通常、古いバージョンのソフトウェアのサポートを管理していますか？

は

オーケー編集ので、私は@AnoEのアドバイスに従い、以前のバージョンにパッチを適用するために、次のように今、私のワークフローがあります。アドバイスは大歓迎です。

git checkout v2.3.0 
// Make code changes 
git add -A 
git commit -m "Fixed a bug in old app" 
// Do something to verify the changes work on a different environment 
git checkout -b v2_3_1 
git tag -a v2.3.1 -m "Fixed small bug." 
git push origin v2_3_1 
git push --tags 

私がブランチを作成しなければならなかったのは、私たちのレポホスティングソリューションであるKilnにタグが表示されないためです。 BitbucketやGithubのような他のプロバイダが、ブランチが関連付けられていないタグを表示するのか、これがGitのストア方法の副作用なのか分かりません。 git tag -lを実行したときにタグがローカルに表示されましたが、ウェブUIから表示されませんでした。私がブランチとタグをプッシュした後、私はブランチを削除して、それがWeb UIから正しく表示されました。

git push --delete v2_3_1 

なぜこのようなことが起こるのか誰かが理解できれば、それは分かります。

Answer 1

2.3をチェックして、パッチを適用し、2.3.1のタグを付けることは、まさにあなたがやろうとしていることです。

新しいヘッド（むしろ新しいブランチ）を作成することはまったく問題ではありませんが、これはgitのために作られたものです。 gitでは "HEAD"は構造的な意味を持たないことに注意してください。現在の作業ディレクトリでアクティブになっている1つのコミットなので目立ちます。 Gitは構造的にコミットだけを気にし、好きなだけ多くの「トップレベル」コミットを持つことができます。

ので：

git checkout 2.3 # gives you a "detached HEAD" 
git checkout -b dev_2.3 # a new branch, more for convenience 
...modify files... 
git add ... ; git commit ... 
git tag 2.3.1 
git branch -D dev_2.3  # get rid of it if you have a feeling that you won't be comming back soon 

は両方のブランチとタグがすべてではgitで何も特別なことではないことに注意してください。それらは単にコミットを指している付箋です。この方法で（たぶん一時的な）ブランチを作るのはちょっと便利です。なぜなら、あなたがやっているバックポートに1回以上のクイックコミットが含まれていると簡単に切り替えることができるからです。

Answer 2

Gitのリリースを扱うには、タグとブランチの2つの方法があります。

タグの一つの引数は、彼らが不変であるということです（枝が成長し続けることができ、一方、あなたが唯一、それらを再作成/削除することができます）、しかし、私は以下の理由により、リリースではなく、タグのための枝を使用する傾向がある：

• タグに基づいてリリースにパッチを当てなければならない場合は、タグとなるリリースがいくつかあります。いくつかのリリースはブランチです。これは、特に2回目のパッチを適用する必要がある場合に混乱する可能性があります。今回は、最初のパッチブランチをチェックアウトしますので、Gitの専門家ではない人たちのためにパッチを当てなければならない場合は、手間がかかるかもしれません。
• 通常、git（Gitlab、BitBucketなど）用のツールには、ブランチを参照としてブランチを使用して、前後のコミットの比較を伴うページのブランチが表示されます。タグでも同じことが可能ですが、各タグを手動で選択する必要があるため、ブランチと同じように簡単にはできません。これは、旧リリースで行われたパッチが最近のリリースに存在することを確認したい場合に特に便利です。
• パッチを当てることで、新しいブランチを作成する必要はありません（）。通常、パッチは下位互換性の問題を引き起こさないので、ブランチrelease_2.3にコミットを追加するだけで（pomを2.3.0から2.3.1に更新するだけで）、新しいブランチを作成しないでくださいパッチのために、親ブランチを使用しないでください（クライアントがパッチを必要としない限り）。

タグはブランチの作成を避けることができ、リポジトリはこれはもう使用されていますが、これはマイナーな欠点です。「公害」は、すべてのリリースでリリースされているパッチから来ていると考えています:)

EDIT： ％タグを使用しますが、古いリリースにパッチを適用する必要がある場合は、y私は推薦していないことですが、歴史を書き換えて書き直す必要があります