ライブラリの異なるバージョンをどのようにバージョン管理下に置きますか？タグを使用していますか？それとも枝？または別の方法？
私は最近、自分のコードをバージョン管理下に置き始めました（私が作業しているラボ、SVNの下、およびgithub内の自分のコード（明らかにgitを使用））。バージョン管理を使用する前は、以前は次のようなことをしていました。ライブラリの名前が付いたフォルダがあり、バージョン番号の付いた多くのフォルダの中にありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始しました。
ただし、フォルダーがバージョン管理下に置かれると、これはかなり冗長に見えます。冗長性は別として、誰かが最新バージョンを取得したい場合、imports/clonesだけですべてのバージョンをダウンロードすることになります。
現在、バージョン管理でこれを行う方法はたくさんありますが、これは初めてなので、どちらがより保守しやすいのかわかりません。
方法1：タグを使用する
タグを正しく理解していれば、メインブランチがあり、変更をコミットしてバージョンでタグ付けします。次に、その作業コピーを取得したい場合は、特定のタグが付いたものを取得します。 （私が間違っていたら訂正してください）
方法2：バージョンの分岐
この方法では、メインブランチは開発ブランチになります。安定したバージョンが作成されるたびに（v1.2.0としましょう）、そのバージョンのブランチを作成し、コミットしないでください。そうすれば、特定のバージョンをダウンロードしたい場合、そのブランチからコードを取得できます。コミットはしないと言ったが、バグ修正を行い、古いバージョンのブランチにコミットして、古いバージョンを実行し続けることができるかもしれない。たとえば、現在のバージョンがv2.0であるが、v1.2を使用したい場合は、v1.2から別のブランチ、つまりv1.2.1を取得して、バグ修正をコミットできます。または、バージョンをv1.2と同じにして、バグ修正をコミットします。
したがって、ブランチは次のようになります。
v1.2.1 v1.2.2
/ /
v1.0.0 v1.2.0--------- v2.0.0
/ / /
-------------------------------------- dev
これにより、マイナーバージョンの更新ごとにブランチが作成されます。 （上のグラフでは、v1.2.1とv1.2.2、またはv2.0.0のリリース後に作成されたため、v1.2.0とv2.0.0の間の開発には含まれていません。古いバージョンのサポートと考えてください）
方法3：開発の分岐
この方法は、前の方法の逆です。メインブランチは最新の安定バージョンです。新しいバージョンで作業しているときはいつでも、（開発用の）ブランチを作成し、コードで作業し、コードが安定したら、メインブランチとマージします。
この場合、ブランチは次のようになります。
________ ____ ________________ _____ dev
/ \/ \/ \/
---------------------------------- latest_version
おそらくこれはタグと組み合わせて行う必要がありますか？
質問！
とにかく、私の質問はあなたの経験に基づいていますが、これらの方法のどれがより実用的であると証明されますか？そこに知られている最良の方法はありますか？これらは通常どのように行われますか？
タグとブランチは相互ではなく、両方を使用できます（通常IMOは両方を使用する必要があります）。タグは、開発のマイルストーンを示すためにあります。例えば。製品のバージョン1.2のブランチを開き、v1.2 Beta、RC1、RC2、Final（その後、必要に応じてSP1など）と同じブランチにタグを付けます。
私は個人的には、デフォルトの方法として方法2を好みます（ただし、可能な限りシンプルにするために、複数レベルのブランチを避けようとします）。方法1は実際には機能しません。タグだけでは不十分で、ブランチが必要です。また、方法3は常に1つの安定バージョンしかないという点で柔軟性がないため、（方法2と組み合わせない限り）複数の（最新および古い）バージョンを並行して維持することはできません。これは、現実のほとんどすべてのプロジェクトで必要です。バージョン2で作業している間も、v1.9のパッチやアップグレードを公開できます。多くの場合、以前のバージョンでも公開できます。もちろん、アプリケーションの種類にもよります。私たちはWebアプリを開発しているため、ある時点で本番バージョンは1つしかありませんが、それでも3つの異なるバージョン（1つは本番、もう1つはUATで展開の準備ができている、1つはトランクの最新バージョン）とやり取りします。 ）。複数の古いバージョンが並行して使用（および保守）されているデスクトップ/クライアントアプリの場合は、さらに複雑になる可能性があります。
ライブラリの名前が付いたフォルダがあり、バージョン番号の付いた多くのフォルダの中にありました。
既にバージョン管理を行っているので、これは事実上、間違ったアプローチです。
さて、列挙したさまざまな手法はすべて同じように思えます。タグとブランチに関する情報を含む、非常に詳細な記事 Source Control Done Right を読むことができます。
3つの方法は相互に排他的ではありません。バージョン管理を最大限に活用するには、3つの方法を組み合わせる必要があります。
私の部分では、デフォルトで方法1と3の組み合わせを使用します。つまり、機能または開発ブランチで、機能が本番稼働可能になるまで開発し、その後トランクにマージします。このようにして、trunkは常に安定した使用予定の開発の現在の状態を表し、svn：externalプロジェクトによって安全にリンクできます。バージョンをリリースしたら、タグを付けます。
私はオンデマンドでのみ分岐します。つまり、ライブラリの古いバージョンにhasのバグが修正されている場合です。壊れたバージョンのタグからそのブランチを簡単に作成できます。不必要に分岐しないことで、分岐の数を少なくし、維持する必要のある最先端（トランクとすべての分岐）の概要をすばやく把握できます。
方法2を使用します。私はこれを使用しましたが、現在の開発を前進させながら、複数のバージョンを管理および維持するための効果的な方法であることがわかりました。必要に応じて、このメソッドと組み合わせてタグを使用することもできます。
ブランチを使用して複数のリリースバージョンを維持する方法の詳細については、私の回答 こちら を参照してください。