Subversionのリポジトリで、"branch", "tag", "trunk" は何を意味するのでしょうか?

この言葉はSubversion(というか一般的なリポジトリ)の議論でよく見かけるようになりました。 私はここ数年、自分のプロジェクトにSVNを使用していますが、これらのディレクトリの完全な概念を把握したことはありません。

これらは何を意味するのでしょうか?

質問へのコメント (1)
ソリューション

うーん、ニック・リタグが枝に似ていることに同意するかどうかはわかりません。 タグは単なるマーカーです。

- Trunk は、プロジェクトの開始から現在までの開発の主要な組織になります。

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

-タグは、トランクまたはブランチの保存時点になります。 保存の2つの主な理由は、これがアルファ、ベータ、RC、RTMのいずれであってもソフトウェアのメジャーリリースであるか、トランクの大幅な改訂が適用される前のソフトウェアの最も安定したポイントであることです。

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

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

Subversionを使用すると、sysadminsはフックスクリプトを作成できます。これは、特定のイベントが発生したときに実行のためにトリガーされます。たとえば、リポジトリに変更を加える。 典型的なSubversionリポジトリの実装では、「/ tag /」を含むパスを処理して、作成後に書き込み保護することが非常に一般的です。最終的な結果は、作成されたタグが不変であるということです(少なくとも「通常の」ユーザーに対して)。 これは、 tag が変更されたオブジェクトの親ノードである場合に、さらなる変更を防止することにより、不変性を強制するフックスクリプトを介して行われます。

Subversionには、「ブランチマージトラッキング」に関連するバージョン1.5以降の機能も追加されているため、ブランチにコミットされた変更は、増分された「スマート」マージをサポートしてトランクにマージできます。

解説 (11)

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

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

  • トランク:主な開発分野。 これは、コードの次のメジャーリリースが存在する場所であり、一般的にすべての最新機能を備えています。

  • ブランチ:メジャーバージョンをリリースするたびに、ブランチが作成されます。 これにより、最新の(おそらく未完成または未テストの)機能をリリースする必要なく、バグ修正を行い、新しいリリースを作成できます。

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

    • -。

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

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

1.0.0が終了すると、トランクを新しい「1.0」ブランチに分岐し、「1.0.0」タグを作成します。 次に、最終的に1.1になるものについてトランクで作業を続けます。

*トランク/-開発バージョン、まもなく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 になります。 ブランチ/ 1.0-今後の1.0.2リリース。

  • ブランチ/ 1.1-今後の1.1.0リリースタグ/1.0.0-1.0.0リリースバージョン。 タグ/1.0.1-1.0.1リリースバージョン。
  • タグ/ 1.1beta1-1.1ベータ1リリースバージョン

1.1ファイナルをリリースしたら、「1.1」ブランチから「1.1」タグを実行します。

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

    • -。

ブランチの別の用途は機能です。 ここで、トランク(またはリリースブランチの1つ)を分岐し、新しい機能を個別に操作します。 機能が完了したら、機能をマージしてブランチを削除します。

トランク/-開発バージョン、間もなく1.2になります。 ブランチ/ 1.1-今後の1.1.0リリース。

  • ブランチ/ウイ-ルライト-実験機能ブランチ

これのアイデアは、あなたと#39のときです。;破壊的な何かに取り組んでいます。 (それは他の人々が彼らの仕事をするのを妨げたり妨げたりするでしょう。) 何か実験的。 (それも入らないかもしれません。) またはおそらく長い時間がかかるもの。 (そしてあなたと#39。;あなたが&#39のときに1.2リリースを保持している場合は、恐れてください。;トランクから1.2を分岐する準備ができています。) ブランチで単独で行うことができます。 通常、変更を常にマージしてトランクで最新の状態に保つため、完了時に再統合(トランクへのマージバック)が容易になります。

    • -。

また、ここで使用したバージョニングスキームは、多くの1つにすぎません。 一部のチームは、バグ修正/メンテナンスリリースを1.1、1.2などとして実行します。、および1.x、2.xなどの主要な変更. ここでの使用法は同じですが、「1.0」または「1.0.x」の代わりに「1」または「1.x」というブランチを指定できます。 (側面、セマンティックバージョンは、バージョン番号の実行方法に関する優れたガイドです)。

解説 (7)

Nickの発言に加えて、Streamed Lines:Branching Patterns for Parallel Software Developmentで詳細を確認できます。

ここに画像の説明を入力してください。! この図では、「main」はトランク、「rel1-maint」はブランチ、「1.0」はタグです。

解説 (4)

一般的に(ツール不可知論ビュー)、ブランチは並列開発に使用されるメカニズムです。 SCMには0からnの分岐があります。 Subversionには0があります。

  • Trunk はメインブランチ推奨 Subversionですが、強制的に作成する必要はありません。 あなたはそれを「メイン」または「リリース」と呼ぶか、まったく持っていないかもしれません。!

  • ブランチは開発努力を表しています。 リソース( 'vonc_branch'など)にちなんで名付けないでください。 -目的「myProject_dev」または「myProject_Merge」。 -リリース境界 'myProjetc1.0_dev'またはmyProject2.3_Merge'または 'myProject6。.2_Patch1 '。..

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

    Subversionに付属のアクセス制御スクリプトの1つを使用して、タグ領域に新しいコピーを作成する以外のことをしないようにすることができます。

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

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

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

-「事前」開発なし(現在の「トランク」開発と互換性がないような変更を示唆する次のバージョンを準備するため)。 -大規模なリファクタリングはありません(新しい技術的な選択をテストするため)。 -以前のリリースの長期メンテナンスはありません。

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

解説 (1)

SVNでは、タグとブランチは本当によく似ています。

タグ = 定義された時間的なスライスで、通常リリースに使用されます。

ブランチ = 開発を継続するための時間的なスライスで、通常1.0, 1.5, 2.0 などのメジャーバージョンに使用され、リリース時にブランチにタグ付けされます。 これにより、トランクの変更を進めながら、製品リリースをサポートし続けることができます。

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

解説 (0)

正式な意味はないんです。フォルダはフォルダです をSVNに追加します。プロジェクトを整理するための一般的な方法です。

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

  • ブランチとは、トランクとは別に作業する、プロジェクトのサブセットのコピーです。ブランチとは、トランクとは別に作業する、あなたのプロジェクトのサブセットのコピーです。

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

しかし、先ほども言ったように、SVNでは、フォルダはフォルダです。ブランチ、トランク、タグは単なる慣例です。

私は 'コピー'という言葉を自由に使っています。SVNは実際にはリポジトリにあるものを完全にコピーするわけではありません。

解説 (0)

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

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

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

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

-ソースコントロールHOWTO

ウィキペディアの記事も読む価値があります。

解説 (0)

これがソフトウェア開発の問題です。何についても一貫した知識はありません。誰もが独自の方法で持っているようですが、それはとにかく比較的若い分野だからです。

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

trunk -トランクディレクトリには、最新の承認済みでマージされた一連の作業が含まれています。 多くの人が告白したこととは逆に、私のトランクは清潔できちんとした承認された作業のためだけであり、開発エリアではなく、リリースエリアです。

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

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

例:製品の5回目の開発では iteration-5 ブランチ、9回目の実験では prototype-9 ブランチなどを使用できます。

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

タグを使用すると、時間を前後にジャンプして興味を簡単に指摘できると思います。

解説 (0)

OpenCV 2コンピュータビジョンアプリケーションプログラミングクックブックの作成者のWebサイトを調べていたときに、SVNに関するこの素晴らしいチュートリアルを見つけました。共有する必要があると思いました。

彼はSVNの使用方法と、「trunk」、「tag」、「branch」というフレーズの意味についてのチュートリアルを持っています。

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

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

いつでも、バージョンをフリーズして、ソフトウェアのスナップショットをキャプチャすることができます。これは、開発のこの段階にあるためです。 これは通常、ソフトウェアの公式バージョンに対応します。たとえば、クライアントに配信するバージョンです。 これらのスナップショットは、プロジェクトの tags ディレクトリの下にあります。

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

解説 (0)

誰もがわずかに異なる定義を持っている理由の1つは、Subversionがブランチやタグのゼロサポートを実装しているためです。 Subversionは基本的に次のように述べています。他のシステムでは、フル機能のブランチやタグを見て、それらが有用であるとは考えなかったので、何も実装しませんでした。 代わりに名前の規則を持つ新しいディレクトリにコピーを作成するだけです。 そしてもちろん、誰もが少し異なる慣習を自由に持つことができます。 実際のタグと単なるコピー+命名規則の違いを理解する。 ウィキペディアのエントリを参照してください Subversionタグ&ブランチ *。

解説 (0)

trunk ディレクトリは、おそらくみなさんが最もよくご存知のディレクトリで、最新の変更点を保持するために使用されます。あなたのメインコードベースは trunk にあるべきでしょう。

branches ディレクトリは、ブランチ (枝) を格納するためのもので、ブランチが何であろうと構いません。

tags ディレクトリは、基本的に、特定のファイルにタグを付けるためのものです。リリースのように、 "1.0" はこのリビジョンではこのファイル、 "1.1" はこのリビジョンではこのファイル、というようなことをするのです。通常、一度作成したタグを変更することはありません。タグについてのより詳しい情報は、 第4章 ブランチとマージ (Subversionによるバージョン管理) を参照してください。

解説 (0)

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

これは「タグ」で通常意味することだと思います。 しかし、Subversionでは:

彼らは本当に正式な意味を持っていません。 フォルダはSVNのフォルダです。

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

あるいは、CVSを使いすぎたのかもしれません。

解説 (1)

混乱の一部は、タグの概念とSVNでの実装の違いに起因していると思います。 SVNにとって、タグはコピーであるブランチです。 タグの変更は間違っていると見なされ、実際にはTortoiseSVNのようなツールは、何かを変更しようとすると警告します。 ../タグ/。. パスで。

解説 (0)

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

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

まず、ブランチを作成します。 これは基本的に、ブランチを作成したときのトランクのコピーです。 その後、すべての作業をブランチで実行します。 ブランチで加えられた変更はトランクに影響を与えないため、トランクは引き続き使用可能であり、他の人が(バグ修正や小さな拡張機能など)作業を続けることができます。 機能が完了すると、ブランチをトランクに統合します。 これにより、すべての変更がブランチからトランクに移動します。

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

Wikipediaの支店のエントリです。おそらく私よりもよく説明されているからです。 :)。

解説 (0)

GITに詳しい人にとって、GITのマスターはSVNのトランクと同等です。

ブランチとタグは、GITとSVNの両方で同じ用語を持っています。

解説 (0)

トランク:アジャイル内のすべてのスプリントが完了した後、部分的にシッピング可能な製品が出てきます。 これらのリリースはトランクに保管されます。

ブランチ:進行中のスプリントごとに並列開発コードはすべてブランチに保管されます。

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

解説 (1)