Pin the merge method per direction, and show rebase is safe here

[ChrisonSimtian]

Settles the open question: squash into develop, rebase into main. Merge commits stay disabled.

Merging	Method
feature/* → develop	Squash
develop → main	Rebase
release/* / hotfix/* → main	Rebase
port-back → develop	Squash

GitHub can't enforce a method per branch, so this is written down rather than configured. Both methods stay enabled because both are correct somewhere. Repo settings are unchanged and already correct: merge_commit: false, squash: true, rebase: true.

Why rebase between two long-lived branches is safe

This is worth recording because it's a fair thing to worry about, and I nearly talked us out of rebase over it.

Rebase-merge rewrites commits, so main never becomes an ancestor of develop. Once a hotfix lands on main and is ported back, the merge base falls behind both — so the next release looks like it would replay commits already present on main.

It doesn't. git rebase detects already-applied commits by patch-id and drops them. Verified rather than assumed — simulated a release, a hotfix on main, and a cherry-pick back to develop:

GitHub would replay for release 2:  B, hotfix, A
RESULT: clean
  replayed: B

Three candidates, one replayed, no conflict and no duplicates.

The edge case is documented too: a port-back that was conflict-resolved differently from the original no longer matches by patch, so rebase will retry it. That surfaces as a conflict at release time — visible and fixable, not silent corruption.

Also

PR template now states the base branch and merge method, since those are the two things easiest to get wrong under GitFlow.

---

Incidentally this is the first PR under the new flow — feature-style branch off develop, targeting develop. Being docs-only, it should be build-skip.yml that reports the required check rather than a real build.

🤖 Generated with Claude Code