2

ここに画像の説明を入力

わかりやすいように、写真に凡例を追加しました。

最初、私のプロジェクトのトランク内のコードはバージョン 1.0 です。

このバージョンのコードで、ベンダー A、ベンダー B、1.1、および 1.2 の 4 つのブランチを作成します。赤い線は、これらの並行開発ブランチを表しています。ベンダー固有の開発とリリースはベンダー ブランチで実行され、ベンダー ブランチのコードがトランクにマージされることはありません。ベンダーに対してリリースが行われると、それらのリリースにタグが付けられます。

さて、私の質問は次のとおりです。

  1. この製品開発の方法論はどの程度正確ですか?
  2. たとえば、トランクは 1.1 にあり、1.1 コードをトランクにマージした後、1.1 ブランチが終了 (期限切れ) します。その後、1.1 コードにバグが見つかりました。ここで、すぐにバグ修正ブランチを作成し、修正をトランクにコミットします。では、このバグ修正は 1.2 ブランチとベンダー ブランチにプッシュする必要がありますか? それとも、これらのブランチは別のバージョンのトランク (1.0) を扱っているため、プッシュすべきではありませんか?
  3. ベンダー ブランチで開発に取り組むにはどうすればよいですか? たとえば、ベンダー ブランチのバグを修正する必要がある場合、変更を直接ベンダー ブランチにコミットする必要がありますか?

プロセスの再構築/再設計についてもご提案いただければ幸いです。

4

1 に答える 1

1

私には問題ないようです。ただし、少し単純化します-ベンダーブランチがトランクから定期的に更新されると考えるのが正しければ、バグ修正ブランチから明示的なマージを行う必要はありません-バグ修正（1.1バグ修正など）をトランクにマージするだけです、トランクからすべてのベンダー ブランチへのマージを実行します。

トランクからベンダーにマージする際の秘訣は、何が既にマージされているかを正確に追跡することです。理想的には、すべてをマージし、時系列順にブロックで実行します。（チケット/機能番号でコミットをマークすると便利だと思いsvn logます。そのため、特定の時点で何をマージする必要があるかがわかります。これにより、機能の半分を別のブランチに送信しないことが保証されます。

マージをコミットするとき、マージ文字列 (例: "(merge -r1234:2345 -r2667:3123 ../../trunk)") をマージの説明と共に追加します。ログ (ベンダー ブランチなど) を使用して、マージされていない最も古いトランク リビジョンを検出します。

ただし、別のブランチで 1.0 と 1.1 を維持する傾向もあります。したがって、1.1 ブランチがマージされると 1.0 トランクが 1.1 になる場合、その直前にトランクからブランチ 1.0 のコピーを取得することが適切な場合があります。最初にバグ修正はトランク (1.1) に対して行われ、次に 1.1 ブランチから派生したベンダーに直接マージされます。ただし、1.0 から派生したベンダーには完全に適用されない (または関連しない) 場合があります。この場合、最初に 1.0 ブランチに適用し、そこから以前のバージョンのすべてのベンダーにマージします。

もちろん、1.0 のみに関連し、1.1 には存在しない、または関連しないバグが見つかる可能性もあります。そのため、この別のブランチも役立ちます。

したがって、このアプローチを念頭に置いて、維持する必要がある同時バージョンの数を最小限に抑えるために、可能な場合は各ベンダーを非常に古いバージョンからアップグレードすることをお勧めします。当然のこととして、または新しいライセンス/契約の一部としてそれを行うかどうかは、あなたのビジネスの問題です.

于 2012-08-14T09:17:10.953 に答える