#1 India's Top IT Training Institute

×

About Uncodemy

Know more about who we are and what we stand for.

About Us

About Us

Discover our mission to equip individuals with essential IT skills and industry expertise.

Read More →
UnCodeMy Gallery

UnCodeMy Gallery

Explore highlights from our IT training sessions and success stories.

Read More →
×

Free Resources

Learn, practice and plan your career — bilkul free.

Tutorials

Tutorials

Step-by-step written tutorials to learn any technology at your own pace.

Read More →
Free Counselling

Free Counselling

Book a free video counselling session and pick the right course for you.

Read More →
Online Compiler

Online Compiler

Write, run and test your code online — no setup required.

Read More →
🌿 FREE · GIT HISTORY

Git Merge vs Rebase Visualizer: Same Branches, Three Histories

Choose how many commits are on main and on your feature branch, and compare the history each command leaves behind.

  • ⊕ Merge commits
  • ♻️ Rebased copies
  • 📦 Squash merge

How to use the Git Merge vs Rebase Visualizer

  1. 1. Set it upSet the new commits on main (0–5) and on feature (1–5).
  2. 2. RunPress Compare.
  3. 3. ReplayRead the four diagrams: before, after merge, after rebase and after squash merge.

Worked example

With 2 new commits on main (M1, M2) and 3 on feature (F1–F3), git merge adds a merge commit with two parents, so main gains 4 commits and every original hash stays the same. git rebase main on feature replays F1–F3 on top of M2 as new commits F1′–F3′ with new hashes, giving a straight line; merging then is a fast-forward that adds 3 commits. git merge --squash adds a single commit S containing all the feature changes.

Set main to 0 commits and merge becomes a fast-forward with no merge commit, and rebase has nothing to do.

Which should you use?

  • Merge keeps the true history and is safe on shared branches, at the cost of merge commits in the log.
  • Rebase gives a clean, linear history and is great for tidying your own local commits before opening a pull request.
  • Squash merge keeps main's log to one commit per feature, which many teams use for pull requests, but the individual commits aren't kept on main.

The golden rule of rebasing

Never rebase commits that others have already pulled. Rebasing creates new commits, so teammates who built on the old ones get duplicated or conflicting history. If you must update a pushed feature branch you own, use git push --force-with-lease, which refuses to overwrite work you haven't seen.

Frequently asked questions

Are the hashes real?

No. They're made up for the diagram. Real hashes depend on the content, author, time and parent commits.

Does rebase cause more conflicts?

It may make you resolve conflicts once per replayed commit, whereas merge resolves them once.

Can I undo a rebase?

Usually, with git reflog to find the old commit and git reset to return to it.

Is the Git merge vs rebase visualizer free?

Yes. You can use the Git merge vs rebase visualizer without signing up. The first time you run it, we ask once for your name and WhatsApp number; after that the Git merge vs rebase visualizer and every other Uncodemy tool open straight away.

More free tools

See all free tools