上記は、組織内のJavaプロジェクトに使用する予定の構造のモックです。あなたたちはそれについてどう思いますか?従来のように見えますか?また、project1をタグの下に置くと、1.0.1、1.0.2などが表示されます。これらはリリース後に作成されたリリースタグです。さて、Devブランチの下にはどのようなタグが存在するでしょうか?それらはいつ作成されますか?開発者ごとにDevBranchの下にブランチを作成する必要がありますか?私は混乱しています。
8 に答える
皆さんはそれについてどう思いますか?
良くないですよ。通常、さらに、、は含まれbranches
ません。は似ていますが、並行開発の流れです。通常、ブランチはfromまたは fromまたは from anotherで作成します。それ以外はOKです。tags
trunk
branches
Branch
trunk
copy
trunk
tag
branch
それは従来に見えますか?
はい、そうです。
では、Dev ブランチの下にはどのようなタグが存在するのでしょうか?
タグとは、名前を意味します。それらに少しわかりやすい名前を付けることができます..またはproject1_new_caching_mechanism
またはproject1_1.1_spot_fixes
-のように、これはおそらくリリース1.1
タグからコピーされ、リリースの問題のいくつかを修正することを示します. このブランチをリリースすると、これらの修正を他の並列実行ブランチおよびトランクにマージしたいと思うでしょう。
それらはいつ作成されますか?
並行開発シナリオを見つけたときはいつでも。メインの開発ブランチを妨げることなく、負荷テストと改善されたコードを追加することでパフォーマンスを改善したかったように. またはスポット修正用。または機能の置き換えのため..または複数のバージョンのサポートのため。
開発者ごとに DevBranch の下にブランチを作成する必要がありますか?
いいえ。SVN は一元化されたリポジトリです... (Git とは異なり)、SCM の目的は、複数の開発者が同時に作業できるようにすることです...各開発者のリポジトリを分離することで、目的に逆らうことになります。
私が完全に間違っていなければ、Dev(およびExperimental)の下にあると思いますが、ブランチ/タグ/トランクはありません。devブランチのリリースを作成する場合は、ここに配置します。
/svn/projects/project1/tags/dev-1.0.1
またはそのようなもの。たとえば、DevとExperimentalは、各ブランチのトランクフォルダのようなものです。Devからブランチを作成したい場合は、Dev2と呼ぶことができますが、それが必要以上に複雑になっていると思います。
また、私はDevをまったく使用せず、トランク内のDevブランチに属するすべてのことを行います。
/svn/projects/project1/trunk
ただし、追加のDevブランチを用意するのには十分な理由があるかもしれません。
SVNBook(Subversionを使用したバージョン管理)を読む必要があります。タグはそこに属していないと思います。
私はあなたのDev、Experimentalなどが好きではありません。それらが/branchsについてです。完了したら、それらを/ trunkにマージするか、ブランチにぶら下がってください。
タグは、本番環境に移行し、読み取り専用で作成したい場合に使用します。リリースしたブランチのコピーを変更することはできません。
リポジトリを配置するための選択肢があります。
- その下に/trunk、/ branchs、および/ tagsを含む1つのリポジトリーと、それらの下にあるプロジェクト。
- 1つのリポジトリの下に複数のプロジェクトがあり、それぞれの下に独自の/ trunk、/ branchs、および/tagsがあります。
- プロジェクトごとに1つのリポジトリ。それぞれに独自の/trunk、/ branchs、および/tagsがあります。
各機能または開発者が独自のブランチを持ち、機能が実行されるトランクに昇格する「機能ごとのブランチ」が必要なようです。もしそうなら、mercurial や git などの分散型バージョン管理システムを検討してみてください。
svn を使用したい場合 (そして正当な理由があるかもしれません)、2 つの異なるbranch
ディレクトリdev-branches
を用意することをお勧めしますbranches
。開発中に本番環境でバグを修正する)、および両方Experimental
をスクラッチします。Dev
は、私にはよく見えますよ。test
Maven または Ivy で自動化する必要がある場合も追加します。
個人的には、静的スナップショットのタグであるタグ番号の進行中の作業にブランチを使用するのが好きです。そうすることで、 のリリースをフィーチャー フリーズするときが来たら1.0.1
、トランクを にコピーし、最終的な安定化/バグ修正中にリリースをビルドするときに、、 などbranches\1.0.1
で編集不可能なコピーを作成します。tags\1.0.1.5
tags\1.0.1.11
重要なのは、親ディレクトリがディレクトリであるかどうかを確認する簡単なスクリプトを作成しtags
、サブディレクトリが作成された直後に書き込みアクセスができないように再構成することです。そうしないと、タグがタグを移動することになり、静的タグ付けの目的が無効になります。
私はあなたが持っているものを単純化します。「DEV」はあなたのトランクであるべきです。プロジェクト レベルから開始する必要があります。各プロジェクトには、タグ、トランク、およびブランチのディレクトリが必要です。
projects/<project>
tags
trunk
branches
上記のように「Experimenal」や「Client-1」のようなものが必要な場合は、トランクに基づくブランチにする必要があります
projects/<project>/branches/experimental
projects/<project>/branches/client-1
同様に、タグは共通の場所に配置する必要があり、フォルダーを使用して整理できます。
projects/<project>/tags/experimental
projects/<project>/tags/client-1
これにはたくさんの理由があります
- ユーザーの予測可能性 ==> 誰かがどのモジュールにいても、あなたの svn 構造を予測できるはずです。
- フックの予測可能性 ==> タグを読み取り専用にするフックは、過度に複雑になるのを避けるために、予測可能な構造が本当に必要です。
- マージ ==> 「experimental」ブランチと「client-1」ブランチはトランクから分岐する必要があります。これにより、トランク機能をこれらのブランチに一貫してマージすることが容易になります。同様に、機能がトランクから分岐している限り、機能をマージすることもできます。
他にもたくさんあると思いますが、これらは私にすぐに飛び出すものです.