複数の開発者間でのトランク/ブランチとタグ構造の使用

Question

トランク/ブランチとタグになると、結局混乱してしまいます。以下は私の質問です。

私たちは単一のプロジェクトに取り組んでいる開発者のチームを抱えています。開発者はグループに分かれて、同じプロジェクトのさまざまなモジュールに取り組むことがよくあります。

現在、私たちは単純な SVN システム (トランク、ブランチ、またはタグのない) を持っており、全員が同じローカル サーバー上で作業し、ファイルをコミットします。しかし問題は、数人の開発者が将来のモジュール (すぐに公開される予定ではない) に取り組んでいるときに始まります。この状況では、データをコミットすることはできません。コミットすると、開発コードがライブサーバーにアップロードされ、最終的にすべてが台無しになってしまうためです。

そこで私は現在、これらの開発者が別々に、しかし同じコードで作業できる、ある種のソリューションを探しています。このようなもの：

開発者Aは新しいモジュールに取り組んでいますA A開発者Bは新しいモジュールBで作業しています。開発者CはモジュールCのバグ修正に取り組んでいます（すでにライブ中ですが、修正する必要があるバグはほとんど必要ありません）

したがって、開発者 A はこのマシン上に独自のコピーを持ち、開発者 A のリポジトリにコミットします。(または支店)

同じロジックが開発者 B にも当てはまりますが、開発者 C はタグ内のどこかにある共通の安定したコピーで作業し、作業が完了するとタグ付けされてトランクにプッシュされ、ライブ サーバーにアップロードされます。

開発者 A は作業が完了したら、ライブ アップロードのためにすべてのファイルをトランクにプッシュします。(これにより、トランク内のいくつかの共通ファイルもマージされるはずです)。同じロジックが開発者 B にも当てはまります。

SVN がこれに対する適切なソリューションであるかどうかはわかりません。私が望むものを実装するより簡単な方法があるかどうかさえわかりません。

あらゆる種類の提案を歓迎します。

TTRに感謝します

Answer 1

まず私の意見は、開発者全員がプロジェクトの別々の部分に取り組んでいるのであれば、ブランチをなくしてもよいということです。少し整理する必要があるかもしれません (適切なログのコメントやバージョン管理など) が、分岐やマージよりもはるかに手間がかかりません。

わかりましたが、ブランチが必要な場合は、簡単です。これにはいくつかのアプローチがありますが、基本的にはすべて、最終コードが最終的に完成する「マスター」バージョンを必要とします。これはトランクにすることもできますが、トランクに変更を加えてからコードをマージしてブランチを解放することを好む人もいます。ただし、「トランクはマスター」という概念は最も理解しやすいものです。

svn では、ブランチを作成するのは簡単です。それは安価なコピーなので、唯一の問題はディレクトリを内容で埋めることです (ブランチを作成し終わったら、ブランチを削除することをお勧めします)。SVN は、このタイプの作業用に特別な種類のブランチも提供します。 社会復帰ブランチ. 。SVN はそれに何が起こったかを追跡するため、特別です。トランクからブランチを作成し、そのブランチで作業し、時々トランクに加えられた変更でブランチを更新し、その後そのブランチでのすべての作業を 1 つのトランクに再統合するように設計されています。最後の強打。その後、最初からやり直すことができます。これはあなたが望んでいることのように思えますが、通常は開発者ごとにブランチを持つのではなく、作業のパッケージごとにブランチを持つことになります。

開発ごとのブランチの問題は、ブランチの存続期間が長くなるほど、ブランチが行った変更をマージして戻すのがますます困難になることです。これは、開発者が定期的に他の開発者の作業を自分のブランチにマージしない場合に特に当てはまります (通常のように)。

svn は安価なコピーを行うため、開発者ごとにトランク全体を分岐することをお勧めします。個別のディレクトリをブランチするよりも、その方が覚えやすいと思います。また、共有ファイルや共通ファイルをコミットすると別のブランチが中断されるかどうかを心配することなく、いつでも変更できるようになります。(つまり、/trunk/moduleA を分岐し、後で /trunk/include/common_file を変更する必要があることが判明した場合、サブセットを分岐したため、共通ファイルはブランチ内に存在しません。したがって、追加の費用はかからないので、ルートで分岐するだけです)

Answer 2

あなたの質問では、トランク/タグ/ブランチモデル全体の背後にある基本的な理由を表明したばかりです。これは、まさにこの状況を管理するためです。これは、開発ショップがしばらくする通常の状況です。

計画することの1つは、トランクレスモデルからトランクモデルへの移行です。

トランク、タグ、ブランチなどがないと言うので、あなたのモデルは次のように見えると思います。

/
 filea.html
 fileb.html
 dira/
  filex

警告の言葉 - ルートディレクトリ自体を分岐しようとしないでください.

例えば：

svn cp / /branchA

これにより、次のように見えるディレクトリが得られます。

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

ルートブランチの一部とサブブランチの一部は、かなり迅速に扱いやすくなります。

きれいに保ちます - すべてのコードを最初にトランクに移動します。これは、ワークスペースを削除してクリーンからすべてを取得するために、すべての人（およびすべての展開システム）を必要とする一種の構造ジャンプです。

svn cp / /trunk

今 あなたはあなたの枝を作ることができます：

svn cp /trunk /branches/branchA

次のような構造を提供します：

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

枝が作られたら、開発者はそれらをチェックアウトして作業することができます。展開システムは、ルートフォルダーの代わりにトランク/を指すことができ、それを展開できます。

バグフィックスで作業する開発者は、トランクをチェックアウトできます。彼らがコミットすると、展開システムは今と同じように変更を展開します。

Branchaが終了すると、Gbjbaanbが示唆するように、開発者は変化をトランクにマージできます。

ちょっとした頭を上げて、それで頑張ってください。