複数リリースのGitブランチ戦略

Question

私のチームはGitLabを使用したGITを初めて使用しており、次の問題を解決しようとしています。

私はプロジェクトAを持っており、それに取り組んでいる3つのチームがあります。

チーム1月3月は

チーム3は、7月のリリース

我々は量産コードのためのマスターのアイデアを持ってい放した

チーム2を解放しています。 私たちが苦労している質問は、チーム2にすべてのチーム1の変更があり、チーム3にはすべてチーム1と2の変更があることを強制する最良の方法は何かです。

私たちはDevJan、DevMarch、DevJulyブランチを持っています。しかし、上流の流れが適切に変化するための良い方法はないようです。

定期的にリベースしますか？チーム1の場合、3つの支店すべてにコミットしますか？ 私はGITのすべての議論で同様のシナリオを見つけられませんでした。

Answer 1

問題のブランチは、特にコラボレーションのために存在するため、ワークフローの一部を再配置することはありません。 DevJanをDevMarchに定期的にマージし、DevMarchをDevJulyにマージすることを練習にすることができます。

このワークフローの欠点...チーム2とチーム3は、マージ頭痛を拡大する可能性がある周期的なチャンクのチーム1の変更を吸収しますが、これは3つの永続性のあるデベロッパーブランチを持つという決定に固有のものです。それを軽減する最善の方法は、定期的なマージをかなり頻繁に（おそらく毎日）行うことです。つまり、「より早いリリース」の変更を「後のリリース」のブランチにもたらすマージコミットが数多く得られます。ある人は "余分な"マージコミットが気に入らないのですが、もしあなたがフィーチャーブランチを使うならば、devブランチは何とかなるでしょう。

Answer 2

それらを1レポに入れることができます。

あなたはgit checkout -b Release/July、コミット、3月から再びgit checkout -b Release/Janをコミットし、そこgit checkout -b Release/Marchから、その後、現在の7月のプロジェクトからすべてのソースをコミットすることができます。 ですから、今、彼らはそれぞれが、自分のリリースブランチへのマージ戦略を持っている 、あなたが上向きの枝をマージすることができ

----------- Release/July Team 3 
    \------- Release/March Team 2 
    \-------- Release/Jan  Team 1 

のような構造を持つことになり、マージしながら、ここでの素敵な葛藤があり得ることを覚えて、下の枝からすべてを「連鎖」する必要があります。

rebaseまたはcherry-pickは、ブランチ間にマージできないもの（たとえばdbスキーム）があり、マージする必要があるものを厳密にする必要があります。しかし、imhoのいずれかの方法は、複数のリリースを維持するのは難しいです。