Systematically closes out a development branch by running verification, cleaning up the commit history, pushing with proper tracking, and making an explicit choice between merge, squash, or follow-up tickets. This prevents the common pattern of abandoned branches, stale PRs, and lost context when work is not deliberately concluded.
Use cases
- Completing a feature branch that is ready for final QA or stakeholder review
- Cleaning up an experimental branch that produced useful learnings but is not going to production
- Archiving a branch after its goal was achieved and the work was merged or picked into another branch
- Wrapping up a sprint branch where incomplete work needs to be deferred with a clear handoff note
- Post-release branch cleanup after a deployment has been confirmed stable in production
Key features
- Confirm CI is green and run any local verification steps that are not covered by CI (smoke tests, manual checklists)
- Review the diff and stage only intentional changes, reverting any debug code, temporary workarounds, or unrelated formatting changes
- Craft a meaningful commit message that describes what changed and why, with a reference to the ticket or issue number
- Push the branch with proper remote tracking and open the PR with a clear description of what changed and how to test it
- After merge, delete the local and remote branch unless it needs to be preserved for a hotfix lineage, and update any related tickets
When to Use This Skill
- When a feature branch has passed all reviews and is ready to be merged into the main branch
- When a branch is being abandoned or superseded and needs to be closed cleanly without losing the commit history
- When a sprint ends and branch work needs to be reconciled with what was actually shipped
Expected Output
A merged or archived branch with a clean commit history, a documented PR description, and a deleted local/remote branch reference.
Frequently Asked Questions
- When should I squash-merge versus a regular merge versus a rebase-and-merge?
- Use squash-merge when the branch has many small, experimental commits that would not benefit future blame or bisect. Use regular merge when the commit history tells a meaningful story. Use rebase-and-merge when you want a linear history but preserve individual commits.
- What if CI is red but the failures are unrelated to my changes?
- Document the failures as pre-existing CI issues in your PR description, get a sign-off from a maintainer that the failures are acceptable to merge, and file a separate ticket to fix the CI issues.
- Should I delete a branch immediately after merging?
- Yes, unless you need to preserve the branch for a hotfix lineage. Stale branches create confusion about which branch is the source of truth and lead to accidental commits that never get merged.
Related
Related
3 Indexed items
Git worktrees for isolation
Uses Git worktrees to create isolated working directories attached to the same repository, each on a different branch, so parallel experiments or long-running tasks do not interfere with the main working tree or require repeated stash-and-reapply cycles. This is especially useful when one branch requires a heavy build or test run while work continues on another.
Custom AI semiconductor earnings claims due diligence
Structures verification of custom-AI chip vendor earnings headlines into a finance and supply-chain checklist. The workflow separates consolidated revenue and EPS beats from AI semiconductor sub-segment growth, full-year AI revenue guidance (raised vs reiterated), and infrastructure software shortfalls cited in the same report. It references CNBC reporting on June 3, 2026 that Broadcom's fiscal Q2 revenue was $22.19 billion versus $22.27 billion estimated (48% YoY), adjusted EPS $2.44 vs $2.40, AI semiconductor revenue $10.8 billion (more than doubled YoY), Q3 revenue guidance about $29.4 billion vs $28.53 billion expected, infrastructure software revenue $7.18 billion vs $7.32 billion expected, CEO Hock Tan reiterating AI semiconductor revenue in excess of $100 billion in fiscal 2027 without raising the 2026 forecast, naming six core custom-chip customers including Anthropic, Google, Meta, and OpenAI, and saying Broadcom would offer chips only rather than complete integrated AI systems—without treating media figures as procurement commitments.
Systematic debugging
Replaces trial-and-error debugging with a hypothesis-driven process: state a falsifiable hypothesis, construct the smallest possible reproduction, and verify evidence before touching code. This structured approach is most valuable during production incidents, flaky CI builds, and confusing regressions where intuition-led debugging wastes hours on correlated but non-causal symptoms.