ライブラリの異なるバージョンをどのようにバージョン管理下に置きますか？タグを使用していますか？または枝？または別の方法？

私は最近、自分のコードをバージョン管理下に置き始めました（私が働いているラボではSVNで、自分のコードはgithubで（明らかにgitで））。バージョン管理を使用する前に、私はこのようなことをしていました。バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始します。

ただし、フォルダがバージョン管理下に置かれている場合、これはかなり冗長に思えます。冗長性は別として、誰かが最新バージョンを入手したい場合、彼import/ 彼女たちがちょうどあればすべてのバージョンをダウンロードするでしょうclone。

現在、バージョン管理を使用してこれを行う多くの方法を見ていますが、私はそれが初めてなので、どちらがより保守可能かはわかりません。

方法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は常に単一の安定バージョンしか持たないという点で柔軟性がないため、（方法2と組み合わせない限り）複数の（最新および古い）バージョンを並行して維持することはできません。これは、実生活のほぼすべてのプロジェクトに必要です。バージョン2で作業している間、v1.9のパッチ/アップグレード、さらには以前のバージョンでも公開できるはずです。もちろん、多くはアプリケーションの種類に依存します。ウェブアプリを開発しているため、特定の時点で製品版は1つしかありませんが、それでも3つの異なるバージョン（製品版、1つはUATで展開の準備をしており、もう1つはトランクの最新バージョンです。複数の古いバージョンが並行して使用および保守されているデスクトップ/クライアントアプリの場合、より複雑になります。

バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。

既に述べたように、これは事実上、間違ったアプローチです。バージョンを管理するためのバージョン管理が既にあるからです。

今、あなたが列挙するさまざまなテクニックはすべて同じように見える。タグとブランチに関する情報を含む、非常に詳細な記事「ソース管理が完了しました」を読むことができます。

3つの方法は相互に排他的ではありません。3つを組み合わせて、バージョン管理を最大限に活用する必要があります。

私の場合は、デフォルトで方法1と3の組み合わせを使用します。つまり、機能が本番稼働可能になるまで機能または開発ブランチで開発し、その後トランクにマージします。このように、trunkは常に安定した使用される開発の現在の状態を表し、svn：externalプロジェクトによって安全にリンクできます。バージョンをリリースしたら、タグを付けます。

私はあなたのライブラリーの古いバージョンではバグがある場合、ある需要に分岐したい持って固定することを。壊れたバージョンのタグからそのブランチを簡単に作成できます。不必要に分岐しないことで、分岐の数を少なくし、維持する必要のある最新のエッジ（トランクとすべての分岐）をすばやく確認できます。

方法2を使用します。これを使ってみたところ、複数のバージョンを管理および保守しながら、現在の開発を進めることができる効果的な方法であることがわかりました。必要に応じて、このメソッドと組み合わせてタグを使用することもできます。

分岐を使用して複数のリリースバージョンを管理する方法の詳細については、こちらの回答を参照してください。