Git’s experimental “git history” command simplifies fixing old commits

Working with many parallel changes in Git often forces developers into messy rebases and branch juggling. The experimental git history command, introduced in Git 2.54 (April) and refined in 2.55 (June), adds three subcommands—fixup, reword, and split—to streamline retroactive edits. By folding staged changes into an existing commit and automatically updating descendant branches, it promises a safer, more atomic workflow. Because it lives inside the core Git distribution, you can try it without installing external tools. Understanding its capabilities and limits can change how teams manage long‑running feature branches.

What happened

The command ships with three subcommands. git history fixup takes a staged change, folds it into a target commit, and then rebases every local branch that descends from that commit so the new hash propagates automatically. git history reword lets you edit a commit message without altering the tree, while git history split breaks a single commit into multiple logical pieces.

All three operations are designed to be atomic: the command refuses to start if the rewrite could leave the repository in an inconsistent state. This includes a safeguard against merge commits—if the target commit has a merge parent, the command aborts, because rewriting across merges can produce ambiguous histories.

Why it matters

Developers who spend hours manually crafting interactive rebase scripts can now rely on a built‑in, single‑command workflow that updates every affected branch. The atomic nature eliminates the half‑broken trees that often result from interrupted rebases, reducing the risk of lost work. Because the feature is part of core Git, teams avoid the overhead of adopting a separate tool like jj while still gaining many of its advertised benefits. However, its experimental status and merge‑commit limitation mean it isn’t a drop‑in replacement for all scenarios.

How to think about it

Treat git history as a targeted fix‑tool rather than a bulk‑rewrite engine. Before running it, create a temporary branch or tag the current tip so you can recover with git reflog if needed. Use fixup for small code corrections, reword for message clean‑ups, and split when a commit bundles unrelated changes. Run the command on feature branches that haven’t been merged publicly; once a branch is shared, coordinate with teammates or avoid rewriting altogether.

FAQ