私はこれらの言葉をSubversion（そして私は一般的なリポジトリだと思います）の議論の周りでたくさん見ました。
私はここ数年プロジェクトにSVNを使用していますが、これらのディレクトリの完全な概念を理解したことはありません。
それらはどういう意味ですか？
grapefrukt
質問する
449696 次
16 に答える
920
うーん、ニックのタグがブランチに似ていることに同意するかどうかはわかりません。タグは単なるマーカーです
トランクは、プロジェクトの開始から現在に至るまでの開発の主体となるでしょう。
ブランチは、トランク内のコードの整合性を維持しながら、コードに大きな変更を適用するために使用される、トランク内の特定のポイントから派生したコードのコピーになります。主要な変更が計画どおりに機能する場合、通常、それらはトランクにマージされます。
タグは、保存したいトランクまたはブランチ上の特定の時点になります。保存の2つの主な理由は、これがアルファ、ベータ、RC、RTMのいずれのソフトウェアのメジャーリリースであるか、トランクのメジャーリビジョンが適用される前のソフトウェアの最も安定したポイントであるかです。
オープンソースプロジェクトでは、プロジェクトの利害関係者によってトランクに受け入れられない主要なブランチがフォークのベースになる可能性があります。たとえば、他のソースコードと共通の起源を共有する完全に別個のプロジェクトです。
ブランチとタグのサブツリーは、次の方法でトランクと区別されます。
Subversionを使用すると、システム管理者は、特定のイベントが発生したときに実行のためにトリガーされるフックスクリプトを作成できます。たとえば、リポジトリへの変更をコミットします。典型的なSubversionリポジトリの実装では、「/tag/」を含むパスを作成後に書き込み保護するように扱うのが非常に一般的です。最終的な結果として、タグが作成されると、（少なくとも「通常の」ユーザーにとっては）不変になります。これは、タグが変更されたオブジェクトの親ノードである場合にそれ以上の変更を防ぐことによって不変性を強制するフックスクリプトを介して行われます。
Subversionは、バージョン1.5以降、「ブランチマージ追跡」に関連する機能も追加しました。これにより、ブランチにコミットされた変更をトランクにマージして、インクリメンタルな「スマート」マージをサポートできます。
于 2008-08-19T13:35:21.603 に答える
558
まず第一に、@AndrewFinnell と @KenLiu が指摘するように、SVN ではディレクトリ名自体は何の意味もありません。「トランク、ブランチ、およびタグ」は、ほとんどのリポジトリで使用される一般的な規則です。すべてのプロジェクトがすべてのディレクトリを使用しているわけではありません (「タグ」をまったく使用しないのはかなり一般的です)。実際、規則を破ると混乱することがよくありますが、好きなように名前を付けることを妨げるものは何もありません。
おそらく最も一般的なブランチとタグの使用シナリオを説明し、それらがどのように使用されるかのシナリオ例を示します。
トランク: 主な開発エリア。これは、コードの次のメジャー リリースが存在する場所であり、通常は最新の機能がすべて含まれています。
ブランチ: メジャー バージョンをリリースするたびに、ブランチが作成されます。これにより、バグ修正を行い、最新の (おそらく未完成または未テストの) 機能をリリースすることなく、新しいリリースを作成できます。
タグ: バージョン (最終リリース、リリース候補 (RC)、およびベータ版) をリリースするたびに、タグを作成します。これにより、その時点のコードのコピーが得られ、必要に応じて過去のバージョンに戻ってバグを再現したり、過去のバージョンをそのまま再リリースしたりできます。SVN のブランチとタグは軽量です。サーバー上では、ファイルの完全なコピーは作成されず、「これらのファイルはこのリビジョンでコピーされました」というマーカーが数バイトしか使用されないだけです。これを念頭に置いて、リリースされたコードのタグの作成について心配する必要はありません。先に述べたように、タグは省略されることが多く、代わりに、リリース時に変更ログまたはその他のドキュメントでリビジョン番号が明確になります。
たとえば、新しいプロジェクトを開始するとします。最終的にバージョン 1.0 としてリリースされるものについて、「トランク」で作業を開始します。
- Trunk/ - 開発バージョン、まもなく 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 になります
- ブランチ/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 になります
- ブランチ/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" ブランチで続行されます。
- トランク/ - 開発バージョン、まもなく 1.2 になります
- ブランチ/1.0 - 1.0.2 リリース予定
- ブランチ/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 つ) を分岐し、新しい機能を分離して作業する場所です。機能が完成したら、マージしてブランチを削除します。
- トランク/ - 開発バージョン、まもなく 1.2 になります
- ブランチ/1.1 - 1.1.0 リリース予定
- branch/ui-rewrite - 実験的な機能ブランチ
これは、破壊的なもの (他の人が仕事をするのを妨げたり妨げたりするもの)、実験的なもの (受け入れられないかもしれないもの)、または単に時間がかかるものに取り組んでいるときの考え方です。 (そして、トランクから 1.2 をブランチする準備ができているときに 1.2 のリリースを遅らせているのではないかと恐れています)、ブランチで分離して行うことができます。通常、変更をトランクに常にマージすることでトランクを最新の状態に保ちます。これにより、終了時に再統合 (トランクにマージして戻す) が容易になります。
また、ここで使用したバージョン管理スキームは、数多くあるものの 1 つにすぎないことに注意してください。一部のチームは、バグ修正/メンテナンス リリースを 1.1、1.2 などとして、主要な変更を 1.x、2.x などとして行います。ここでの使用法は同じですが、ブランチの名前を「1」または「1」にすることができます。 「1.0」または「1.0.x」の代わりに.x」。(さておき、セマンティック バージョニングは、バージョン番号の付け方に関する優れたガイドです)。
于 2008-09-20T19:00:20.377 に答える
97
Nick の発言に加えて、 Streamed Lines: Branching Patterns for Parallel Software Developmentで詳細を確認できます。
この図mainで は幹、rel1-maintは枝、1.0はタグです。
于 2008-08-19T13:58:18.107 に答える
76
一般に (ツールに依存しないビュー)、ブランチは並行開発に使用されるメカニズムです。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 つの「現在の開発」が得られ、これらの並行開発で行うすべてを必ずしも「トランク」にマージする必要があるわけではありません。
于 2008-09-22T11:44:36.913 に答える
39
SVNでは、タグとブランチは非常に似ています。
タグ=定義された時間内のスライス、通常はリリースに使用されます
ブランチ=また、開発を継続できる時間内に定義されたスライスであり、通常は1.0、1.5、2.0などのメジャーバージョンで使用され、リリース時にブランチにタグを付けます。これにより、トランクの重大な変更を進めながら、本番リリースを引き続きサポートできます。
トランク=開発ワークスペース。これはすべての開発が行われる場所であり、変更はブランチリリースからマージされます。
于 2008-08-19T13:25:17.410 に答える
32
それらは実際には正式な意味を持っていません。フォルダーはSVNへのフォルダーです。これらは、プロジェクトを整理するための一般的に受け入れられている方法です。
トランクは、開発のメインラインを維持する場所です。ブランチフォルダは、短い投稿で説明するのが難しいブランチを作成する場所です。
ブランチは、トランクとは別に作業するプロジェクトのサブセットのコピーです。多分それはどこにも行かないかもしれない実験のためであるかもしれません、あるいは多分それは次のリリースのためであり、それは後で安定したときにトランクにマージされます。
また、tagsフォルダーは、通常はリリースチェックポイントで、リポジトリのタグ付きコピーを作成するためのものです。
しかし、私が言ったように、SVNにとって、フォルダーはフォルダーです。branch、trunkおよびタグは単なる慣例です。
私は「コピー」という言葉を自由に使っています。SVNは、実際にはリポジトリ内の物の完全なコピーを作成しません。
于 2008-08-19T13:27:23.193 に答える
13
トランクは、最新のソースコードと機能を保持する開発ラインです。プロジェクトに追加された最新の機能だけでなく、最新のバグ修正が含まれている必要があります。
ブランチは通常、トランク（または他の開発ライン）から離れて何かを行うために使用されます。多くの場合、新しい機能はブランチに組み込まれ、トランクにマージされます。ブランチには、ブランチ元の開発ラインで必ずしも承認されていないコードが含まれていることがよくあります。たとえば、プログラマーはブランチ内の何かで最適化を試み、最適化が満足のいくものになったときにのみ開発ラインにマージすることができます。
タグは、特定の時点でのリポジトリのスナップショットです。これらの開発は発生しないはずです。これらは、クライアントにリリースされたもののコピーを取得するために最もよく使用されるため、クライアントが使用しているものに簡単にアクセスできます。
リポジトリへの非常に優れたガイドへのリンクは次のとおりです。
ウィキペディアの記事も読む価値があります。
于 2008-08-19T13:37:32.893 に答える
12
これがソフトウェア開発の話です。何についても一貫した知識はありません。誰もが独自の方法で進めているように見えますが、それはとにかく比較的新しい分野だからです。
これが私の単純な方法です。
トランク- トランク ディレクトリには、最新の、承認され、マージされた一連の作業が含まれています。多くの人が認めていることとは反対に、私のトランクはクリーンできちんとした、承認された作業専用であり、開発領域ではなくリリース領域です。
トランクがすべてリリースの準備ができていると思われる特定の時点で、タグが付けられてリリースされます。
ブランチ- ブランチ ディレクトリには、実験と進行中の作業が含まれています。ブランチの下での作業は、トランクへのマージが承認されるまでそこにとどまります。私にとって、これはすべての作業が行われる領域です。
例:製品の 5 回目の開発用にイテレーション 5ブランチ、9 回目の実験用にプロトタイプ 9ブランチなどを作成できます。
tags - tags ディレクトリには、承認されたブランチとトランク リリースのスナップショットが含まれています。ブランチのトランクへのマージが承認されるか、トランクのリリースが作成されるたびに、承認されたブランチまたはトランクのリリースのスナップショットがタグの下に作成されます。
タグを使えば、興味のあるポイントを簡単に前後にジャンプできると思います。
于 2009-06-30T11:50:56.570 に答える
10
OpenCV 2 Computer Vision Application Programming Cookbook の著者のWeb サイトを調べていたときに、SVN に関するこの素晴らしいチュートリアルを見つけたので、共有する必要があると思いました。
彼は、SVN の使用方法と、「トランク」、「タグ」、および「ブランチ」というフレーズの意味に関するチュートリアルを持っています。
彼のチュートリアルから直接引用：
チームが現在作業しているソフトウェア プロジェクトの現在のバージョンは、通常、trunkというディレクトリの下にあります。プロジェクトが進化するにつれて、開発者はそのバージョンを更新してバグを修正し、新しい機能を追加し、その変更をそのディレクトリの下に送信します。
任意の時点で、バージョンをフリーズして、開発のこの段階にあるソフトウェアのスナップショットをキャプチャしたい場合があります。これは通常、ソフトウェアの公式バージョン (クライアントに配布するバージョンなど) に対応します。これらのスナップショットは、プロジェクトのtagsディレクトリの下にあります。
最後に、ある時点で、ソフトウェアの新しい開発ラインを作成すると便利なことがよくあります。これは、たとえば、ソフトウェアを変更する必要がある代替実装をテストしたいが、新しいソリューションを採用するかどうかを決定するまで、これらの変更をメイン プロジェクトに送信したくない場合に発生します。その後、他の開発者がプロトタイプに取り組んでいる間、メイン チームはプロジェクトに取り組み続けることができます。プロジェクトのこれらの新しい開発ラインは、branchesというディレクトリの下に配置します。
于 2011-07-26T08:56:50.567 に答える
9
トランクディレクトリは、最新の変更を保持するために使用されるため、おそらく最もよく知っているディレクトリです。メインのコードベースはトランク内にある必要があります。
ブランチディレクトリは、ブランチが何であれ、ブランチを保持するためのものです。
tagsディレクトリは、基本的に特定のファイルセットにタグを付けるためのものです。これは、リリースなどで、「1.0」をこれらのリビジョンでこれらのファイルにし、「1.1」をこれらのリビジョンでこれらのファイルにする場合に行います。通常、タグが作成された後は変更しません。タグの詳細については、第4章（Subversionを使用したバージョン管理）の分岐とマージを参照してください。
于 2008-08-19T13:28:01.397 に答える
9
誰もがわずかに異なる定義を持っている理由の 1 つは、Subversionがブランチとタグのサポートをまったく実装していないためです。Subversion は基本的に次のように述べています:他のシステムでフル機能のブランチとタグを調べましたが、それらが有用であるとは思わなかったため、何も実装しませんでした。代わりに、命名規則を使用して新しいディレクトリにコピーを作成してください。それからもちろん、誰もが自由にわずかに異なる規則を持つことができます。実際のタグと単なるコピー + 命名規則の違いを理解するには、ウィキペディアのエントリSubversion のタグとブランチを参照してください。
于 2010-11-17T20:39:47.790 に答える
6
混乱の一部は、タグの概念と SVN での実装の違いから来ていると思います。SVN にとって、タグはコピーであるブランチです。タグの変更は間違っていると見なされ、実際、TortoiseSVN のようなツールは、パスに ../tags/.. を含むものを変更しようとすると警告を発します。
于 2008-08-19T17:24:07.100 に答える
5
「タグ」が何であるかはよくわかりませんが、ブランチはかなり一般的なソース管理の概念です。
基本的に、ブランチはトランクに影響を与えることなくコードの変更に取り組む方法です。かなり複雑な新機能を追加したいとします。変更を加えたときにチェックインできるようにしたいが、機能が完了するまでトランクに影響を与えたくない。
まず、ブランチを作成します。これは基本的に、ブランチを作成した時点でのトランクのコピーです。その後、ブランチですべての作業を行います。ブランチで行われた変更はトランクに影響を与えないため、トランクは引き続き使用可能であり、他のユーザーがそこで作業を続けることができます（バグ修正や小さな拡張など）。機能が完了したら、ブランチをトランクに統合します。これにより、すべての変更がブランチからトランクに移動します。
人々が枝に使用するパターンはたくさんあります。複数のメジャーバージョンが同時にサポートされている製品がある場合、通常、各バージョンはブランチになります。私が働いている場所には、QAブランチとプロダクションブランチがあります。コードをQAにリリースする前に、変更をQAブランチに統合し、そこからデプロイします。本番環境にリリースするときは、QAブランチから本番環境ブランチに統合するため、本番環境で実行されているコードはQAがテストしたものと同じであることがわかります。
これがブランチに関するウィキペディアのエントリです。おそらく私よりもうまく説明しているからです。:)
于 2008-08-19T13:34:21.200 に答える
4
GIT に詳しい人にとっては、GIT のマスターは SVN のトランクに相当します。
ブランチとタグは、GIT と SVN の両方で同じ用語を使用します。
于 2018-04-04T05:07:23.993 に答える