それは素朴な git の質問かもしれませんが、ここにあります:
プル リクエストを行う前に、私は通常、アップストリームの最新のコミットから新しいブランチを作成し、開発ブランチから重要なコミットをチェリー ピックします。次に、新しいブランチからリモート リポジトリにプル リクエストを送信します。
しかし、マージの競合は嫌いです (ただし、競合が発生した場合は git mergetool が大いに役立ちます)。これらの競合のいくつかは、cherrypicks の順序が原因であると思われます。私は通常、最も古いコミットから最も新しいコミットまで一連のコミットを選択します。これは正しいアプローチですか？または、コミットの順序は git にとって重要ではありませんか?
チェリーピッキング中にマージの競合を最小限に抑えるための他のトリックはありますか?
確実に順番にコミットを選択する必要があります。そうしないと、適用されない可能性があります。あるコミットで foo.c が追加され、次のコミットでそれが変更されるとします。明らかに、それらは順不同で機能するわけではありません。一般に、それほど明白でなくても、開発には論理的な流れがあり、それを台無しにしたくはありません。そうは言っても、ブランチを手動で作成してチェリーピッキングを行う理由がわかりません。(コミットをスキップしない限り) と同等ですgit pull --rebase。
チェリー ピッキングの際にマージの競合が発生する場合は、開発プロセスが理想的ではないことを示しています。これは、開発ブランチで取り組んでいるものも上流で変更されていることを意味します。他の人が取り組んでいるのと同じコードに取り組まないか、pull --rebase開発中に最後まで待つのではなく、より頻繁に上流から (おそらく、再び) プルすることで、自分自身を助けることができるかもしれません。
もちろん、コミットの順序は重要です。コミット B がコミット A で最初に導入されたものを変更する場合、コミット A が適用されるまでコミット B を適用することはできません。
あなたのワークフローは奇妙です。git rebase上流のブランチのコンテンツの上にブランチを再構築するかgit merge、上流のブランチだけを自分のものに再構築する必要があります。これにより、チェリーピックの作業が回避され、実際に git が競合を自動的に解決する可能性が高くなります。