git-history-squash

Squash first-parent Git commit ranges with recoverable backup refs and exact remote force-with-lease publishing.

2|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/NAMEWTA/learning-open-code --skill git-history-squash-namewta
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-history-squash
Source: https://github.com/NAMEWTA/learning-open-code/tree/main/speculo/skills/git-history-squash
Command: npx skills add https://github.com/NAMEWTA/learning-open-code --skill git-history-squash-namewta

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) and assets (resource) components.

What problem does it solve? Rewriting Git history by squashing commits is risky: a wrong range, a dirty worktree, or a drifting remote tip can destroy work with no way back. This Skill performs controlled history squashing of a branch tip's first-parent commit range using dry-run planning, explicit user confirmation gates, atomic ref transactions with backup refs, and precise --force-with-lease remote publishing, so every step is verifiable and recoverable. ## Core Features & Use Cases - Dry-run planning with frozen manifest: The plan command freezes full SHAs, range counts, merge counts, worktree/dirty state, affected refs, submodule graph, and remote protection policy without creating any Git object or moving any ref. - Confirmed local transaction: The apply command creates a single new commit from the end tree with one baseline parent, then uses a compare-and-swap update-ref transaction to create a backup ref and move the target branch atomically. - Exact remote lease publishing: The publish command pushes only with --force-with-lease=<ref>:<old-sha> after re-reading the remote tip, and blocks on GitHub protection rules that disallow non-fast-forward updates. - Submodule-aware layering: Child repositories must publish before parent gitlinks advance, with planned parent trees built via a temporary index. - Use Case: Before merging a long feature branch, squash its 30 first-parent commits into one commit, keep a backup ref for recovery, and publish to GitHub only after verifying branch protection allows the force push. ## Quick Start Ask the agent to run the git-history-squash skill to squash the first-parent commits of your current feature branch into a single commit with a dry-run plan first.

Frequently Asked Questions about git-history-squash

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I squash commits on a Git branch safely?

Use a dry-run plan that freezes the exact start and end SHAs, range counts, and worktree state before any write. The apply step then creates one new commit from the end tree and moves the branch with a compare-and-swap ref transaction that also creates a backup ref for recovery.

How to force push a squashed branch without overwriting others' work?

Push with an exact lease: git push --force-with-lease=<remote-ref>:<old-sha> <local-ref>:<remote-ref>. The old SHA is read from git ls-remote immediately before pushing, so any remote tip drift stops the push instead of silently overwriting commits.

Does this work with GitHub branch protection rules?

Yes, for github.com remotes the plan queries branch protection and rulesets via the gh API. Publishing is blocked when non-fast-forward updates are disallowed, the branch is locked, force pushes are disabled, or the policy cannot be determined.

Can I squash commits in a repository with submodules?

Yes, child repositories declare their parent via submodule_of and must publish first. The parent's planned tree replaces only the declared gitlink entries with the child's published new SHA, and the parent layer requires its own fresh confirmation digest.

What are the limitations of this history squash approach?

The end must equal the branch tip, so interior ranges cannot be rewritten. The start must lie on the first-parent chain, shallow clones and replace refs are unsupported, and dirty worktrees, in-progress Git operations, or active workflow evidence block execution.

How do I recover if a squash is interrupted midway?

Run the status command, which re-reads actual refs and remotes instead of trusting saved phase state. Each repository is classified as untouched, local-verified, published, recoverable-partial, or unknown-drift, and restore plans using the backup refs require fresh explicit authorization.