少し前まで、Microsoft VSS をバージョン管理ツールとして使用しており、すべてのリリースの終了後にコードのブランチを作成し、それをクライアントに展開していました。
今は SVN に移行し、最近タグ/ブランチについて多くの議論がありました。特定のリリースの開発後にコードにタグを付けたりブランチしたりする必要がありますか?
SVN は実際にそのような目的で「タグ」を推奨していますが、それ以上の変更を加えないことも推奨しています。このリリースで発生する凶悪なバグ修正はどこで行うのでしょうか?
他に行っていることは、タグとブランチの両方を作成し、タグをクライアントにデプロイし、バグが発生した場合に備えて、ブランチに修正を加えてから再度タグ付けすることです :-(
他の人は何をしますか？
Subversionでは、これらは同じものです。同じ方法で実装され、結果は同じです（リポジトリ階層を除く）。これらは、リポジトリの特定のリビジョンへの単なる参照です。実際のコピーは作成されません。（本当の意味で）ブランチで作業を開始すると、そのリソースの新しいコピーを新しい場所で使用することになります。
必要に応じていつでもタグからブランチを作成できるため、ブランチとタグを作成する理由はありません。
一貫性を保つのに役立つ場合は、先に進んで実行しますが、実際には、ブランチのチェックイン/改訂を開始するまで何も実行されません。
（タグ/ブランチは両方ともcpコマンドで作成されます）
コード行の特定のリビジョン (例: トランク) にタグを作成し、常にタグからリリースを行います。svn のタグは、svn 自体によって強制されていませんが、スナップショットと参照ポイントを意味します。その暗黙の概念を利用して、特定のリリースに対応することがわかっているタグから作成されたビルドのみをリリースしてください。
ブランチを使用して、特定のリリースにメンテナンス パッチをコミットします (たとえば、リリースにパッチを適用する必要がある場合は、タグからブランチを作成します)。また、ブランチからリリースするときにもブランチにタグを付けて、パッチにも同じ手順に従います。
はい、通常、トランクと並行してメンテナンス ブランチを作成し、そこからバグ修正リリースにタグを付けます。
ここでは、ソース管理の概念、特にSVNはまだかなり新しいため、トランクだけで作業します。まだライブになる予定のないコミットがあり、その時点でデプロイしている人がそのことに気付かないまでは、うまく機能します。
誰もがここでSVNに慣れ、少なくとも1人がマージに慣れたら、承認されたすべての本番コミットをマージできる「ライブ」ブランチをセットアップします。
タグは、開発サイクル、「ベータ」、「アルファ」、「リリース候補1」などに名前を付けることができるので便利です。しかし、必要な最も重要なことは、本番環境で使用するために信頼できる優れたブランチです。タグを使用すると、マイルストーンを簡単に判別できます。
リリース ブランチのタグ。