GitFlow：開発ブランチの変更を機能ブランチに安全にマージします
最近、大きな機能に取り組み始めたので、新しいfeature/xyzブランチを作成しました。問題は、この機能が大きいため、完了するまでに約3か月かかることです。 developブランチからの変更が既に機能ブランチで行った更新を上書きすることを心配せずに、developで行われた進捗を安全に機能ブランチにマージしたいと思います。 developをfeature/xyzにマージしようとする以前の試みは、元に戻される新しい機能で既に行ったいくつかの変更で終わりました。
これを達成するためのコマンドは何でしょうか？ありがとう
唯一の安全性は、学習、識別、および頻繁なマージにあります。
developとfeature/xyzのコードがどのように整列するかを理解できるのはあなただけです。ふさわしい方法で2つのフローを正しくマージできるのはあなただけです。 -S oursまたは-X theirsよりもはるかに危険性の低いデフォルトのマージ戦略を使用しても、常に結果を確認する必要があります。
もちろん、いくらかの助けが必要かもしれません、そしてgitはいくつかを提供します。たとえば、gitで記録された解像度- rerere を使用すると、最初に決定した後、同じ正しいマージ決定を行うのに役立ちます。
ブランチに指定した名前を使用した、かなり一般的で比較的単純なモデルがこのように機能しますが、
developは、開発の主な推進力が発生するブランチです。xyzは、機能xyzを開発するブランチですxyz_stageは、developとxyzコードをマージするブランチで、そのブランチをdevelopとxyzのそれぞれの安定点に合わせて安定させます。これは、機能xyzまたはその一部をリリースする準備ができたときに最終的に開発にマージするブランチでもあります。
上記では、xyzをxyz_stageにマージするだけでなく、developをxyz_stageにマージし、xyzの一部がこれまでにxyz_stageにリリースされていることを確認します。 developのコードと関連して関連するテストに合格します。
それでも、開発の進行状況を認識しながら、機能で作業するxyzブランチをどのように作成するかを選択する必要があります。
最もクリーンなオプションは-それを認識させないでください。そのため、2つの開発フローが一緒になるxyz_stageがあります。 xyzの開発が長引かない限り、このアプローチは実現可能であり、正気です。
2番目のオプションは、ステージングブランチに満足したら、xyz_stageをxyzにマージして戻すことです。そうすれば、xyz機能を継続して開発できる安定したポイントが得られます。
以下に、コメント付きのプロセスの簡単な図を示します。
git merge -s recursive -X ours を使用します。これにより、2つのブランチで競合が発生し、チェックアウトされたディレクトリ（この場合はfeature/xyz）のバージョンを使用して常に解決されます。
重要：タイトルに反して、この戦略は必ずしも「安全」ではありません：developからの変更は、feature/xyzの変更と競合する可能性があります。いつものように、マージされた変更を適切にテストしてください。
私の経験では、唯一の「安全な」ソリューションは、マージの結果を常に手動で検査およびテストすることです。 --no-commitはマージをステージングし、コミットする前に検査できるようにします。または、より実用的と思われるものをリセットまたは修正できます。 3者間マージツールを入手すると非常に役立ちます。マージの競合がなくても物事が壊れる可能性のある方法はあまりにも多く、自動マージに依存することで問題が発生します。 100％のテストカバレッジがある場合、もう少しリラックスできますが、実際にそれを主張できるプロジェクトはいくつありますか？ ;-)