SVN:幹、枝、タグ

Question

私は自分の問題に対する最善の解決策を見つけようとしている月ですが、これが最善の解決策です。あなたがそれに同意するかどうか知りたいです。

私たちは相互接続された一連の Web アプリケーションを開発しています。私たちは各アプリケーションを他のアプリケーションから独立した単一のソリューションとして扱います。各アプリケーションは異なるプロジェクトによって形成されますが、これはあまり重要ではありません。

私たちはトランク上で新しい機能を開発するために使用します。何かをライブで公開するときは常に、トランク バージョンにバージョン名をタグ付けします。たとえば、最初のトランクのバージョンに 1.0.0 のタグが付いているとします。さらなる実装を開発するとき (つまり、1.1.0に取り組んでいます）製品版から一連のバグが出てきました。私たちがやろうと考えているのは、タグ 1.0.0 をチェックアウトし、バージョン 1.0.1 に向けてバグを修正することです。

ここで達成したいのは、各リビジョン バージョンにタグを付けることです。言い換えれば、1.0.0、1.0.1、1.0.2 ... の完全な作業コピーを作成できるようにしたいと考えています。

これが私の解決策です。これに同意していただけるかどうかを知りたいです。

1. タグ付きバージョン 1.0.0 をローカルの /tags フォルダーにチェックアウトします
2. このバージョンを /branches/1.0.1 リポジトリ フォルダーにブランチします
3. 新しいブランチをローカルの /branch フォルダーにチェックアウトします
4. ブランチ 1.0.1 のバグを修正しました
5. x 件のコミット後、すべてが正常になったら、この新しいバージョンを /tags/1.0.1 にタグ付けします。

新しいバグや新しいリリースごとに以下のようになります。試してみたところ、/tags フォルダーをチェックアウトすると、すべてのバージョンが表示され、完璧に動作しています。

1.1.0 の準備ができたら、「リビジョンの範囲をマージ」オプションを使用して、トランク上の最後のタグ (またはブランチ、すべてが正しければ最後は同じになるはずです) をマージする必要があります。すべてがマージされると、過去に修正されたリビジョンを備えた完全に動作する 1.1.0 バージョンが得られるはずです。コンパイル、テストして公開し、当然のことですが、サーバー上の /tags/1.1.0 フォルダーにタグ付けします。

どう思いますか？ありがとう、 マルコ

Answer 1

通常、すべての開発はtrunk上で行われ、trunkはリリースのベースとなるものです。ブランチは、リリースに備えてコードを安定させるため、リリースにパッチを適用するため、またはいくつかの理由でトランクで開発できない機能を実装するために使用します。

安定化またはリリースにパッチを適用するためにブランチを使用する場合、バグの修正、または安定化ブランチに送られる変更はすべてトランク上で開発され、選択的にブランチにマージされます。

機能ブランチを使用する場合は、ブランチにコミットしてから、トランクにマージして戻します (おそらくそこから安定化/パッチ ブランチにマージします)。

早い話が、あなたの開発サイクルにトランクがなかったのが懐かしいです。すべての変更が最終的にトランクに確実に反映されるようにどのようにして行っているのか不思議です。なぜなら、次のメジャー機能リリースはそこから開始される/開始されるべきだからです。

Answer 2

これはかなり良いプロセスのように見えますが、本番ブランチのバグ修正はおそらくトランクにも反映する必要がある点が異なります。したがって、合併する必要はないはずです すべて すでに行っているので、最後にトランクに移動します。

それ以外の場合は、ブランチとタグを適切に使用しているようです。その点は賞賛に値します。私は、ソース管理で現在の (または他の) 製品バージョンを識別できないプロジェクトをあまりにも多く見てきました (何かを修正したりロールバックする必要がある場合、これは不可欠です)。私の意見では、それについては言い訳の余地がありません。

Answer 3

あなたが説明したことは、私にはタグ付けと分岐の通常の手順のように思えます。これが私が Subversion を使用する方法であり、非常にうまく機能します。

Answer 4

私にはいいですね。

リリースされる修正の量にもよりますが、マイナー リリースごとにブランチを作成する必要はありません。これらを作成し、何をチェックアウトするか、どこにチェックインするかを人々に伝え、マージダウンなどを行います。洗い流して繰り返します。

メジャー リリースごとにブランチを用意し、それを「メンテナンス」ブランチとして使用することは、私たちにとってうまく機能します。

興味がある場合のために、プロセスの説明を以下に示します。同じプロジェクトの異なるコンポーネントに取り組んでいる複数の開発者グループ (同じ場所にいない) のための svn デプロイメント戦略

ブランチのポリシーを定義し、現在のポリシーに当てはまらないことを行う必要がある場合にのみ新しいブランチを作成します。分岐を制限するのに役立ちます。