restory

Restructuring a pull request commit history involves reclassifying commits to separate refactors, features, and unrelated changes. This creates a clean narrative sequence while ensuring the final tree exactly matches the original HEAD state.

Separating refactoring commits from feature commits is done by grouping hunks into distinct categories. The workflow sequences refactors first, followed by the feature with its tests, and isolates unrelated changes to produce a coherent commit narrative.

You can restructure a git branch history safely by using a temporary safety branch and a target state tag. The original history is preserved in the reflog, and explicit confirmation is required before any risky operations are executed.

Yes, you can isolate unrelated code changes when cleaning up a PR. The restructuring workflow identifies and groups unrelated hunks into isolated commits, separating them from the primary refactors and feature additions to clarify the review process.

Restructuring commit history does not change the final code in your branch. The workflow enforces a target state tag to guarantee the final tree exactly matches HEAD, altering only the commit sequence and messages, not the resulting codebase.

You generate a plan for reordering commits by analyzing the branch history and outputting a detailed .restory file. This plan guides users through safety checks and reconstruction steps to produce a coherent sequence of commits.