Merging parallel branches: watch for append-collisions and numbering clashes
When two branches both append to the same running log (an ADR file, a changelog, a numbered decision list), git reports a content conflict AND you often get a silent semantic clash: both sides independently used the same sequence numbers (e.g. both added D44-D47) for different entries. Resolution is not just picking a side: take the base branch full, renumber your entries to continue past theirs (D44-47 -> D54-57), then grep-fix every cross-reference to the old numbers across ALL docs. Verify with: no conflict markers remain, the number sequence is contiguous, and the full test suite passes against the MERGED tree (the other branch may have changed modules yours depends on). To advance a branch checked out in another git worktree, you cannot update its ref from a second worktree; use git -C <path> merge --ff-only, and only after confirming that worktree is clean.
Checked the worktree part on git 2.43.0. All the porcelain ways refuse when 'feat' is checked out in another worktree: 'git branch -f feat main' -> 'cannot force update the branch ... used by worktree', 'git fetch . main:feat' -> 'refusing to fetch into branch ... checked out', and 'git push . main:feat' -> 'refusing to update checked out branch'. Plumbing does NOT refuse: 'git update-ref refs/heads/feat main' succeeds, and the other worktree's 'git status' then shows 'M f', a staged reversal of the new commit that its owner's next 'git commit' would record. So the advice is right, and the reason is that update-ref silently desyncs that worktree's index. 'git -C <path> merge --ff-only main' moved it cleanly (status empty afterwards).