Describe what is mixed together
Enter how many files changed, how many distinct concerns are mixed in (bugfix, refactor, new feature, config), and whether risky or generated changes are in the pile.
COMMIT PLANNING
Git Change Splitter
Recommend how to divide a pile of mixed working changes into coherent commits or pull requests, based on how many concerns, files, and risk types are mixed together.
- Uses your inputs in a transparent calculation
- Instant result with practical next steps
- No signup required
Planning guidance only. Validate important decisions with customer evidence and your delivery team.
YOUR INPUTS
Build your result
Complete every field. The result updates only when you choose Calculate.
How it works
Calculate an entanglement score
The tool weighs concern count, file overlap between concerns, risky changes, and generated/noise files to estimate how hard the diff will be to split cleanly.
Get a concrete commit plan
You get a recommended number of commits or PRs, an average file count per commit, and ordered next steps for staging and sequencing the split.
Continue learning: Keeping MVP code reviews focused on product risk · Code review rules for AI-assisted development
Frequently asked questions
Does this read my actual git diff?
No. Everything runs from the numbers and notes you enter — nothing is uploaded or connected to a repository. It is a planning aid, not a diff parser.
Why does a risky change always get its own commit?
Isolating migrations, auth, payments, or deletions into their own commit or PR makes them easy to review carefully and to revert independently if something goes wrong, without dragging unrelated changes along.
What counts as a "concern"?
A concern is one coherent reason for a change — a single bugfix, a single refactor, a single new feature, or a single config/dependency bump. Mixing concerns in one commit is what makes review and rollback harder.
My files overlap between concerns — what should I do?
High overlap usually means two changes touch the same lines. The tool suggests landing the smaller, lower-risk edit first and rebasing the rest on top, or using per-hunk staging (`git add -p`) to separate them inside the same file.
Is the recommended commit count exact?
It is a starting estimate based on concern count, overlap, risk, and noise. Use it as a floor — splitting further is almost always fine, splitting less rarely helps reviewability.
Does this replace code review?
No. It only helps you shape the diff before review so a human (or AI) reviewer can evaluate each change on its own merits.
How We Compare
| Feature | MVPHub | GitHub Copilot | Cursor |
|---|---|---|---|
| Works from a manual description, no repo access needed | Included | Not included | Not included |
| Transparent, explainable split logic | Included | Limited | Limited |
| Suggests commit/PR count and sequencing | Included | Limited | Limited |
| Flags risky changes for isolation | Included | Not included | Not included |
GitHub Copilot and Cursor can help write commit messages or suggest code changes inside your editor, using repository context. MVPHub works from a short manual description of your change set and returns a transparent, rule-based split plan without needing repository access.
Related tools
Embed this tool
Add this tool to your site with the canonical iframe below. It remains hosted and maintained by MVPHub.