gitを使って古いバージョンを維持する

Question

私はgitブランチングのワークフローを読んできました。開発目的でブランチがあり、最終的にすべてがマスターにマージされるという前提があるようです。古いバージョンのメンテナンスのために長時間実行されるブランチを使用することに関する多くの議論を見つけることはできません。

たとえば、私のワークフローはSVN（perforce "tofu"モデルに基づいています）で動作する方法です。最新のリリース版が4.1だとしましょうが、バージョン4.0,3.5、および3.6もサポートしていますので、それぞれにメンテナンスブランチがあります。トランクは、4.2までリリースされない機能に使用されます。顧客がバージョン3.6へのバグ修正を必要としているとします。私は私の3.6メンテナンスブランチへの修正を行い、新しいメンテナンスリリース（引数3.6.22のために）を作るでしょう。

この時点で、修正は4.0に、そこから4.1,4.2、トランクに、そしてそこからトランクで作成された開発ブランチにマージされます。これはチェリーピックマージではないことに注意してください。これは通常のSVN自動マージです。

修正が簡単でない場合は、3.6リリースブランチからdevブランチを作成し、リリース前に通常の方法で再統合することがあります。同様に、4.1へのマージダウンが重要でない場合、4.1からの開発ブランチをマージして、マージに満足すれば4.1リリースに再統合するかもしれません。私たちは、バージョン4.2をリリースするとI（あるいは私がすることができます）Gitの中でまったく同じワークフローを使用すべき

を、私たちは同じようにそのためのメンテナンスブランチを分岐し、トランクには、現在進行中の4.3仕事になるだろう、またはこの "古い帽子"伝統的なsvn思考は再考する必要がありますか？

Answer 1

ブランチング戦略は、バージョン管理技術によって大きく変わることはありません。あなたが説明したものは、実際の製品のかなり標準的な分岐ワークフローのように聞こえます。 SVNのような別のツールからGitに移るときに変わるものは、のブランチの作成と維持です。 Gitでは、分岐は非常に安いです。 Gitのブランチは、基本的にコミットのポインタです。たとえば、わずかなコミットだけを含むメンテナンスブランチを作成するコストは、漸進的に非常に小さくなります。 SVNのようなツールでは、プロジェクトのコピーやすべてのファイルを作成する必要があるかもしれません。