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.
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.
SEO indexing check
Reviews sitemap completeness, canonical URL configuration, hreflang pairing for bilingual sites, robots.txt directives, and Search Console signals before publishing a content batch. This is especially important for bilingual static sites where indexing misconfigurations can cause search engines to index the wrong locale or deprioritize pages unfairly.