当社のソフトウェア製品ラインでは、複数のソフトウェア バージョンを同時に開発および維持する必要があります。私たちは比較的 Git の初心者であり、最近、 Driessen の分岐モデルを利用するために Git Flow を採用しました。私たちのソフトウェア チームは非常に小規模で、熱心な開発者はほとんどおらず (全員がさまざまな帽子をかぶっています)、「統合の第一人者」もいません。
Git と Git Flow を私たちのニーズに適応させる方法について、多くの検索を行った結果、具体的なアドバイスはほとんど見つかりませんでした。明らかになったのは、Git Flow は複数のバージョンを同時にサポートするのに適していないということです。SO に関する1 つの関連する議論には、個別のバージョンの履歴を追跡するために個別のブランチ名を使用する必要があることを示す回答があります。これと関連する戦略により、変更されない限り Git Flow は削除されます。これが私たちにとって実用的でない理由については、上記のチームの制限を参照してください。
重要な問題は、複数のリリース ラインをサポートしながら Driessen の分岐モデルをできるだけ厳密に実装するための優れたアプローチであると他の人が見つけた方法は何ですか?
更新:
以下の回答 (特に @Rasmus ') を、よりターゲットを絞った検索といくつかのオプションに関する内部ディスカッションで抽出すると、私たちが実装している次のソリューションにつながります。
Git Flow は今後も使用しません。代わりに、各ブランチ名の前に意図したリリース文字列を付けることで、Driessen のモデルをレポ内の個々のリリース ラインに適用します。
r1.5/develop
プロジェクトのすべてのバージョンは、Git リポジトリに含まれています。新しいプロジェクト バージョンを開始するには、リリース文字列を前に付けた新しい長命のブランチの小さなセットを作成する必要があります (たとえばr1.6/develop、私たちの場合はr1.6/release; nomasterで、現在の単一の良好なビルド可能状態を意味します)。
remoteローカル リポジトリリンクを介してコードを共有するための主要な手段となるサーバー上に、プロジェクトごとに 1 つの中央パブリック リポジトリを確立します。このリポジトリへのプッシュは、他のユーザーが使用する準備ができているコードを意味します。ブランチにマージRX.Y/developしてからプッシュするRX.Y/releaseことは、リリースを意図したコードを意味します。 feature、、、hotfixなど。アル。ブランチも同様に処理されます。特定のリリース ラインのブランチ マージ/コミット履歴は、クリーンでわかりやすいものです。時間の経過とともに構造が分岐する可能性があるようなリポジトリをマージする複雑さを回避するために、典型的な Git 分散リポジトリ戦略は必要ありません。
一部の Git GUI (たとえば SourceTree など) では、このブランチ構造が認識されて階層として表示されるため、ブランチ構造からプロジェクトの最上位の履歴を理解するのに役立ちます。
回答に賛成票を投じなかったことをお詫びします。SOでの私の評判は、そうするために必要な最低限のものではありません。