Subversion リポジトリにおける「ブランチ」、「タグ」、「トランク」とは何を意味しますか?

StackOverflow https://stackoverflow.com/questions/16142

質問

これらの言葉は、Subversion (おそらく一般的なリポジトリ) の議論でよく目にしました。私はここ数年プロジェクトで SVN を使用してきましたが、これらのディレクトリの完全な概念を理解したことがありませんでした。

どういう意味でしょうか？

役に立ちましたか？

解決

うーん、Nick re タグがブランチに似ているという意見に同意するかどうかはわかりません。タグは単なるマーカーです

  • トランク プロジェクトの立ち上げから現在までの開発の主体となります。

  • 支店 トランク内のコードの整合性を維持しながらコードに大きな変更を適用するために使用される、トランク内の特定のポイントから派生したコードのコピーになります。大きな変更が計画どおりに機能する場合、通常はトランクにマージされます。

  • 鬼ごっこ は、保存したいトランクまたはブランチ上の特定の時点になります。保存する主な理由は 2 つあり、アルファ、ベータ、RC、RTM のいずれであっても、これがソフトウェアのメジャー リリースであるか、トランクのメジャー リビジョンが適用される前のソフトウェアの最も安定した時点であるかのいずれかです。

オープンソース プロジェクトでは、プロジェクトの利害関係者によってトランクに受け入れられていない主要なブランチが、 フォーク -- 例: 他のソース コードと共通の起源を共有する完全に別個のプロジェクト。

ブランチとタグのサブツリーは、次の方法でトランクと区別されます。

Subversion を使用すると、システム管理者は フックスクリプト 特定のイベントが発生したときに実行がトリガーされます。たとえば、リポジトリへの変更をコミットします。典型的な Subversion リポジトリの実装では、「/tag/」を含むパスを作成後に書き込み禁止として扱うのが非常に一般的です。最終的な結果として、タグは一度作成されると (少なくとも「通常の」ユーザーにとっては) 不変になります。これはフック スクリプトを介して行われ、次の場合にそれ以上の変更を防ぐことで不変性を強制します。 鬼ごっこ 変更されたオブジェクトの親ノードです。

Subversion には、バージョン 1.5 以降、「ブランチ マージ追跡」に関連する機能も追加されています。これにより、変更がブランチにコミットされます。 支店 インクリメンタルな「スマート」マージのサポートにより、トランクにマージし直すことができます。

他のヒント

まず第一に、@AndrewFinnell と @KenLiu が指摘しているように、SVN ではディレクトリ名自体には何の意味もありません。「トランク、ブランチ、タグ」は、ほとんどのリポジトリで使用される一般的な規則にすぎません。すべてのプロジェクトがすべてのディレクトリを使用するわけではありません (「タグ」をまったく使用しないことはかなり一般的です)。実際、慣例を破ることは混乱を招くこともありますが、実際には、それらを好きなように呼び出すことを妨げるものはありません。

ブランチとタグのおそらく最も一般的な使用シナリオについて説明し、それらがどのように使用されるかのシナリオ例を示します。

  • トランク:主要な開発エリア。ここにコードの次のメジャー リリースが存在し、通常はすべての最新機能が含まれます。

  • 支店:メジャー バージョンをリリースするたびに、ブランチが作成されます。これにより、未完成または未テストの可能性がある最新の機能をリリースすることなく、バグ修正を行って新しいリリースを作成できます。

  • タグ:バージョン (最終リリース、リリース候補 (RC)、およびベータ) をリリースするたびに、そのバージョンのタグを作成します。これにより、その状態のコードの特定時点のコピーが得られるため、必要に応じて過去のバージョンに戻ってバグを再現したり、過去のバージョンをそのままの状態で再リリースしたりすることができます。SVN のブランチとタグは軽量です。サーバー上ではファイルの完全なコピーは作成されず、数バイトしか占有しない「これらのファイルはこのリビジョンでコピーされました」というマーカーが作成されるだけです。これを念頭に置いて、リリースされたコードのタグを作成することを心配する必要はありません。前に述べたように、タグは省略されることが多く、代わりに、リリースの作成時に変更ログまたはその他のドキュメントでリビジョン番号が明確になります。

たとえば、新しいプロジェクトを開始するとします。あなたは「トランク」で作業を開始し、最終的にはバージョン 1.0 としてリリースされる予定です。

  • トランク/ - 開発バージョン、間もなく 1.0 になります
  • 枝/ - 空

1.0.0 が完了したら、trunk を新しい「1.0」ブランチに分岐し、「1.0.0」タグを作成します。現在、最終的に 1.1 となる作業が trunk で続けられています。

  • トランク/ - 開発バージョン、 もうすぐ1.1になる
  • ブランチ/1.0 - 1.0.0 リリース バージョン
  • タグ/1.0.0 - 1.0.0 リリース バージョン

コード内でいくつかのバグを発見し、それをトランクで修正し、その修正を 1.0 ブランチにマージします。逆に、1.0 ブランチのバグを修正してから、それをトランクにマージして戻すこともできます。ただし、通常、プロジェクトは何かが欠けている可能性を減らすためだけに一方向のマージに固執します。バグは 1.1 では廃止されているため、1.0 でしか修正できない場合があります。それはあまり重要ではありません:1.0 で修正されたのと同じバグを抱えたまま 1.1 をリリースしないようにしたいだけです。

  • トランク/ - 開発バージョン、まもなく 1.1 になります
  • 枝/1.0 - 今後の 1.0.1 リリース
  • タグ/1.0.0 - 1.0.0 リリース バージョン

十分なバグ (またはおそらく重大なバグが 1 つ) を見つけたら、1.0.1 リリースを行うことにします。そこで、1.0 ブランチからタグ「1.0.1」を作成し、コードをリリースします。この時点で、トランクには 1.1 になるものが含まれ、「1.0」ブランチには 1.0.1 コードが含まれます。次回 1.0 へのアップデートをリリースするときは、1.0.2 になります。

  • トランク/ - 開発バージョン、まもなく 1.1 になります
  • 枝/1.0 - 今後の 1.0.2 リリース
  • タグ/1.0.0 - 1.0.0 リリース バージョン
  • タグ/1.0.1 - 1.0.1 リリース バージョン

最終的には 1.1 をリリースする準備がほぼ整いましたが、最初にベータ版を実行したいと考えています。この場合、「1.1」ブランチと「1.1beta1」タグを実行する可能性があります。さて、1.2 (またはおそらく 2.0) になる作業はトランクで継続されますが、1.1 の作業は「1.1」ブランチで継続されます。

  • トランク/ - 開発バージョン、 もうすぐ1.2になる
  • Branch/1.0 - 今後の 1.0.2 リリース
  • Branch/1.1 - 今後の 1.1.0 リリース
  • タグ/1.0.0 - 1.0.0 リリース バージョン
  • タグ/1.0.1 - 1.0.1 リリース バージョン
  • tags/1.1beta1 - 1.1 ベータ 1 リリース バージョン

1.1 最終版をリリースしたら、「1.1」ブランチから「1.1」タグを実行します。

必要に応じて、3 つのブランチ (1.0、1.1、およびトランク) すべての間でバグ修正を移植して、1.0 を維持し続けることもできます。重要な点は、保守しているソフトウェアのメイン バージョンごとに、そのバージョンのコードの最新バージョンを含むブランチがあるということです。

ブランチのもう 1 つの用途は機能です。ここでトランク (またはリリース ブランチの 1 つ) をブランチし、独立して新機能に取り組みます。機能が完成したら、それをマージし直し、ブランチを削除します。

  • トランク/ - 開発バージョン、間もなく 1.2 になります
  • Branch/1.1 - 今後の 1.1.0 リリース
  • branch/ui-rewrite - 実験的な機能ブランチ

これは、何か破壊的なもの（他の人の作業を妨げたり妨害したりするもの）、実験的なもの（それは成功しない可能性があります）、あるいは単に長い時間がかかるものに取り組んでいるときに考えられます。 (そして、トランクから 1.2 をブランチする準備ができているときに、1.2 のリリースが保留されるのではないかと心配になります)、ブランチ内で単独で実行できます。通常、変更を常にトランクにマージすることでトランクを最新の状態に保ちます。これにより、完了後の再統合 (トランクにマージして戻す) が容易になります。

また、ここで使用したバージョン管理スキームは多数あるうちの 1 つにすぎないことにも注意してください。一部のチームは、バグ修正/メンテナンス リリースを 1.1、1.2 などとして実行し、大きな変更を 1.x、2.x などとして実行します。ここでの使用法は同じですが、ブランチに「1.0」または「1.0.x」の代わりに「1」または「1.x」という名前を付けることができます。(余談ですが、 セマンティックバージョニング バージョン番号を付ける方法についての良いガイドです)。

Nick の発言に加えて、詳細については、次の URL を参照してください。 ストリームライン:並列ソフトウェア開発の分岐パターン

enter image description here

この図では main トランクです、 rel1-maint 支店であり、 1.0 タグです。

一般的に (ツールに依存しないビュー)、ブランチは並列開発に使用されるメカニズムです。SCM には 0 ～ n 個のブランチを含めることができます。Subversion には 0 があります。

  • トランク 本店です 推奨 投稿者: Subversion, しかし、作成することを強制されるわけではありません。それを「メイン」または「リリース」と呼ぶことも、まったく持たないこともできます。

  • 支店 開発努力を表しています。リソースにちなんで名前を付けることはできません (「vonc_branch」など)。ただし、次の後に付けます。

    • 目的「myProject_dev」または「myProject_Merge」
    • リリース境界「myProjetc1.0_dev」または「myProject2.3_Merge」または「myProject6..2_Patch1」...

  • 鬼ごっこ 簡単にその状態に戻すためのファイルのスナップショットです。問題は、Subversion ではタグとブランチが同じであることです。. 。そして、私は間違いなく偏執的なアプローチをお勧めします。

    Subversion で提供されているアクセス制御スクリプトの 1 つを使用すると、タグ領域に新しいコピーを作成する以外の操作を誰にも禁止できます。

タグは最終的なものです。その内容は決して変更されるべきではありません。一度もない。これまで。リリースノートの一行を忘れていませんか?新しいタグを作成します。古いものを廃止するか削除します。

さて、私は「これこれのブランチでこれとこれをマージし、最後にトランクブランチでマージする」ということについてよく読みました。それは呼ばれます マージワークフロー そこには ここには強制的なものは何もありません. 。幹の枝があるからではありません。 マージして戻らなければなりません 何でも。

慣例により、トランク ブランチは開発の現在の状態を表すことができますが、これは単純な順次プロジェクト、つまり次のようなプロジェクトの場合です。

  • 「事前」開発はありません（次の次のバージョンを準備するため、現在の「トランク」開発と互換性がない変更を意味します）
  • 大規模なリファクタリングはありません（新しい技術的選択をテストするため）
  • 以前のリリースの長期メンテナンスは不要

なぜなら、これらのシナリオの 1 つ (またはすべて) では、4 つの「トランク」、4 つの「現在の開発」が得られ、それらの並行開発で行うすべての作業を必ずしも「トランク」にマージし直す必要があるわけではないからです。

SVN では、タグとブランチは非常に似ています。

鬼ごっこ = 定義された時間のスライス。通常はリリースに使用されます。

支店 = 開発を継続できる定義された時間のスライスでもあり、通常は 1.0、1.5、2.0 などのメジャー バージョンに使用され、リリース時にブランチにタグを付けます。これにより、トランク内の重大な変更を進めながら、実稼働リリースのサポートを継続できます。

トランク = 開発ワークスペース。ここですべての開発が行われ、ブランチ リリースからの変更がマージされます。

実際には正式な意味はありません。フォルダーはSVNのフォルダーです。これらは、プロジェクトを編成する一般的に受け入れられている方法です。

  • トランクは、開発のメインラインを保管する場所です。ブランチ フォルダーはブランチを作成する場所ですが、短い記事で説明するのは難しいです。

  • ブランチは、トランクとは別に作業するプロジェクトのサブセットのコピーです。おそらくそれは、どこにも行かない可能性のある実験用かもしれません。あるいは、安定したら後でトランクにマージし直す次のリリース用かもしれません。

  • また、タグ フォルダーは、通常はリリース チェックポイントで、リポジトリのタグ付きコピーを作成するためのものです。

しかし、先ほども言ったように、SVN にとってフォルダーはフォルダーです。 branch, trunk とタグは単なる慣例です。

私は「コピー」という言葉を多用しています。SVN は実際にはリポジトリ内の完全なコピーを作成しません。

の トランク は、最新のソース コードと機能を保持する開発ラインです。最新のバグ修正とプロジェクトに追加された最新の機能が含まれている必要があります。

の 枝 通常、トランク (または他の開発ライン) から離れて何かを行うために使用されます。 壊す ビルド。新しい機能は多くの場合、ブランチに構築され、その後トランクにマージされます。ブランチには、ブランチ元の開発ラインで必ずしも承認されているとは限らないコードが含まれることがよくあります。たとえば、プログラマはブランチ内の何かで最適化を試み、最適化が満足のいくものになった場合にのみ開発ラインにマージし直すことができます。

の タグ 特定の時点でのリポジトリのスナップショットです。これらに関して開発を行うべきではありません。これらは、クライアントが使用しているものに簡単にアクセスできるように、クライアントにリリースされたもののコピーを取得するために最もよく使用されます。

リポジトリに関する非常に優れたガイドへのリンクは次のとおりです。

Wikipedia の記事も読む価値があります。

さて、それがソフトウェア開発に関するものです。何についても一貫した知識はなく、誰もが独自の方法で開発しているようですが、それはいずれにしても、それが比較的若い分野だからです。

これが私の単純な方法です。

トランク - トランク ディレクトリには、承認され、マージされた最新の作業内容が含まれます。多くの人が告白していることに反して、私のトランクは清潔できちんとした承認された作業専用であり、開発エリアではなくリリースエリアです。

ある特定の時点で、トランクを解放する準備ができているように見えると、トランクにタグが付けられて解放されます。

枝 - Branch ディレクトリには実験と進行中の作業が含まれています。ブランチの下の作業は、トランクへのマージが承認されるまでそこに残ります。私にとって、これはすべての作業が行われる領域です。

例えば：持つことができます 反復-5 製品の開発の第 5 ラウンドに向けて分岐します。 プロトタイプ-9 9 ラウンド目の実験に分岐するなど。

タグ - タグ ディレクトリには、承認されたブランチとトランク リリースのスナップショットが含まれています。ブランチがトランクへのマージが承認されるか、トランクからリリースが作成されると、承認されたブランチまたはトランク リリースのスナップショットがタグの下に作成されます。

タグを使用すると、時間をかけて興味のあるポイントに簡単に行き来できると思います。

の Web サイトを調べていたときに、SVN に関するこの素晴らしいチュートリアルを見つけました。 著者 の OpenCV 2 Computer Vision Application Programming Cookbook を共有する必要があると思いました。

彼は、SVN の使用方法と、「トランク」、「タグ」、「ブランチ」というフレーズの意味についてのチュートリアルを提供しています。

彼のチュートリアルから直接引用:

チームが現在作業しているソフトウェア プロジェクトの現在のバージョンは、通常、 というディレクトリの下にあります。 トランク. 。プロジェクトが進化するにつれて、開発者はそのバージョンを更新し、バグを修正し、新機能を追加し、そのディレクトリに変更を送信します。

任意の時点で、バージョンをフリーズし、開発のこの段階でのソフトウェアのスナップショットをキャプチャすることができます。これは通常、ソフトウェアの公式バージョン (クライアントに配信するバージョンなど) に対応します。これらのスナップショットは、 タグ プロジェクトのディレクトリ。

最後に、ある時点でソフトウェアの新しい開発ラインを作成すると役立つことがよくあります。これは、たとえば、ソフトウェアを変更する必要がある代替実装をテストしたいが、新しいソリューションを採用するかどうかを決定するまでこれらの変更をメイン プロジェクトに送信したくない場合に発生します。他の開発者がプロ​​トタイプに取り組んでいる間、メイン チームはプロジェクトの作業を続けることができます。プロジェクトのこれらの新しい開発ラインを、 というディレクトリの下に置きます。 枝.

トランク ディレクトリは、最新の変更を保持するために使用されるため、おそらく最もよく知られているディレクトリです。メインのコードベースはトランクにある必要があります。

ブランチ ディレクトリは、ブランチが何であれ、ブランチを保持するためのディレクトリです。

タグ ディレクトリは基本的に、特定のファイル セットにタグを付けるためのものです。これは、リリースなどで、これらのリビジョンで「1.0」をこれらのファイルにし、「1.1」をこれらのリビジョンでこれらのファイルにしたい場合に行います。通常、タグを作成した後は変更しません。タグの詳細については、「」を参照してください。 第4章。分岐と結合 （で Subversion によるバージョン管理).

誰もが微妙に異なる定義を持っている理由の 1 つは、Subversion が実装しているためです。 ゼロ ブランチとタグのサポート。Subversion は基本的に次のように述べています。 私たちは見ました フル機能の 他のシステムのブランチとタグは役に立たなかったので、何も実装しませんでした。新しいディレクトリに名前を付けてコピーを作成するだけです 大会 その代わり. 。もちろん、誰もが多少異なる慣例を持つことは自由です。の違いを理解するには、 本物 タグと単なるコピー +ネーミングコンベンションウィキペディアエントリを参照してください Subversion のタグとブランチ.

タグ = 定義された時間のスライス。通常はリリースに使用されます。

これが一般的に「タグ」という言葉で意味されるものだと思います。しかし、Subversion では次のようになります。

実際には正式な意味はありません。フォルダーはSVNへのフォルダーです。

これはかなり混乱を招くと思います:ブランチやタグについて何も知らないリビジョン管理システム。実装の観点から見ると、「コピー」を作成する Subversion の方法は非常に賢いと思いますが、それについて知っておく必要があるのは、いわゆる「コピー」です。 漏れやすい抽象化.

それとも私がただ使っているだけなのかもしれません CVS 長すぎます。

混乱の一部は、タグの概念と SVN での実装の違いから生じていると思います。SVN にとって、タグはコピーであるブランチです。タグを変更することは間違っていると考えられており、実際、TortoiseSVN などのツールは、../tags/.. で何かを変更しようとすると警告を出します。道中で。

「タグ」が何なのかはよくわかりませんが、ブランチはかなり一般的なソース管理の概念です。

基本的に、ブランチはトランクに影響を与えずにコードの変更に取り組む方法です。かなり複雑な新機能を追加したいとします。変更を加えたときにその変更をチェックインできるようにしたいが、機能が完了するまではトランクに影響を与えたくないでしょう。

まずブランチを作成します。これは基本的に、ブランチを作成した時点のトランクのコピーです。その後、すべての作業をブランチ内で行うことになります。ブランチで行われた変更はトランクに影響を与えないため、トランクは引き続き使用でき、他のユーザーがそこで作業を続けることができます（バグ修正や小さな機能強化など）。機能が完了したら、ブランチをトランクに統合し直します。これにより、すべての変更がブランチからトランクに移動されます。

ブランチに使用するパターンは多数あります。複数のメジャー バージョンが同時にサポートされている製品がある場合、通常は各バージョンがブランチになります。私が働いている場所には、QA ブランチとプロダクション ブランチがあります。コードを QA にリリースする前に、変更を QA ブランチに統合し、そこからデプロイします。実稼働環境にリリースするときは、QA ブランチから実稼働ブランチに統合するため、実稼働環境で実行されているコードが QA がテストしたものと同一であることがわかります。

こちらが 枝に関するウィキペディアのエントリ, 、おそらく彼らは私よりもうまく説明しているからです。:)

GIT に詳しい人にとって、GIT のマスターは SVN のトランクに相当します。

ブランチとタグは、GIT と SVN の両方で同じ用語を使用します。

トランク :アジャイルでのすべてのスプリントが完了すると、部分的に出荷可能な製品が完成します。これらのリリースはトランクに保管されます。

支店 :進行中の各スプリントのすべての並行開発コードはブランチに保持されます。

タグ :部分的に出荷可能な製品の種類のベータ版をリリースするたびに、そのタグを作成します。これにより、その時点で利用可能なコードが得られ、開発中のある時点で必要に応じてその状態に戻ることができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top