3

私の開発チームはまもなく分岐に移行します。SourceSafe に悩まされていた私たちは、Team Foundation Server に移行しています。何か気になることがあります。

従来、製品の大幅な改訂を行って、フォルダー構造やファイル名さえも同じままにしない場合、ソース管理で新しいルート フォルダーを作成します。

例えば

$/V1.0
$/V1.1
$/V1.5
$/V2.0

など。

私は分岐についてはまったくの初心者であり、私が読んでいることの 1 つは、製品のさまざまなバージョンに異なる分岐を使用できるということです。さて、ホットフィックスやコードの小さな変更または修正について話しているとき、最悪の場合、新しいファイルを追加する可能性がある場合、これは理にかなっています。

ただし、製品の「V-Next」バージョンを実行する場合、製品を多かれ少なかれ完全に書き直すことを計画している場合 (ゼロからではなく、大幅に作り直す)、フォルダ構造とファイルが名前は完全に異なる可能性がありますが、それでも分岐によってやりたいことはありますか? または、それを処理するために新しいルート (上記の $/V2.0) を作成しますか?

4

6 に答える 6

4

私たちの開発チームは、Subversion で非常に標準的な分岐構造を使用しています。メイン リポジトリには 3 つのフォルダがあります。

  • 枝
  • タグ
  • トランク

あなたの例では、すべての V* フォルダーがタグの下に配置されます。主な開発はすべてトランクで行われ、別のプロジェクトのためにトランクにあるものにバリエーションが必要な場合はブランチを使用します。

また、ブランチを使用して、トランクへの大幅な変更を保存します。これは、書き換えが完了する前にトランクのバグを修正する必要がある場合に適しています。そのため、ブランチの下に「V-Next」ブランチを作成し、それが完了したら、そのブランチをトランクにマージします。

于 2009-02-02T15:51:09.163 に答える
1

私は TFS の専門家ではありませんが、ブランチとタグについて「強い」意見を持っています。

VCS のブランチは、現在のものと互換性のない開発作業を分離するために予約する必要があります。

つまり、現在作業している環境 (ブランチの有無に関係なく) に関係なく、言及した抜本的なリファクタリングを開始しながら現在の開発を続行できない場合は、ブランチが必要です。
そのブランチでは、ファイルの履歴はまだ記録されている間に新しいパスを取ることができます

秘訣は、特に両方がディレクトリとして表されている場合は、ブランチのタグを解釈しないことです。

V2.0次の両方として解釈できます。

  • ファイルの履歴を固定して不変にするタグ
  • 2.0リリースまでの歴史が進化するブランチ

ディレクトリの背後にある意図を明確にする命名規則をお勧め
V2.0_Refactoringします。たとえば、より明確でブランチを示します。

于 2009-02-02T16:00:56.427 に答える
0

ベストプラクティスに関するいくつかの記事をご覧になることをお勧めします。

あなたの場合、私はあなたのV-nextをホストするためのブランチを作成しません。パッケージングブランチを作成して顧客に提供する準備ができた場合にのみ、そのブランチを作成する必要があります。

リスクのある開発をホストするために、いくつかの短期ブランチ（スクラムの反復ごとに1つ）を作成し、各反復の最後にそれらをマージします。あなたが話している激しいリファクタリングなどの危険な開発のためにのみ開発ブランチを作成してください。

メインブランチは常に安定している必要があります。顧客に配達する準備ができているか、少なくともパッケージングブランチに分岐する準備ができています。

SCMパターンもお勧めします。

于 2009-02-02T16:38:27.477 に答える
0

分岐は履歴をまとめて保持し、プロジェクトの完全な起源を確認できるようにします。また、リリースされたバージョンの修正を「次の」バージョンにマージすることもできます (製品と混乱の状態によって異なります)。

于 2009-02-02T15:53:56.130 に答える
0

これを読んでください：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

于 2009-04-15T23:44:10.383 に答える
0

私の経験で最も効果的な分岐戦略は、単一の「メインライン」トランクを持ち、そこからメジャー バージョンごとに分岐し、必要に応じてそれらのそれぞれから小さなリリースに分岐することです。ほとんどの作業はメインラインで行われ、リリースがかなり近づくと分岐してブランチを安定させます。

任意の小さな変更セット/リリースに分岐することはできますが、最終的には認知オーバーヘッドが大きくなりすぎて価値がなくなります。変更がマージされる準備が整うまで、進行中の大きな作業をメイン ブランチから分離するために、さらに一時的なブランチを作成することもできます。

これらすべてを踏まえると、リリースの最初に「最初からやり直す」ことにはあまり価値がないと思います。リリースの終わりまでにすべてが変更される場合でも、時間の経過とともに物事がどのように進化したかの完全な履歴が必要です。私は、TFS が移動/名前変更/削除などを追跡していると推測しているので、ファイル レベルの変更をたくさん行っている場合でも、それは貴重な履歴です。

于 2009-02-02T16:07:09.067 に答える