Cleanup Branches

Cleanup Merged Local Branches

Delete every local branch whose PR has already been merged — plus any branch with no PR of its own whose changes are all already represented on origin/development (e.g. a gh pr checkout <N> review checkout) — then bring development up to date. Leave persistence.xml with local JNDI names restored (unstaged) at the end.

Step 1 — Stash Local persistence.xml Changes

Only stash persistence.xml — not all uncommitted work. This prevents unrelated WIP from being moved onto development when the stash is popped.

git stash push -- src/main/resources/META-INF/persistence.xml

If this reports "No local changes to save", that is fine — continue. Note whether a stash was created so you know whether to pop it in Step 7.

Step 2 — Fetch Latest from Origin

git fetch origin --prune

--prune removes remote-tracking refs for branches deleted on GitHub.

Step 3 — Collect All Local Branches Except development

List every local branch except development:

git branch --format='%(refname:short)' | grep -v '^development$'

For each branch, determine whether it is safe to delete.

Protected branches — never delete, never classify

Before the feature/hotfix split, skip any branch that is master or ends with -prod (the local mirrors of admin-managed / production branches — see Notes for the full list). They diverge from development by design, so a naïve patch-equivalence check could still misfire on them; the explicit skip is the guarantee. List them in the report under their own "Protected — not touched" heading (they are expected, not a problem to flag).

Feature branches (do NOT end with -hotfix)

The comparison base is origin/development. Look for a merged PR from this head:

gh pr list --head <branch> --base development --state merged --repo hmislk/hmis --json number,title,mergedAt --jq '.[0]'
# if that is empty, retry without --base — the PR's base may have been changed:
gh pr list --head <branch> --state merged --repo hmislk/hmis --json number,title,baseRefName,mergedAt --jq '.[0]'

Record the PR number/title if found. If the second query returns a PR with a baseRefName other than development, the comparison base is origin/<that baseRefName>, not origin/development. Whether or not a PR is found, continue to Vet the branch tip — a merged PR does not by itself prove the local branch is safe to force-delete (it may carry post-merge commits, or have been reused).

Hotfix branches (end with -hotfix)

Hotfix PRs target a production branch. Look for a merged PR:

gh pr list --head <branch> --state merged --repo hmislk/hmis --json number,title,baseRefName,mergedAt --jq '.[0]'

• No merged PR → skip (warn the user). A hotfix branch is never vetted by patch-equivalence against development; its commits legitimately are not there.
• Merged PR found → record the PR number/title and its baseRefName, then Vet the branch tip with the comparison base origin/<baseRefName>.

Vet the branch tip (both branch kinds)

Carry two facts forward for each branch: its PR reference — either #<n> → <base-branch> (from the gh pr list step) or none (a no-PR review checkout) — and its comparison base <base>: origin/development for a feature branch or a no-PR checkout, origin/<baseRefName> for a feature PR whose base was changed, origin/<prod> for a merged hotfix.

git merge-base --is-ancestor <branch> <base> && echo CONTAINED || echo AHEAD

• CONTAINED — the branch tip is already reachable from <base>; it holds nothing unmerged and no post-merge commits. Mark for deletion.

• AHEAD — the tip is not reachable from <base>. Normal for a squash- or rebase-merged PR, but also how a branch with genuine post-merge commits (or a reused branch) looks. Decide with a final-tree guard: are <branch>'s versions of the files it touched already identical to <base>?

  mb=$(git merge-base <base> <branch>)
  git diff --quiet <base> <branch> -- $(git diff --name-only "$mb" <branch>)

  This compares final content, not per-commit patches, so it is correct where git cherry is not: a clean multi-commit squash-merge (no per-commit equivalent) passes; a branch whose change was applied to <base> and later reverted there fails; a merge commit that carried unique content in fails.

  • exit 0 — every file the branch touched already matches <base>; deleting the branch loses nothing (a clean squash/rebase merge, or a fully-absorbed no-PR checkout such as pr-23617). Mark for deletion.
  • exit 1 — some file the branch touched differs from <base>: genuine post-merge work, a reused branch, conflict-resolution content, or a squash/rebase that did not land identical content. Skip and warn, quoting the branch's real <base> and its PR reference (or noting it has none): "ahead of <base> — if PR #<n> was squash/rebase-merged, git branch -D <branch> manually; otherwise inspect for unmerged work first".

  Empty touched-file list gotcha: if git diff --name-only "$mb" <branch> is empty, the command above degrades to a full-tree git diff --quiet <base> <branch> (no pathspec) and will almost always exit 1 — not because <branch> differs from <base>, but because <base> has since changed unrelated files <branch> never touched. Don't trust that exit code in this case. Instead compare tree hashes directly:

  [ "$(git rev-parse <branch>^{tree})" = "$(git rev-parse "$mb"^{tree})" ] && echo IDENTICAL || echo DIVERGED

  • IDENTICAL — <branch>'s tree is byte-identical to the merge-base (its "ahead" commits are no-ops, e.g. an empty merge), and the merge-base is by definition an ancestor of <base>. The branch holds zero unique content. Mark for deletion.
  • DIVERGED — genuinely different content despite the empty per-commit diff (rare). Skip and warn.