Silent merges are the default

Git's merge machinery operates at line granularity. A three-way merge compares two branches against their common ancestor and combines changes that do not collide; the Pro Git book illustrates this with diagrams of divergent histories converging cleanly. Two patches that implement the same feature in different files — or in different regions of the same file — meet no resistance and merge without a warning.

The one automated tripwire is collision. When both patches modify the same lines, Git declares a conflict and forces a developer to reconcile them. That moment is the only point at which version control itself notices that two strands of work may be the same strand of work.

Review depends on knowledge of both tickets

Once a clean merge has gone through, detection shifts entirely to code review. A reviewer examining a single pull request sees one implementation, not the parallel history behind it. The duplicate surfaces only if that reviewer happens to know both tickets — the one already landed and the one in flight.

Teams that spread ticket ownership across squads, or across time, have no structural mechanism that surfaces the overlap for them. The result is that duplicate code can accumulate not because tooling failed loudly, but because it succeeded quietly — applying two patches that never needed to meet.

For engineering organizations running parallel workstreams, the practical takeaway is procedural rather than technical: assign overlapping tickets carefully, and treat merge conflicts not as an annoyance but as the rare automated signal Git actually provides.

The picture that emerges — Git silent except for line collisions, and human review effective only when the reviewer knows both tickets — is Mostly True.