製品のバージョン管理と長期プロジェクトの分岐を処理する最良の方法は何ですか？
一般的な意味で、製品のライフサイクル中に複数のリリースがあり、以前の製品のサポートを必要とする長期的なプロジェクトの場合、製品のバージョンとコードベースの分岐を処理する最良の方法は何ですか？
より具体的な意味では、適切な分散バージョン管理（gitなど）が実施されており、チームの規模は小さいものから大きいものであり、開発者は一度に複数のプロジェクトで作業している可能性があると想定しています。直面している主な問題は、当時存在していた古いバージョンをサポートする契約上の義務があることです。これは、新しい開発では古いコードにパッチを適用できないことを意味します（Microsoft Office製品はこの例である可能性があり、所有する機能の年）。
その結果、各主要製品には複数の依存関係があり、それぞれに年次リリース間で変更される独自のバージョンがあるため、現在の製品のバージョン管理は少し複雑です。同様に、各製品には独自のリポジトリがありますが、ほとんどの作業はメインソーストランクではなく、その年の製品リリースのブランチで行われます。製品がリリースされると、サポートされるように新しいブランチが作成されます。つまり、バージョン管理を使用するときに考えられるように、製品のコードベースを取得することは簡単なことではありません。
どのくらいの（そしてどのような種類の）構造が必要かは、何をしたいかに大きく依存します。なくてはならないもの、持ちたいもの、気にしないものを見つけましょう。
決定の良い例のセットは次のようになります。
これなしでは生きていけないもの：
- 過去のリリースをいつでも再構築できる
- サポートされている製品の複数のメジャーバージョンをいつでも維持できる
欲しいもの：
- ブランチのマージを心配せずに、（次のメジャーリリースの）進行中のメジャー機能開発を実行できる
- 過去のリリースのメンテナンスアップデートを実行できる
私たちがなくても生活できるもの：
- 現在の作業から過去のリリースへの変更の自動バックポート
- 一度に数日または1週間でも主要な機能の開発を中断しない
上記があなたの目標であれば、次のようなプロセスを採用できます。
- VCSのトランクですべての開発作業を行う（gitの「マスター」）
- メジャーリリースに近づいたら、主要な機能の開発を中止し、システムの安定性に1週間ほど集中する
- トランクが安定しているように見えたら、このメジャーリリースのブランチを作成します
- ブランチではバグ修正とリリース準備のみが許可されていますが、主要な機能開発はトランクで続行できます。
- ただし、ブランチに対して行われるすべてのバグ修正は、まずトランクでテストする必要があります。これにより、将来のすべてのリリースにも存在することが保証されます
- リリースする準備ができたら、ブランチに（VCS）タグを作成します。このタグは、同じブランチでさらに作業を行った後でも、いつでもリリースを再作成するために使用できます
- このメジャーリリース（マイナーリリース）の追加のメンテナンスリリースをブランチで準備できるようになりました。リリース前にそれぞれにタグが付けられます
- それまでの間、次のメジャーリリースに向けた主要な機能開発はトランクで続行できます
- そのリリースに近づいたら、上記の手順を繰り返し、そのリリースの新しいリリースブランチを作成します。これにより、複数のメジャーリリースをそれぞれ独自のブランチで同時にサポートされた状態にして、それぞれに対して個別のマイナーリリースをリリースすることができます。
このプロセスはすべての質問に答えるわけではありません。特に、リリースブランチにどのような修正を加えることができるかを決定し、バグがリリースブランチで最初に修正されないようにするための適切なプロセスが必要です（そのような修正など）。可能な場合は常にトランクでテストする必要があります）。しかし、それはあなたにそのような決定をするためのフレームワークを提供します。
「長期」は、あなたが必要バージョン管理であることを示す指標ですが、特定のバージョン管理および分岐戦略を意味するものではありません。さらに興味深い質問は、サポートする製品ラインまたはメジャーバージョンラインの数です（これは、顧客との契約によって異なります）。保守契約を結んでいる製品ライン/メジャーバージョンラインごとに、少なくとも1つのブランチが必要です。
一方、それはあなたのチームの規模に依存します。大きな開発チームがいて、さまざまな人がさまざまな機能に並行して取り組んでいる場合、1人または2人のチームの場合よりも、より多くの機能ブランチが明らかに必要になります。より大きなチームで作業している場合は、分散バージョン管理を使用することを検討してください。これにより、異なるブランチでの並行作業（および後でトランクに再統合すること）がはるかに効率的になります。
Gitはバージョン管理ツールです。ファイルのバージョンを管理します。あなたが求めているのは、構成管理ツールです。これらは利用可能ですが、大部分はIBMなどからの高額の$$$です。
バージョン管理ツールは、分岐とタグ付けを提供します。これにより、追加のツールサポートなしで無作法な構成管理が可能になるため、開発者は違いを理解できません。あなたのニーズは、おそらくGITが行うように設計されているものを超えています。
私は気づいていませんが、Git用のCMツール追加が存在することは確かです。
この質問は、私が最近回答した 別の質問 に非常に似ているようです 最近 。
つまり、バージョン管理や分岐の問題というよりは、製品の設計と配布の問題のように聞こえます。もちろん、私がそれを言うのは簡単であり、あなたがすでに問題の深いところにいる場合、あなたが修正するのはより困難です。
特定の問題の詳細を詳細に知らなくても。ただし、一般に、製品間で大量の共有コードを持つコードベースに基づく製品の複数のバージョンがある場合、可能であれば、製品をよりモジュール化するような方法で製品をリファクタリングし、モジュール自体がコードの追加の分岐を必要としないことを確認してください。また、コードベースの多くを統一したまま、顧客をサポートするためのより良い手段があるかどうかを確認するために、展開モデルも調べます。特定の顧客のカスタマイズが必要な場合は、システム内の重複するコードの量を減らすために、モジュールをさらに細かくする必要がある場合があります。
これは簡単な作業ではありませんが、ジョブを適切に管理し、すべてを一度に「アップグレード」する必要がないように作業をスケジュールできる場合は、段階的に修正できます。