私たちは、本番リリース用にトランクからブランチ、タグへの変更を促進する標準的なパターンに従っています。本番環境で変更にパッチを適用する必要がある場合、変更はブランチに反映され、そのブランチから新しいタグが作成されます。現在、変更が確実にトランクにプルされ、テストされることは作成者の責任です。残念ながら、現在の本番環境の問題の修正、テスト、および展開に追われている最中に、作成者が変更をトランクにプルするのに失敗することがあり、次のリグレッションでのみこれに気付きます。私の同僚の 1 人は、ポリシーを変更して、最初にすべての変更をトランクでテストし、トランクからの変更のみをブランチに昇格できるようにすることを提案しました。
長所：
- トランクへの変更のプルを見逃さないようにするためのポリシー ソリューション
短所：
- 本番環境の問題を修正するときは、本番環境に移行する可能性のあるトランクではなく、本番環境に移行する予定のブランチ コードで即時の修正をテストしたいと考えています。早送りコピーに変更を加えてからブランチコードのパッチを後付けすることで失われる時間は、ぎこちなく思えます。逆に言えば、トランクがブランチとは異なる動きをする (パラダイム シフトのように) シナリオはそれほど多くないかもしれません。
そのようなことは通常、オープンソース プロジェクトではどのように処理されますか? また、その他の長所や短所の緩和についても遠慮なく指摘してください。