リリース前に機能をデモするためのGitワークフロー
私のチームと私は、リリース前にWebアプリケーションの実験的な変更/機能をデモするためのgitワークフローを探しています。私たちの対象者には、プロジェクトマネージャーとデザイナー（アプリのインスタンスを実行することを期待していない人）が含まれているため、Webサーバーもホストする必要があります。
最初の試みでは、demoブランチを作成し、変更を共有する準備ができたので、機能ブランチにマージしました。変更が承認された後、機能ブランチはmasterにマージされてリリースされました。残念ながら、demoをmasterで常に最新の状態に保つと、マージの競合が発生することがわかりました。
各機能ブランチがアプリケーションの独自のインスタンスを取得するようにすることもできますが、理想はすべてのデモ機能をグループ化し、それらを1つの場所で提供することです。
誰かアドバイスはありますか？
編集：明確にするために、マージの競合はmasterとdemoの両方でファイルが変更された結果であると思われます。私たちの機能ブランチは長続きする傾向があり（たとえば、物事が調整されている間約1週間）、必然的にバグ修正やその他の変更がその間にmasterに加えられます。
Gitflowを使用する場合、マージの競合なしで、開発ブランチをデモブランチと同じように使用できます。
しかしながら。あなたの主な問題は、コードのプレリリース版を取得することではありません。これはさまざまな方法で行うことができます。
主な問題は、デモの1つの機能のリリースが承認されていない場合の対処方法です。
コードを変更したり、問題のある機能をコメントアウトしたり、再テストやリデモを行わずにリリースしたりすることはできません。
機能する唯一のソリューションは、機能ブランチで各脅威を個別にデモし、承認後にマスター/開発にマージすることです。
これはトランクベースの開発と同等であり、他の機能にマージする必要がある変更の一定の流れがあるため、機能を小さく保つ必要があります
機能の切り替えは非常によく話されていますが、欠陥があります。テストしたい場合は、機能トグルの各組み合わせをテストする必要があり、すぐに不可能になります。絶対に避けてください。
説明からは明らかではありませんが、異なる場所にある異なる機能ブランチでのまったく異なる変更、または何らかの形で履歴情報を失った同じ機能ブランチでの変更が原因で競合が発生しています。後者の場合は、demoの強制プッシュを回避しようとしている可能性があります。そのため、すべての一時的なマージが履歴に残り、競合が発生します。
より良いアプローチは、最新のマスターからdemoを毎回再作成し、デモンストレーションしたい機能ブランチをそこにマージすることです。このようなアプローチはgitプロジェクト自体で機能し、提案されたすべてのパッチをマージする p ブランチがあり、パッチが更新されるたびに更新されます。このようにすると、同じ変更の異なるバージョンが衝突するため、不要なマージの競合を回避できます。
異なる機能ブランチが同じ場所を編集するときに発生するマージの競合は、おそらく完全に避けられません。機能ブランチの寿命が長く、何度も何度もマージして、同じ競合を解決する必要がある場合は、 git rerere を試してみるとよいでしょう。このような場合に役立ちます。
機能がマージされるたびにマスターでデモを更新する代わりに、デモが必要になるたびにマスターから異なるデモブランチを作成できると思います。 （demo/feature_A、demo/featureBなど）