Branch divergence is when two branches meant to represent the same history stop sharing a common lineage for a set of changes — typically because commits were cherry-picked or squash-merged between them instead of merged directly — so a later real merge produces conflicts even though the content looks identical.
Cherry-picking or squash-merging a commit from one branch onto another creates a brand-new commit with a new hash, even when the resulting file content is identical to the original. Git has no way to recognize that the new commit and the original represent "the same" change — as far as its history graph is concerned, they're unrelated. Repeat this enough times between two long-lived branches and their histories stop lining up, even though the branches look equivalent on the surface.
The fallout shows up later, when the branches are finally merged directly instead of cherry-picked between: Git compares the full histories, finds dozens of commits that appear unrelated despite representing the same underlying changes, and reports a wave of 📝merge conflicts even though nothing in the actual file content should conflict. The fix is to always merge — never cherry-pick or squash — between branches that will ever be merged into each other again; squashing is safe only for a one-way trip, such as a feature branch merging into a shared branch that will never receive a reverse merge from it.