git non-gurus向けの、複数のリリースラインとgit-flowに関するアドバイス
当社のソフトウェア製品ラインでは、複数のソフトウェアバージョンを同時に開発および保守する必要があります。私たちは比較的Gitの初心者で、最近Git Flowを採用して Driessenの分岐モデル を利用しています。私たちには非常に小さなソフトウェアチームがあり、専任の開発者はほとんどいません（全員が多くの帽子をかぶっています）。「統合の第一人者」もいません。
多くの検索で、GitとGit Flowを私たちのニーズに適応させる方法に関する具体的なアドバイスはほとんどありませんでした。判明したことは、Git Flowは複数のバージョンを同時にサポートするのにはあまり適していないということです。 1つ SOに関する関連ディスカッション には、個別のバージョンの履歴を追跡するために個別のブランチ名を使用する必要があることを示す回答があります。これと関連する戦略により、Git Flowが変更されない限り排除されます。これが私たちにとって実用的でない理由については、上記のチームの制限を参照してください。
重要な質問は、複数のリリースラインをサポートしながら、Driessenの分岐モデルを可能な限り厳密に実装するための優れたアプローチであると他者が考えていることは何ですか？
更新：
以下の回答（特に@Rasmus '）を絞り込んで、いくつかのオプションを対象とした検索と内部のディスカッションを行うと、実装している次のソリューションにつながります。これは、同様の条件下で同様のチームに関連する可能性があるアプローチの1つとして提供しています。
Git Flowは今後も使用しません。代わりに、各ブランチ名の前に目的のリリース文字列を付けることで、リポジトリの個々のリリースラインにDriessenのモデルを適用します。例：
r1.5/develop
プロジェクトのすべてのバージョンは、Gitリポジトリに含まれています。新しいプロジェクトバージョンを開始するには、リリース文字列が前に付いた新しい長命ブランチの小さなセットを作成します（例：r1.6/develop、および私たちの場合、r1.6/release; masterは、現在の単一の適切なビルド可能な状態を意味します）。
ローカルリポジトリremoteリンクを介してコードを共有するための主要な手段となるサーバー上のプロジェクトごとに1つの中央パブリックリポジトリを確立します。このリポジトリへのプッシュは、他の人が利用する準備ができているコードを示します。マージRX.Y/developに入れてから、RX.Y/releaseブランチは、リリース用のコードを示します。 feature、hotfixなどal。ブランチも同様に処理されます。特定のリリースラインのブランチのマージ/コミット履歴は、クリーンで理解しやすいものです。時間の経過とともに構造が異なる可能性が高いリポジトリをマージする複雑さを回避するために、典型的なGit分散リポジトリ戦略を望んでいません。
一部のGit GUI（たとえば、SourceTreeなど）では、このブランチ構造が認識され、階層として表示されるため、ブランチ構造からプロジェクトのトップレベルの履歴を理解するのに役立ちます。
回答に賛成票を投じないことをお詫びします。 SOに対する私の評判は、そうするために最低限必要なものではありません。
300人を超える専任の開発者がいることを除いて、同様のセットアップを行っています。さまざまなお客様に提供する必要があるいくつかの改訂について、お客様が説明したとおりです。
分割して、refs/heads/platformX.Y /のような最初の参照ができたら、それを基に構築します
したがって、何をする必要があるかに応じて、platformX.Y/developをチェックアウトし、その時点から機能ブランチで作業を開始し、完了したらマージして開発します。
これは私たちにとってはうまくいき、nvieモデルに従うことができます。
これらすべてのプラットフォームX.Yブランチをメインの開発ブランチにマージしているため、これらのブランチで修正されたエラーは最新のソフトウェアにもリリースされます。
通常の開発プロセスはDriessenのフローワークフローによく適合しますが、進行中の開発の大部分を含めたくない特別なリリースのために、いくつかの機能を備えたブランチを開発する必要がある場合があります。既存のツールを使用して、フロー内でこれを行う方法を見つけました。追加のステップが2つだけあります。 （私たちはMercurialで作業していますが、git flowとhg flowのオプションは同じです。）
たとえば、次の通常のリリースは23.0であり、特別な「サンドボックス」リリースは22.4.2です。これらのケースでは、次のことを行います。
- 新しい機能が作成される前の早い段階で、developからの特別リリース用のリリースブランチ22.4.2を作成します。一部の機能は、私たちが除外したい開発作業が終わっていない限り、以前に開始されていても問題ありません。
- そこにタグを作成します（start-22.4.2）
- それぞれの新しい22.4.2機能を開始start-22.4.2（開発時の変更セット）を親/ベースとして。これにより、その間に開発するためにマージされた作業がリリースブランチにリークするのを防ぎます。コマンドラインとSourcetreeはどちらも、
git flow feature startのヒントの他に、親の選択をサポートしています。 - 必要に応じて、必要に応じて22.4.2ブランチの先端から機能に手動でマージし、ブランチから完了した機能を取り込みます。これにより、ブランチの新しい22.4.2機能間で懸念される相互作用に対処できます。
git flow feature finish機能。これをマージして、通常どおり開発します。 （私たちにとって、これらの機能は将来のリリースに含まれる予定です。テストされていない作業からのみ22.4.2を保護しています。）finishの後、機能を22.4.2ブランチに閉じる前の最後の変更セットを手動でマージします。
1つの解決策は、設定変数gitflow.branch.developを変更することです。リリースしたバージョンでブランチを作成し、そのブランチを新しい開発ブランチとして使用します。そこから、通常のgit-flowコマンドを使用します。その作業を自動的に元の開発ブランチにマージする場合は、git-flow finishコマンドの前にgitflow.branch.develop変数を変更します。