8

同僚と私は、リリース/SCM システムでのタグの価値と使用法について議論しています。この問題を解決するために、StackOverflow コミュニティからの意見をお待ちしております。

一方では、タグはリリース管理にとって価値のある追加機能であると主張しています。それらの使用例: このリリースで使用されるコード スナップショットである新しいタグ (1.0 と呼びます) を作成する Maven リリースを行います。このタグは READONLY ブランチである必要があります。バグを修正する必要がある場合、タグのコピーを新しいブランチ (1.1 と呼びます) に作成できます。バグ修正はそこに行きます。これらの修正は、メインの開発ブランチがバグ修正を取得できるように、トランクに再びマージされる場合があります。最後に、1.1 がリリースされ、タグ 1.1 が自動的に作成されます。このサイクルは続きます。ここでの Tag の主な利点は、何らかの理由でバージョン 1.0 を再リリースする必要がある場合に、誰も変更されていないという確信を持って Tag 1.0 をリリースできることです。また、「Release Tag 1.0」と言う方が、「元の 1 であるブランチ 1.0 のリビジョン 1 をリリースする」よりも簡潔です。

反対側は、特に CVS のタグのように機能するグローバル リビジョンを備えた Subversion のようなシステムでは、タグは価値のある利点を提供していないと主張しています。さらに、Subversion はタグにコミットするときにのみ警告を出します。それは実際にそれを止めません。彼らの方法はトランクで開発されており、リリース時に 1.0 というブランチを作成します。Trunk で引き続きバグ修正を行い、それらのバグ修正を本番環境に再リリースする必要がある場合は、それらを 1.0 Branch にマージして 1.0 を再リリースします。ある時点で、おそらく Trunk の主要な修正または機能の後、Branch 1.1 をリリースして作成します。サイクルは続きます。元の 1.0 バージョンをリリースする必要がある場合は、Branch 1.0 リビジョン 1 をチェックアウトする必要があります。

明らかに、両方の方法が機能します。どちらの方法が好まれているか、またその理由について、コミュニティの意見を聞きたいです。

編集:「最善の」方法が基礎となる SCM システムに依存することを少し心配しています。Subversion で解決するか、可能であれば SCM にとらわれないようにしてください。

4

8 に答える 8

4

私の意見では、タグは便利です。プロジェクトの進行中のある時点で、バグや変更に遭遇し、それが以前のリリースにあったかどうかを知りたい場合があります。あるリリースのコードを別のリリースと比較して、パフォーマンスと実際のコード開発の両方の効率を測定する理由があります。

確かに、それを台無しにする可能性はありますが、いつでも元に戻すことができます. そうしない理由はまったくありませんし、将来役に立つかもしれないいくつかの理由があります。私にとっては簡単なことです。

ブランチを使用してそこで開発を行うべきであることに同意しますが、実際に何かをリリースするときはいつでも、それからタグを作成してください。

于 2009-04-08T13:30:17.887 に答える
4

SCM にとらわれない観​​点から見ると、タグはリビジョンとは大きく異なります。

どちらも同じ方法で実装できます。どちらも「タイム ライン」を表しますが、目的は異なります。

  • タグは、すべてのファイルが一意の ID によって参照される不変の状態を表します。多くのことを表す名前ですが、主に安定した状態を表します...)
  • リビジョンはコミット トランザクションを表します (すべての SCM にそれらがあるわけではなく、特に「ファイルごとのアプローチ」を使用する古いもの)。すべてのコミットが「安定した」状態を表しているわけではありません (「コンパイル」または「実行」の成功など)。それらは世界史の新しい要素にすぎません。

SVN の問題は、リビジョン、タグ、およびブランチがすべて同じように実装されていることです。
しかし、タグが「読み取り専用」ブランチとして使用されるオプションを引き続き好むでしょう。

于 2009-04-08T14:16:18.557 に答える
1

はい、タグを使用します。

タグは、特定のリビジョンの単なるラベルまたは名前と考えてください。私の経験では、プロジェクトの重要なマイルストーンにタグを付けることは、製品リリースであろうと中間 QA リリースであろうと、非常に役に立ちます。時間をさかのぼって、特定のリリースのソース コードを見たいと思うことがよくあります。

リリース時に分岐すると、どのリビジョンが本番環境にリリースされたかをいつでも把握できますが、これはタグを見るだけに比べると面倒です。リリース ブランチを使用しないと、特定のビルドの作成に使用されたリビジョンを簡単に追跡できなくなります。

svn の問題は、タグとブランチの区別が曖昧なことです。誰でもいつでもタグにコミットできるため、固定/不変であるとは限りません。PVCS のような他の VCS では、「タグ」は変更できません。チーム規約を採用してタグへのコミットを防止したり、コミット フックを使用してタグへのコミットを防止したりすることもできます。

于 2009-04-08T14:20:12.057 に答える
1

新しいベースラインを作成するときは、タグ (ラベル) を使用します。私たちは週に 1 回行いますが、1 日に数回行うチームもあります。

(私たちにとって) ポイントは、常に新しいベースラインが安定していることを確認することです。つまり、単なるビルドではなく、テストスイート全体、数時間の自動テスト、および潜在的に手動の探索的テストに合格するビルドです。

次に、ベースラインは次の反復中にすべてのタスクの開始点として使用されます。すべての新しいタスクは、安定していることが知られているベースラインから始まる新しいブランチであるため、タスクで壊れたものはタスク自体の中で簡単に追跡できます。 .

通常、他のすべてのブランチの統合ポイントであるメイン ブランチ (または、SCM フレーバーに応じてトランクまたはマスター) にのみタグ (ラベル) を配置します。

公式製品をリリースするときは、「そのためのリリース ブランチ」を作成します。これにより、新しい開発が「メイン」にとどまっている間、修正のみが受信されます。次に、これらの「メンテナンス ブランチ」(できれば一度に 1 つまたは 2 つだけ) にもタグを付けることができます。

于 2009-04-15T09:34:06.373 に答える
0

プロジェクトのソースコード（および実行可能ファイル）の不変のスナップショットは、構造化テストであれフィールド使用であれ、あらゆる種類のテストを実行するために非常に貴重です。構造化テストの場合、数か月または数年先に参照される可能性のあるデータを作成することになります。そのデータを再検討するときはいつでも、マーフィーの法則により、データがどのコードからのものであるかを知る必要があり、ソースコードの特定のスナップショットを引用するのに苦労しない限り、どのソースコードが対応しているかを自信を持って判断することは不可能です。そのテストデータ。

誰かが私のところに来て、「このマイクロコントローラーのコードが機能していません。助けてくれませんか」と言った回数はわかりません。そして私は彼らに「あなたはどのバージョンを使っていますか？」と尋ねます。また、リリース管理が適切に行われていないため、「わからない」と言われます（少なくとも、デバイスにステッカーを貼っておくと、リアルタイムで照会できるEEPROMにバージョン情報を入れる方がよいでしょう）。> :(

于 2009-04-08T17:42:56.000 に答える
0

私は、タグを「リビジョンの派手な名前」と考えるのが好きです。私はいつもそれらについてそのように考えてきました.IIRCのmercurialはまさにそれです. ただし、Subversionでは、あなたが言うように、実際にはtrunk/*からtags/fancy-name/への（安価な）コピーです

正直なところ、最適な結果を得るには、リリース時にタグとブランチという 2 つの戦略を組み合わせます。あなたのタグは 1.0.0、ブランチ 1.0-MAINT と呼ばれます。バグ修正はブランチに入り、バグ修正リリースは再びタグになります (1.0.1 は、特定の時点で 1.0-MAINT のエイリアスを意図したタグによる場合があります)。

ただし、subversion のタグとブランチは実際には同じものであることを忘れないでください: 安価なコピーです。それらの唯一の違いは、あなた/あなたのチームがそれらに帰属するセマンティクスであるため、要約すると、人々が1つの特定の方法に同意し、それに固執するようになります（サーバーで強制される可能性があります。たとえば、タグ/例外でのコミットを禁止します）リリースコーディネーター向けなど）

ただし、2 番目のアプローチの問題点は、1.0 を再リリースした場合に、現場でソフトウェアを簡単に区別するにはどうすればよいかということです。つまり、1.0 と別の 1.0 が実際には別のコード ベースを参照している可能性があることを意味します... .

于 2009-04-08T13:35:50.807 に答える
0

私は両方のアプローチを組み合わせます。リリースするときはいつでも、タグを付けます。タグは決して変更されるべきではないため、「1.0.0」タグの存在は、他のものを 1.0.0 としてリリースしようとしてはならないことを示しています。

同時に、1.0.0 をやる時が来たら、1.0 ブランチに入れました。フローは次のとおりです。トランクを 1.0 に分岐し、この新しい 1.0 に 1.0.0 のタグを付けて、展開します。次に、1.0 ブランチでバグ修正を行い (現在トランクにある可能性のある 1.1 を対象とした開発と混同しないようにするため)、トランクにマージします。修正された 1.0 の各リリースは、1.0 ブランチから 1.0.x としてタグ付けされます。これは基本的に Perforce で使用するアプローチであり、Subversion と非常によく似ています。（返信を読んで、Vincentの推奨事項とほぼ同じだと思います）

リビジョン番号があるためにタグが冗長であるというコメントに関する限り、タグがスコープも指定することを除いて、それはおおむね正しいです。つまり、リポジトリ内のどのファイルがタグでカバーされているかです。合理的に誰かに /svn/proj1/tag/1.0.0 を見るように頼むことができ、彼らはすぐに一貫したワークスペースを見ています。リビジョン X を見るように依頼した場合、最初にリビジョン X を見て、(たとえば) /svn/proj1/trunk/Makefile が変更されていることを確認し、/svn/proj1/trunk/@X が何であるかを推測する必要があります。彼らは見ているは​​ずです。リビジョン X が proj1 と proj2 のファイルに触れた場合はどうなりますか? もちろん悪いことですが、厳密には /svn/proj1/trunk/@X. リビジョン番号のリストはどこに保存されていますか? 1.0.0 がリビジョン X であることはどのようにしてわかりますか? 私見は、リポジトリからだけでそれを判断できるはずです。

Git のようなシステムでは、タグとブランチは基本的に同じもの (オブジェクト データベースへの参照のみ) ですが、慣習として、タグ ref は変更されず、ブランチ ref は変更されます (変更方法に特定の制約があることが望ましい) ）。Perforce には、変更リストとは別に一連のファイル リビジョンをグループ化する方法である「ラベル」もあります。これは本質的にはタグですが、より紛らわしいです: 歴史的に、バージョンを識別するために、変更リスト番号 (Subversion リビジョン番号に相当) をブランチの名前で修飾して使用してきました。この 2 つはほとんど同じなので、ここでは TMTOWTDI と推測します。

于 2009-04-08T19:09:25.467 に答える