なぜこれが起こるのか頭の中で理由はわかりませんが、デバッグのヒントをいくつか提供できます。
まず、おかしな設定がないことを確認します。Git 構成を持たないアカウントで、これらのブランチの両方を持つリポジトリの新しいクローンを作成します。マージを実行してみてください。それはまだ起こりますか？そうでない場合は、設定を確認し、異常がないかどうかを確認してください。特に、 rerereの設定が疑わしいと思います。また、マージを実行して--no-rerere-autoupdate、問題の行がまだ削除されるかどうかを確認してください。
その後、マージの最大冗長性をオンにすることから始めて、マージを再試行します。
GIT_MERGE_VERBOSITY=5 git merge -v master
これにより、マージ プロセスで行われた決定に関する詳細情報が得られます。
それが有用なことを何も伝えていない場合は、別のマージ戦略、またはデフォルトの再帰的マージ戦略に対する別のオプションで発生するかどうかを確認することもできます。git merge -s resolveより単純だが愚かなマージ戦略を試してみてください。それでも問題は解決しますか? などの再帰戦略の別のオプションを試してみgit merge -s recursive -X patienceませんか? 余分な冗長性をオンにして最後に実行し、デフォルトのマージ戦略とは異なる決定を下すかどうかを確認します。
それがうまくいかない場合は、これを手動で最小限のテスト ケースに減らしてみてください。まず、問題のファイルだけに制限しようとします。使い捨てのリポジトリで作業していることを確認し、git filter-branchすべてのファイルを削除するために使用しますが、行が欠落している問題のファイルは削除してください。それを行って、再度マージを試みた場合、同じ結果が得られますか? そうでない場合は、Git が混乱して、実際には移動していないのに別のファイルに移動したと考えて、行が消えている可能性があります。
1 つのファイルだけでも問題を再現できる場合は、問題が解決するまで、各ブランチのリビジョン履歴をさかのぼってマージを行います。たとえば、開発ブランチから始めて、途中まで戻ってマージをやり直し、master からの行がまだ消えるかどうかを確認します。もしそうなら、さらにジャンプして戻ってみてください。そうでない場合は、開発ブランチに沿ってジャンプして、もう一度試してください。開発側で問題を引き起こすコミットを見つけたら、マスターで同じことを試し、問題がなくなるまでマージするコミットを戻します。
できる限りさかのぼったので、その時点より前の履歴の単純化されたバージョンを再作成してみてください。新しい Git リポジトリを作成し、これら 2 つのコミットのマージ ベースをチェックインします。次に、上記で追跡した 2 つのコミットを別々のブランチにチェックインします。それらを問題なくマージできますか、それともその間のマージ トポロジのいくつかの側面に依存しますか? その場合は、完全なマージ トポロジを再作成してみてください。履歴内のすべてのマージを行うために必要なコミットのみを作成します。それはあなたの問題を再現できますか？
この時点で、問題を再現するための可能な限り単純な履歴が得られ、それを示すファイルが 1 つだけになります (または、問題をこれ以上縮小して問題を再現できなかった場合に興味深いことがわかります)。その 1 つのファイルに機密性の高いものが含まれていない場合は、このリポジトリを公開して確認できるようにすることをお勧めします。関連する行。また、関連する各行をプレースホルダー値に置き換えて、実際のコードを一切含まない最小限のテスト ケースを残すこともできます。
上記はすべてかなりの量の作業ですが、すべてを完了する前に何か興味深いことが見つかるか、途中の手順をすべて実行せずにスキップして最小限のテスト ケースを生成できることを願っています。より最小限のテスト ケース、または上記の手順のいずれかの結果が得られたら、それらを投稿してください。詳細を確認できます。