Loading page
About this tool
Answer a few questions about your branch and get a merge, rebase or squash recommendation with history previews and the exact commands.
This helper decides between git merge, rebase and squash merge for a specific branch by applying the golden rule of rebasing from Pro Git: never rewrite commits that exist outside your repository and that others may have based work on. Answer four questions — whether the branch is shared, how many commits it has, whether they are individually meaningful, and your history preference — and it returns a recommendation, the reasoning, ASCII history previews and the exact commands to run.
Open Git Merge vs Rebase Helper on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Shared branches always get a merge recommendation — the one case where rebasing genuinely breaks collaborators.
See the resulting commit graph for merge, rebase and squash side by side before choosing.
Each recommendation ships with the exact git commands, including --ff-only and --squash variants.
Rebase when the branch is private — not yet pushed, or pushed but not pulled by anyone — and you want a linear history. Rebase rewrites your commits with new SHAs as it replays them onto the target, which is harmless for unpublished work and destructive for shared work; that boundary is the whole decision.
Never rebase commits that exist outside your repository and that people may have based work on — as stated in the Rebasing chapter of Pro Git. Rewriting published commits gives every collaborator duplicate, divergent history that they must manually repair, usually with confused merges or a risky forced pull.
git merge --squash stages all the changes from a branch as a single commit on the target, discarding the branch's individual commits from the target history. GitHub and GitLab offer it as a pull-request merge method; it is the right choice when a branch's commits are wip noise but the overall change is one logical unit.
Yes — every replayed commit gets a new SHA because its parent (and often its content after conflict resolution) changes. That is why a rebased branch that was previously pushed needs git push --force-with-lease, and why rebasing anything a teammate has already fetched causes divergence.