gitでは、ダースのライブラリのバージョニングを行う方法がすべて並行して動作しました
私たちはプロジェクトを行っていますが、プロジェクト間で多くのコードを再利用し、共通のコードを含むライブラリをたくさん持っています。新しいプロジェクトを実装するにつれて、一般的なコードを抽出してライブラリに追加する方法が増えています。ライブラリは互いに依存し、プロジェクトはライブラリに依存します。各プロジェクト、およびそのプロジェクトで使用されるすべてのライブラリは、参照しているすべてのライブラリの同じバージョンを使用する必要があります。ソフトウェアをリリースする場合、バグを修正する必要があり、長年、場合によっては数十年にわたって新しい機能を追加する必要があるかもしれません。約12のライブラリがあり、変更は多くの場合2つ以上にまたがり、複数のチームが複数のプロジェクトを並行して作業し、これらすべてのライブラリに同時に変更を加えます。 最近、gitに切り替えて、各ライブラリおよび各プロジェクトのリポジトリを設定しました。stashを共通のリポジトリとして使用し、機能ブランチで新しい作業を行い、プルリクエストを作成し、レビュー後にのみそれらをマージします。 プロジェクトで対処しなければならない問題の多くは、いくつかのライブラリとプロジェクト固有のコードを変更する必要があります。多くの場合、ライブラリインターフェイスの変更が含まれますが、その一部には互換性がありません。（これが怪しいと思うなら、私たちはハードウェアとインターフェイスし、特定のハードウェアを汎用インターフェイスの後ろに隠します。他のベンダーのハードウェアを統合するたびに、現在のインターフェイスが予期しなかったケースに遭遇するため、それらを改良する必要があります。）たとえば、プロジェクトを想像しP1たライブラリを使用してL1、L2とL3。L1また、使用していますL2とL3、とL2用途L3にも。依存関係グラフは次のようになります。 <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ ここで、このプロジェクトの機能に変更が必要でP1ありL3、のインターフェースを変更することを想像してくださいL3。これらのライブラリを参照するプロジェクトP2をP3ミックスに追加します。それらをすべて新しいインターフェイスに切り替え、すべてのテストを実行し、新しいソフトウェアを展開する余裕はありません。それでは、代替手段は何ですか？ 新しいインターフェースを実装する L3 プルリクエストをL3してレビューを待ちます 変更をマージする の新しいリリースを作成する L3 の新しいリリースをP1参照することで機能の作業を開始し、機能のブランチにL3機能を実装しますP1 プルリクエストを行い、これをレビューして、マージします （私はちょうど私がスイッチに忘れたことに気づいたL1とL2新しいリリースに。そしてそれはと並行して行われる必要があるので、私も、どこでこれを固執するかわかりませんP1...） これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。 しかし、あまり多くのオーバーヘッドなしで新しいプロジェクトに新しい機能を実装できるプロセスを作成するために、どのように分岐とタグ付けを使用するのでしょうか？