状況: ベータ版が終了し、バージョン 1.0 がいくつかの顧客サイトにリリースされました。チーム A は、段階的なバグ修正と使いやすさの微調整を行うバージョン 1.1 の作業にすでに忙しく、別のチームは、製品のコアが完全に再設計されている可能性がある大規模な変更を伴うバージョン 2.0 に取り組んでいます。現在、1.1 に加えられた変更のほとんどは、ある時点で 2.0 に移行する必要があり、2.0 ブランチで行われたバグ修正の一部は、実際には以前のリリースにスケジュールする必要がある場合があります。問題は、2.0 には基本的な違いがあるため、1.1 からの変更を手動で変換しないとマージできないことです。また、その逆も同様です。
私の質問: この種の状況でマージの競合と作業の重複を最小限に抑えるための最良のリビジョン管理プラクティスは何ですか? チームがリビジョン管理の問題に費やす時間と労力をできるだけ少なくしながら、顧客に定期的なパッチを提供するにはどうすればよいですか?
良い方法の 1 つは、安定版ブランチの各バグを修正し、安定版ブランチを開発版ブランチにマージすることです。これが並行メンテナンス/開発ラインパターンであり、重要なのは早期かつ頻繁にマージすることです。マージが頻繁に行われず、遅いということは、開発ブランチが安定ブランチと比較して認識できないこと、または同じようにバグを繰り返すことができないことを意味します。
Subversionにはバージョン 1.5 以降のマージ トラッキングが含まれているため、同じ変更セットが 2 回マージされてばかげた競合が発生しないようにします。他のシステムが存在し (例: Git、Mercurial、Accurev、Perforce )、「ブランチ A のどの変更がブランチ B にマージされていないか?」というタイプのクエリを作成できます。そして必要な修正を dev ブランチにチェリーピックします。
ここの記事(Subversion の日々) では、1 つの方法として、バージョン 1.1 ビルドのデータでバージョン 2 を常に更新することが挙げられています。記事では、男はこれを毎日行うように言っています。
あなたが読みたい部分は、「ウェイター、私のトランクにバグがあります!」というタイトルです。記事の半分くらいです。
おそらく、この目的のために問題追跡システムに依存し、トランク コードに転送する必要がある各変更にタグを付けるようにします。次に、各変更のチェックイン コメントが関連する問題を参照していることを確認し、コード変更の意図を明確に表現して、トランクに再実装しようとするときに簡単に理解できるようにします。
他の人が言っていることとほとんど同じですが、SVN を使用して複数のブランチで開発を処理した経験を投げかけたいと思いました。
当社の主力製品では、2 つ以上のバージョンを同時に開発する必要があります。
私は当初、実際のリリースごとにタグを使用して、メイン トランクを「メイン開発」バージョンとして使用していました。ブランチは、新しい機能セットの実質的な開発作業に使用されました。その後、一度に 2、3、4 のリリースに取り組み始めたとき、各リビジョンにブランチを使用し始めました。
私はリポジトリを維持し、QA ビルドのプッシュも処理するので、毎朝「ロールアップ」を行うようにしています。これは、現在アクティブなブランチの最下位から開始してツリーの上方に変更をマージすることで構成されます。そのため、1.1 から 1.2 への変更をマージすることになり、最後のマージ以降の 1.2 からの他の変更とともに 1.3 にマージされます。
コミットするときは、常に次のようなコメントでコミットをコメントするようにします
マージされた 1.1 リビジョン 5656-5690
少し面倒かもしれませんが、うまくいきます:)
その特定の質問に答えるために、多くの開発者がSubversionからGitに切り替えました。github.comをチェックアウトします。
早期にマージし、頻繁にマージし、メインラインの QA がメンテナンス リリースの各パッチで修正された欠陥を認識し、後退/検証するようにします。
何かが抜け落ちて、次のリリースでバグを「修正しない」のは非常に簡単です。言っておきますが、顧客は、複数のブランチを管理することがどれほど複雑になるかなど気にしません。それがあなたの仕事です。
分岐とマージをサポートするソース管理システムを使用していることを確認してください (私は Perforce と SVN の経験があり、Perforce の方が優れていますが、SVN は無料です)。
また、一貫した方法でマージを実行する責任者が 1 人いることで、マージが定期的に行われるようになると考えています。それは通常、私か、私たちのチームの上級者の 1 人でした。
私の仕事でこれを処理する方法は、trunk ブランチを最新のコード (つまり、この場合は 2.0) として維持することです。1.x コードのブランチを作成し、そこですべての修正を行います。1.x に対するすべての変更は、(必要に応じて手動で) トランク (2.0) ブランチにマージする必要があります。
次に、1.x の開発者は、1.x コミットのリビジョン番号と 2.0 マージのリビジョン番号の両方を、そのバグのチケットに書き留めるように要求します。そうすれば、誰かが変更をマージするのを忘れた場合に簡単に気付くことができ、それを追跡しなければならないという事実が覚えやすくなります。
The Build Doctor のこの写真には、重要なポイントが1 つあります。それは、一方向のみをマージすることです。