私はいくつかのgit実験をローカルで実行し、質問に記載されているワークフローの手順を複製しました。残念ながら、答えは「はい」と思われます。 git squashを使うと、何をやっているのか細心の注意を払わなければ、多くのマージ競合が発生します。
私はこれについて広範囲にわたってthis blog postに書いています。
上記の問題は、あなたが単純なマージを行っても、かすれがなくても発生しませんでした。その場合、マージ後、マスタとローカルブランチの両方にコミットD-Eが含まれます。したがって、次にローカルのD-E-F-G-Hブランチをマージしようとすると、gitはマスターの上にF-G-Hを適用してマージを実行します。
しかし、私たちはスカッシュをしたので、これはgitを混乱させます。残念ながら、コミットF-G-HはXで修正されたコードと同じ行を変更するため、結果のdiffはマージの競合で失敗します。
この問題を解決するにはいくつかの潜在的な方法：
ブルートフォース：それを吸うと、手動ですべての競合を解決します。
プルリクエストを送信したら、プルリクエストに含まれるコミットの上に追加のコミットを作成しないでください。プルリクエストのコミットは、gitの観点から消えていくので、あなたはそれらに依存したくありません。残念ながら、これは、あなたが提出したものの上で実行したい任意の改良が、プルリクエストが承認され、マージされるまで待つ必要があることを意味します。
以前のプルリクエストの上で改良を加えた場合は、以前のプルリクエストをマージすることを許可しないでください。代わりに、更新されたブランチを使用して新しいプルリクエストを送信するか、既存のプルリクエストをすべての詳細設定で上書きします。残念なことに、これはプル・リクエスト・プロセスをオール・オア・ナイン・アフェアにします。理想的には、最初のプルリクエストと追加のリファインメントを段階的に承認/マージすることができます。代わりに、競合を避けるために、あなたは一気に全部をマージするか、何もマージしないように強制する必要があります。
あなたの以前のPRがマージされたとし、あなたが今マスターに併合したいと思う新たな改良があるとします。ブランチ全体をマスターにマージするのではなく、作成したインクリメンタルなコミットをチェリーピックし、それらのチェリーピックされたコミットだけをマージします。したがって、上記の例では、D-E-F-G-HをXにマージしようとするのではなく、F-G-HをコミットしてXの上に適用し、結果のブランチでプルリクエストを作成します。これはうまく動作し、すべての競合を回避し、いつでも/あなたが望むペースで開発作業を行うことができます。残念ながら、D-E == Xという事実を手動で追跡する必要があり、F-G-Hを手動でチェリーピックして適用する必要があります。これは、より多くの時間と認知努力を必要とします。また、チェリーピッカーを多すぎる（とにかく紛争を起こす）、またはチェリーピッキングを少なめにする（そして重要な変更が見落とされる）ことによって、このステップを混乱させるのも簡単です。
githubのメタル機能を使用しないでください。いずれのスカッシュもプルリクエストを提出する前に、ローカルでコミットします。または、まっすぐに抜かずにプルリクエストをマージしてください。これは、ほとんどのプロジェクトの現状であり、そこにはすべての利点/欠点があります。
このように、マージする前にすべてのコミットを抑制するのに実際の問題やコストがあります。上記の解決策のどれも完全ではありません。私は、上記のうちのどれがすべての悪の中で最も小さいか分からない。しかし、私はあなたにこの問題についてもっと深く考えさせて、この新しい素晴らしいGitHub機能を利用する際の注意点を理解してほしいと思っていました。
お試しください。 –