ソース管理とバグ修正のベストプラクティス

Question

コミットされた現在の開発、または現在のバージョンからの変更を含まないバグパッチを発行する必要がある場合、プロセスをより安全でオーバーヘッドを少なくするために何をすべきですか？

現在、主にVisual Studio 2008で開発している小規模（3人の開発者）チームのソース管理にSubversionを使用しています。チームは来年に8人の開発者にグループ化し、以前のリリースサポートはより複雑。ほとんどのお客様は現在のリリースを使用していますが、一部のお客様はさらに遅れています。

Answer 1

ソース管理はこれを非常に簡単に処理でき、このために設計されました。

リリースの安定化期間に達したら、ブランチを実行する必要があります。これが行われる前に、次のリリースで作業を開始しないことが重要です。

そのリリースでは、そのブランチでバグ修正を行う必要があります。これにより、今後のリリースの新しいコードがバグ修正を汚染するのを防ぎます。バグ修正が完了したら、その変更をトランクにマージし、必要に応じて他のリリースにマージできます。

コメントにバグ番号を入れることを忘れないでください。これにより、コミットの追跡が容易になります。

Answer 2

方法：メジャーバージョンごとのブランチ、必要に応じてブランチにバグ修正を適用し、トランクに適用（またはマージ）します。

Answer 3

私が働いているところでは、いくつかのプロジェクトが同時に働いています。この問題を回避するために、ソースコードのいくつかのバリアントがあります。たとえば、最初のリリースはVariant 1.0です。将来のすべての開発のために、Variant 2.0など、このリリースから分岐を作成します。バグ修正を行う必要がある場合は、現在1.0であり、リリースできるメインのVariantで修正します。 Variant 2.0の運用準備が整ったら、メインブランチ（この場合は1.1）にあるものとマージし、それが新しいメイントランクになります。ある時点で、4つのブランチが同時に実行されていました。

コードのマージには時間がかかる可能性があり、マージ中に新しいバグを導入しないように注意する必要がありますが、適切なコード比較ツールを使用できる場合、それはそれほど悪くないはずです。 10,000個のファイルソースディレクトリでBeyond Compareを使用してしばらく前にマージを行いましたが、1朝かかりました。