バージョン 1.1 とバージョン 2.0 を同時に作業するにはどうすればよいですか?

Question

状況：ベータ版は終了し、バージョン 1.0 がいくつかの顧客サイトにリリースされました。チーム A はすでに、段階的なバグ修正とユーザビリティの調整を含むバージョン 1.1 の作業に忙しくしていますが、別のチームは大規模な変更を加えたバージョン 2.0 に取り組んでおり、製品のコアが完全に再設計されている可能性があります。現在、1.1 に対して行われた変更のほとんどは、ある時点で 2.0 に反映される必要があり、2.0 ブランチで行われたバグ修正の一部は、実際には以前のリリースでスケジュールする必要がある可能性があります。問題は、2.0 には根本的な違いがあるため、1.1 からの変更を手動で変換せずにマージすることはできず、またその逆も同様であることです。

私の質問：このような状況でマージ競合や重複作業を最小限に抑えるためのベストなリビジョン管理方法は何でしょうか?顧客に定期的にパッチを提供しながら、チームがリビジョン管理の問題に費やす時間と労力をできるだけ少なくするにはどうすればよいでしょうか?

Answer 1

良い方法の 1 つは、安定版ブランチ内の各バグを修正し、安定版ブランチを開発ブランチにマージすることです。これは 並行保守/開発ライン 重要なのは、早期かつ頻繁にマージすることです。マージの頻度が低く、遅いということは、開発ブランチが安定版と比べて認識できないか、同じ方法でバグを再現できないことを意味します。

転覆 バージョン 1.5 以降はマージ追跡が含まれているため、同じ変更セットが 2 回マージされて愚かな競合が発生することがなくなります。他のシステムも存在します (例: ギット, マーキュリアル, アキュレブ, パーフォース）このタイプのクエリを作成できます。「ブランチAの変更は、ブランチBに統合されていませんか？」そして、あなたが必要な修正をDev Branchにチェリーピックします。

Answer 2

記事 ここ (Subversion の日常) では、1 つの方法として、バージョン 1.1 ビルドのデータを使用してバージョン 2 を継続的に更新することが挙げられています。記事の中で、男性はこれを毎日行うようにと言っています。

読んでいただきたい部分は、「ウェイター、私のトランクに虫が入っています!」というタイトルです。記事の半分くらいです。

Answer 3

この目的のためにはおそらく問題追跡システムを利用し、トランク コードに反映する必要がある各変更を必ずタグ付けすることになるでしょう。これにより、各変更のチェックイン コメントが関連する問題を参照し、コード変更の意図を明確に表現できるようになり、トランクに再実装するときに容易に理解できるようになります。

Answer 4

他の人が言っていることとほぼ同じですが、SVN を使用して複数のブランチで開発を処理した経験を活かしてみようと思いました。

当社の主力製品では、2 つ以上のバージョンを同時に開発する必要があります。

私は当初、メイン トランクを「メイン開発」バージョンとして使用し、実際のリリースごとにタグを使用しました。ブランチは、新しい機能セットの大幅な開発作業に使用されました。その後、一度に 2 つ、3 つ、4 つのリリースに取り組み始めたとき、リビジョンごとにブランチを使用し始めました。

私はリポジトリを保守し、QA ビルドのプッシュも処理するため、毎朝必ず「ロールアップ」を実行します。これは、現在アクティブな最下位のブランチから開始してツリー上の変更をマージすることで構成されます。したがって、最終的に 1.1 からの変更を 1.2 にマージし、それが最後のマージ以降の 1.2 からの他の変更とともに 1.3 にマージされます。

コミットするときは、必ずコミットに次のようなコメントを付けるようにしています。

マージ 1.1 リビジョン 5656-5690

少し面倒かもしれませんが、うまくいきます:)

Answer 5

早期にマージし、頻繁にマージし、メインラインの QA がメンテナンス リリースの各パッチで修正された欠陥を認識し、回帰/検証するようにしてください。

何かを見逃して、次のリリースでバグを「修正」するのは非常に簡単です。言っておきますが、複数のブランチの管理がどれほど複雑になるかは顧客は気にしていません。それがあなたの仕事です。

分岐とマージをサポートするソース管理システムを使用していることを確認してください (私は Perforce と SVN を使用した経験があり、Perforce の方が優れていますが、SVN は無料です)。

また、一貫した方法でマージを実行する責任を負う担当者を 1 名にすることで、マージを定期的に実行できるようになると考えています。たいていそれは私かチームの先輩の一人でした。

Answer 6

私の職場でこれに対処する方法は、トランク ブランチを最先端のコード (つまり、この場合は 2.0) として保持することです。1.x コードのブランチを作成し、そこにすべての修正を加えます。1.x への変更はすべて (必要に応じて手動で) トランク (2.0) ブランチにマージする必要があります。

そこで私は、1.x 開発者には、1.x コミットのリビジョン番号と 2.0 マージのリビジョン番号の両方をそのバグのチケットに記録するよう強く求めます。そうすれば、誰かが変更をマージするのを忘れた場合に気づきやすくなり、それを追跡しなければならないという事実が覚えやすくなります。

Answer 7

重要なポイントの 1 つが捉えられています この絵 ビルドドクターより:一方向のみをマージします。

Answer 8

その特定の質問に答えるために、多くの開発者が Subversion から Git に切り替えました。github.com をチェックアウトしてください。