原則として、変更をマスターから本番にマージする必要があります。したがって、一部のワークスペースで、運用ブランチに切り替え、マスター ブランチをマージしてから、開発サーバーと運用サーバーにプッシュします。これは、任意の開発者のワークスペースで実行できます。
プロダクション ブランチに直接変更が加えられない場合、すべてのマージは「早送り」されます。つまり、「プロダクション ブランチ」は基本的にマスター ブランチ上の位置へのポインタであり、プロダクションが最後に更新された時点を示します。 . これは、マージによって競合が発生することも決してないことを意味します。この場合、技術的には、「git push origin master:production」を実行して、リモート サーバー上の運用ブランチを更新できます。
中間リポジトリ（ここでは「開発」）を持つことは、本番環境に配置される可能性のあるコミットを統合およびデバッグするための良い方法です。
rel2.3しかし、最終的な修正/マイナーな調整を行えるようにするために、中間リポジトリにリリースブランチ（たとえば''）を作成してから、prodリポジトリrel2.3の' production'ブランチを（タグとともに、 2.3）を表す正確なコミットをマークするため
したがって、個々の開発者はproductiobに直接プッシュするべきではありません。中間リポジトリにプッシュされたものを検証した「インテグレーター」（またはテスター）のみがprodにプッシュする必要があります。
そして、rel2.3_hotfixes緊急の修正を本番環境に一度分離するために、prodリポジトリに''ブランチを作成します。
つまり、各リポジトリ（開発者、および「開発」）は、本番ブランチと同期する（つまり、リベースする）必要があります。これにより、特定のリリース後にコミットが追加される可能性があります。