あなたの例では、誰かがf36908d（最初の親;マージ時のHEAD）と8def6e9（2番目の親;おそらくマージ時の元のブランチの先端）をマージして326c8fd0を生成しています。
マージコミット（326c8fd0）が、その親（f36908dおよび8def6e9、後者の一部が欠落していると言う）に関して重要なコンテンツが欠落している場合、マージコミットを作成する人は、おそらく不適切な方法でマージを実行しています。ファッション。
この人は、oursマージ戦略（-s ours/でマージまたはプル--strategy=ours）、oursデフォルトの再帰的マージ戦略のオプション（/でマージまたはプル-X ours）--strategy-option=oursを使用している可能性があります。または、マージの競合を手動で解決するときに誤った決定を行っている可能性があります。
このours戦略では、最初の親を除くすべての親の履歴で行われたコンテンツの変更は完全に無視されます。マージコミットとその最初の親（つまり、それらの変更）は同一のツリーを持つ（つまりgit diff f36908d 326c8fd0、違いを示さない）ため、通常、このタイプのマージを識別できます。
マージ戦略オプションはours、2番目の親の履歴からの変更（つまり、変更）も無視しますが、最初の親の履歴で行われた変更（つまり、変更）と競合するものだけを無視します。この場合、2番目の親からの一部の変更が結果に反映される可能性がありますが、他の変更は完全に削除される可能性があります。
他の可能性のある代替案は、デフォルトのマージ中に生成された競合を解決しながら、彼らが悪い決定をしているだけであるということです。
いずれにせよ、誰かがマージを行ったユーザーと話し合って、彼らが何をしたのか、そしてなぜそれを行ったのかを調べて、将来問題を防ぐためのポリシーを考案できるようにする必要があります。
回復するには、自分でマージをやり直して、結果を履歴の現在のヒントにマージします。
git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git checkout develop
git merge remerge
# maybe resolve more conflicts
# eventually: git branch -d remerge
または、履歴の書き換えに問題がない場合：
git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git rebase --onto remerge 326c8fd0 develop
# maybe more conflicts to resolve at each rebased commit
