Subversionリポジトリで「ブランチ」、「タグ」、「トランク」は何を意味しますか？
回答:
うーん、Nick re tagがブランチに似ていることに同意するかどうかはわかりません。タグは単なるマーカーです
プロジェクトの開始から現在に至るまで、トランクが開発の主体となります。
ブランチは、トランク内のコードの整合性を維持しながらコードに大きな変更を適用するために使用されるトランク内の特定のポイントから派生したコードのコピーになります。大きな変更が計画通りに機能する場合、それらは通常トランクにマージされます。
タグは、保持したい幹または枝の特定の時点になります。保存の2つの主な理由は、これがアルファ、ベータ、RC、またはRTMに関係なく、ソフトウェアのメジャーリリースであるか、トランクのメジャーリビジョンが適用される前のソフトウェアの最も安定したポイントであることです。
オープンソースプロジェクトでは、プロジェクトの利害関係者によってトランクに受け入れられない主要なブランチがフォークのベースになる可能性があります。たとえば、他のソースコードと共通の起源を共有する完全に別個のプロジェクトです。
ブランチとタグのサブツリーは、次の方法でトランクと区別されます。
Subversionを使用すると、sysadmin は特定のイベントが発生したときに実行をトリガーするフックスクリプトを作成できます。たとえば、変更をリポジトリにコミットします。一般的なSubversionリポジトリの実装では、「/ tag /」を含むパスを作成後に書き込み禁止にして扱うことが非常に一般的です。最終的には、タグは、作成されると（少なくとも「通常の」ユーザーにとって）不変になります。これは、タグが変更されたオブジェクトの親ノードである場合、それ以上の変更を防ぐことによって不変性を適用するフックスクリプトを介して行われます。
Subversionには、バージョン1.5以降の「ブランチマージトラッキング」に関連する機能も追加されています。これにより、ブランチにコミットされた変更をトランクにマージし、インクリメンタルな「スマート」マージをサポートできます。
Tagsディレクトリは、通常のユーザーによるマイルストーンのテストと検証にもよく使用されます。これは、プロトタイプを配置するのにも適しています（私の頭の上にいくつかのアイデアを追加するだけです）。
まず、@ 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リリースバージョン
- tags / 1.0.0-1.0.0リリースバージョン
コードのいくつかのバグに遭遇し、それらをトランクで修正してから、修正を1.0ブランチにマージします。また、反対のことを行って、1.0ブランチのバグを修正してからトランクにマージすることもできますが、通常、プロジェクトは一方向にマージすることで、何かを見落とす可能性を減らします。バグは1.1で廃止されたため、1.0でのみ修正できる場合があります。それは本当に問題ではありません：1.0で修正された同じバグで1.1をリリースしないことを確認したいだけです。
- トランク/-開発バージョン、間もなく1.1
- Branchs / 1.0-次の1.0.1リリース
- tags / 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
- Branchs / 1.0-次の1.0.2リリース
- tags / 1.0.0-1.0.0リリースバージョン
- tags / 1.0.1-1.0.1リリースバージョン
最終的には、1.1をリリースする準備がほぼ整いましたが、最初にベータ版を実行したいと考えています。この場合、おそらく「1.1」ブランチと「1.1beta1」タグを実行します。現在、1.2（または2.0の可能性あり）に関する作業はトランクで継続されていますが、1.1の作業は「1.1」ブランチで継続されています。
- trunk /-開発バージョン、間もなく1.2になる
- Branchs / 1.0-次の1.0.2リリース
- Branchs / 1.1-次の1.1.0リリース
- tags / 1.0.0-1.0.0リリースバージョン
- tags / 1.0.1-1.0.1リリースバージョン
- tags / 1.1beta1-1.1ベータ1リリースバージョン
1.1 finalをリリースしたら、「1.1」ブランチから「1.1」タグを実行します。
また、必要に応じて1.0を維持し続け、3つのブランチ（1.0、1.1、およびトランク）間でバグ修正を移植することもできます。重要なポイントは、維持しているソフトウェアのメインバージョンごとに、そのバージョンの最新バージョンのコードを含むブランチがあることです。
ブランチのもう1つの用途は機能です。ここで、トランク（またはリリースブランチの1つ）を分岐し、新しい機能を分離して作業します。機能が完成したら、それをマージしてブランチを削除します。
- trunk /-開発バージョン、間もなく1.2になる
- Branchs / 1.1-次の1.1.0リリース
- ブランチ/ ui-rewrite-実験的な機能ブランチ
このアイデアは、破壊的なもの（他の人の作業を妨げたり妨げたりするもの）、実験的なもの（うまくいかないこともある）、またはおそらく時間がかかるものに取り組んでいるときです。 （そして、トランクから1.2を分岐する準備ができているときに1.2リリースを保留している場合は、恐れます）、分岐で分離して実行できます。一般的には、変更を常にマージすることで、trunkを最新の状態に保ちます。これにより、完了時に再統合（trunkにマージ）しやすくなります。
また、ここで使用したバージョン管理スキームは、多くの1つにすぎません。一部のチームは、バグ修正/メンテナンスリリースを1.1、1.2などとし、主要な変更を1.x、2.xなどとします。ここでの使用法は同じですが、ブランチに「1」または「1」という名前を付けることができます。 「1.0」または「1.0.x」の代わりに「.x」。（さておき、セマンティックバージョニングは、バージョン番号の作成方法に関する優れたガイドです）。
Nickの発言に加えて、Streamed Lines：Parallel Software Developmentの分岐パターンで詳細を確認できます。
この図で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へのフォルダです。これらは、プロジェクトを整理するために一般的に受け入れられている方法です。
トランクは、開発のメインラインを維持する場所です。ブランチフォルダーは、短い投稿では説明するのが難しいブランチを作成する場所です。
ブランチは、トランクとは別に作業するプロジェクトのサブセットのコピーです。多分それはどこにも行かないかもしれない実験のためであるかもしれません、あるいは多分それは後でそれが安定したときにトランクに再びマージする次のリリースのためです。
また、tagsフォルダは、通常リリースチェックポイントで、リポジトリのタグ付きコピーを作成するためのものです。
しかし、私が言ったように、SVNにとって、フォルダーはフォルダーです。branch、trunkタグは単なる慣例です。
「コピー」という言葉をふんだんに使っています。SVNは実際にはリポジトリにあるものの完全なコピーを作成しません。
トランクは、最新のソースコードと機能を保持している開発ラインです。プロジェクトには、最新のバグ修正と最新の機能が追加されているはずです。
枝は通常、そうでないでしょうトランク（または他の開発ライン）から何かを離れて行うために使用されている破るビルドを。多くの場合、新しい機能はブランチに組み込まれ、その後トランクにマージされます。ブランチには、ブランチ元の開発ラインで必ずしも承認されていないコードが含まれていることがよくあります。たとえば、プログラマはブランチ内の何かに対して最適化を試み、最適化が満足できるものになって初めて開発ラインにマージし直すことができます。
タグは、特定の時点でのリポジトリのスナップショットです。これらの開発は発生しません。ほとんどの場合、クライアントにリリースされたもののコピーを取得して、クライアントが使用しているものに簡単にアクセスできるようにするために使用されます。
リポジトリへの非常に優れたガイドへのリンクは次のとおりです。
ウィキペディアの記事も読む価値があります。
それがソフトウェア開発のことです。何かについて一貫した知識はなく、誰もが独自の方法を持っているようですが、それはとにかく比較的若い分野だからです。
これが私のシンプルでシンプルな方法です。
トランク -トランクディレクトリには、最新の承認済みのマージされた一連の作業が含まれています。多くの人が告白したこととは逆に、私のトランクは、クリーンできちんとした承認された作業のためだけのものであり、開発領域ではなくリリース領域用です。
トランクがすべて解放する準備ができていると思われるある時点で、タグが付けられて解放されます。
ブランチ -ブランチディレクトリには、実験と進行中の作業が含まれています。ブランチの下での作業は、トランクへのマージが承認されるまでそのままです。私にとって、これはすべての作業が行われる領域です。
たとえば、製品の5回目の開発では反復5のブランチを、9回目の実験ではプロトタイプ9のブランチを作成できます。
タグ -tagsディレクトリには、承認されたブランチとトランクのリリースのスナップショットが含まれています。ブランチがトランクにマージすることが承認されるか、トランクからリリースが作成されると、承認されたブランチまたはトランクリリースのスナップショットがタグの下に作成されます。
タグがあれば、時間の前後に非常に簡単に興味のあるポイントにジャンプできます。
OpenCVの作者のWebサイトを調べているときに、SVNに関するこの素晴らしいチュートリアルを見つけました 2コンピュータービジョンアプリケーションプログラミングクックブック。
彼はSVNの使い方と「トランク」、「タグ」、「ブランチ」というフレーズの意味についてのチュートリアルを持っています。
彼のチュートリアルから直接引用：
チームが現在作業しているソフトウェアプロジェクトの現在のバージョンは、通常、trunkというディレクトリの下にあります。ます。プロジェクトが発展するにつれて、開発者はそのバージョンを更新してバグを修正し、新しい機能を追加します）、そのディレクトリの下で変更を送信します。
いつでも、開発のこの段階で、バージョンをフリーズしてソフトウェアのスナップショットをキャプチャすることができます。これは通常、ソフトウェアの公式バージョン（たとえば、クライアントに配信するバージョン）に対応しています。これらのスナップショットはタグの下にあります、プロジェクトのディレクトリのあります。
最後に、ある時点で、ソフトウェアの新しい開発ラインを作成すると便利なことがよくあります。これは、たとえば、ソフトウェアを変更する必要がある代替実装をテストしたいが、新しいソリューションを採用するかどうかを決定するまでこれらの変更をメインプロジェクトに送信したくない場合に発生します。その後、メインチームは引き続きプロジェクトに取り組み、他の開発者はプロトタイプに取り組みます。これらの新しいプロジェクト開発行を、branchesと呼ばれるディレクトリの下に置きます。
トランクディレクトリは、最新の変更を保持するために使用されるため、おそらく最もよく知っているディレクトリです。メインのコードベースはトランクにある必要があります。
ブランチディレクトリは、ブランチを保持するためのものです。
タグディレクトリは基本的に、特定のファイルセットにタグを付けるためのものです。これはリリースなどの場合に行います。「1.0」をこれらのリビジョンのこれらのファイルに、「1.1」をこれらのリビジョンのこれらのファイルにしたいとします。一度作成されたタグは通常、変更しません。タグの詳細については、第4章を参照してください（Subversionによるバージョン管理）。
誰もがわずかに異なる定義を持っている理由の1つは、Subversion がブランチとタグのゼロサポートを実装しているためです。Subversionは基本的に次のように述べています。他のシステムでフル機能のブランチとタグを調べたところ、それらが役に立たなかったため、何も実装しませんでした。代わりに、命名規則を使用して新しいディレクトリにコピーを作成してください。そしてもちろん、誰もがわずかに異なる規則を自由に持つことができます。実際のタグと単なるコピー+命名規則の違いを理解するには、WikipediaのSubversionタグとブランチを参照してください。
タグ=時間の定義されたスライス。通常、リリースに使用されます
これが「タグ」が通常意味することだと思います。しかしSubversionでは：
正式な意味はありません。フォルダは、SVNへのフォルダです。
私はどちらかと言えば混乱します：ブランチやタグについて何も知らないリビジョン管理システム。実装の観点からは、「コピー」を作成するSubversionの方法は非常に賢明だと思いますが、それについて知っている必要があるのは、私がリークのある抽象化と呼んでいるものです。
あるいは、CVSを使いすぎたのかもしれません。
タグの概念とSVNでの実装の違いから混乱が生じていると思います。SVNにとって、タグはコピーであるブランチです。タグの変更は間違っていると考えられており、パスに../tags/ ..を含むものを変更しようとすると、TortoiseSVNなどのツールが警告を出します。
「タグ」が何であるか本当にわかりませんが、ブランチはかなり一般的なソース管理の概念です。
基本的に、ブランチはトランクに影響を与えずにコードの変更に取り組む方法です。かなり複雑な新機能を追加したいとします。変更を加えたときにチェックインできるようにしたいが、機能が終了するまでトランクに影響を与えたくない。
まず、ブランチを作成します。これは基本的に、ブランチを作成した時点のトランクのコピーです。その後、ブランチですべての作業を行います。ブランチで行われた変更はトランクに影響を与えないため、トランクは引き続き使用可能であり、他の人がそこで作業を続けることができます（バグ修正や小さな機能強化など）。機能が完成したら、ブランチをトランクに統合します。これにより、すべての変更がブランチからトランクに移動します。
ブランチで使用するパターンは多数あります。複数のメジャーバージョンが同時にサポートされている製品がある場合、通常は各バージョンがブランチになります。私が働いている場所には、QAブランチと本番ブランチがあります。コードをQAにリリースする前に、変更をQAブランチに統合し、そこからデプロイします。本番環境にリリースするときは、QAブランチから本番ブランチに統合するため、本番環境で実行されているコードはQAがテストしたものと同じであることがわかります。
ここだ枝にWikipediaのエントリは、私ができるよりも、彼らはおそらくより良いものを説明しているので、。:)