git-history-rewrite

Rewrites existing Git commits through splitting, rewording, reordering, deletion, and timestamp restoration.

1|Updated Sep 11, 2026
One-click install
npx skills add https://github.com/lldwb/lldwb-claude-skills --skill git-history-rewrite-lldwb
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-history-rewrite
Source: https://github.com/lldwb/lldwb-claude-skills/tree/main/skills/git-history-rewrite
Command: npx skills add https://github.com/lldwb/lldwb-claude-skills --skill git-history-rewrite-lldwb

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Rewriting Git history (splitting commits, fixing commit types, reordering, deleting entries, restoring timestamps) is irreversible and error-prone: a missed backup, a wrong rebase base, or a CRLF mismatch can silently corrupt history. This Skill enforces a disciplined workflow—backup branch first, plan before acting, four-fold verification, and confirmed force-push—so structural history corrections stay safe and recoverable. ## Core Features & Use Cases - Five structural corrections: split one commit into multiple by file, reword type/title, reorder commits, delete commits, and restore original author/committer timestamps after rebase or filter-branch. - Release commit rules: enforces chore(release): 发布 vX.Y.Z conventions—version files only, positioned after the last feature commit of that version, entries immutable once created. - Batch content replacement: uses filter-branch --index-filter with a ready-to-adapt script template to replace text across many commits while avoiding core.autocrlf line-ending traps. - Four-fold verification: tree consistency against the backup branch, commit rules, timestamp semantics, and tag retargeting must all pass before a --force-with-lease push. - Use Case: You need to split version-bump files out of a feature commit, move the release commit to the end of the version, and restore original commit times—this Skill walks you through backup, planning, rebase execution, verification, and a confirmed force-push. ## Quick Start Ask the AI to split the version files out of a specific commit and rewrite the branch history safely with backup and verification.

Frequently Asked Questions about git-history-rewrite

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

FAQPage Schema
How do I split one Git commit into multiple commits?

Save the original message with git log -1 --format='%B' HEAD before running git reset --soft HEAD^, then unstage files that belong to later commits with git restore --staged, and commit each group separately. The message must be captured before the reset, otherwise you get the parent commit's message.

How to restore original commit dates after git rebase?

Rebase resets committer dates to the rewrite day, so build a mapping file of commit hash to original author and committer timestamps from the backup branch, then apply them with git filter-branch --env-filter setting GIT_AUTHOR_DATE and GIT_COMMITTER_DATE. Split commits inherit the original commit's time.

Should I use filter-branch --index-filter or --tree-filter?

Prefer --index-filter when changing only a few files: it edits blobs directly in the index without checking out files, avoiding core.autocrlf line-ending conversion that causes silent replacement failures with --tree-filter. Always verify by reading back the new content with git show and grep -c.

Why did my GIT_SEQUENCE_EDITOR edit marker not apply during rebase?

The sed expression matches todo lines by hash prefix, so abbreviated or mismatched hashes cause the target commit to be silently replayed as pick. After the rewrite, verify each target commit was actually processed by comparing git log output against the plan.

When should I not rewrite Git history?

Use git-rollback instead when resetting or reverting a branch to a past state, git-clean-branches for branch cleanup, and commit-review when you only want to audit commit quality. History rewriting requires force-pushing, which affects every collaborator's clone.

Is force-pushing rewritten history safe for collaborators?

Force-pushing overwrites remote history and forks every collaborator's clone, so it requires explicit user confirmation with an impact explanation. The workflow uses --force-with-lease for branches after fetching, and --force only for tags, with the backup branch retained for recovery.