Skip to content
GitTree
العربية

Video: Merge versus rebase: choose with a graph

The video plays in YouTube’s player, in privacy-enhanced mode.

Run merge and rebase from two identical copies of the same divergence, compare the two graphs, the parents and the file trees, and learn the one rule that decides between them: who else already has your commits.

Read the full lesson

The article has every step and command from the video, the practice exercise and the questions.

Go to the lesson

Video transcript

The narration of the video, cue by cue.

  1. Merge or rebase? The same work can leave two different histories.
  2. We will run both from the same starting point and compare.
  3. Your branch has one commit. The updated branch has another.
  4. Both grew from the same commit, so neither contains the other.
  5. First, prepare the divergence and make two identical copies.
  6. A fair test needs the same refs and files in both copies.
  7. Here is the first copy. We will merge in this one.
  8. And this is the second copy. We keep it untouched for the rebase.
  9. Right-click updated-main and choose its Merge command.
  10. Under Record it as, choose Always a merge commit.
  11. Choose Merge once, and wait for the real result.
  12. The new commit has two parents: your commit, then updated-main's.
  13. Now the second copy. It still has the two original commits.
  14. Right-click updated-main again, and choose Rebase this time.
  15. The dialog names the branch and the target. Leave both options off.
  16. Rebase once. Git replays your commit on top of updated-main.
  17. The replayed commit has a new parent, so it gets a new ID.
  18. The old commit is not lost: the rescue branch still points to it.
  19. Now compare the files. The page is the same in both copies.
  20. So is the integration note. Same files, different history.
  21. Look at the two graphs: a diamond with a merge commit, and a straight line.
  22. So which one should you use? Ask who else has your commits.
  23. If others have them, merge. A rebase would rewrite their history.
  24. If the commits are private, rebase is safe, and gives a straight line.
  25. Neither makes your code better. The rule is about ownership.
  26. Now prove it in the terminal. First, the parents of each tip.
  27. Three IDs for the merge copy: the commit, and its two parents.
  28. Two IDs for the rebase copy: the commit, and its one parent.
  29. Then the file trees: one ID, printed twice. Same files.
  30. But the two commit IDs differ. Equal trees, different histories.
  31. Change the input: suppose your branch had no commit of its own.
  32. A default merge would then fast-forward, with no merge commit.
  33. Never rebase a branch that someone else already has.
  34. If the trees differ, compare the starting refs first.
  35. Do not delete a result to force the two to match.
  36. Practice: report the parents, the IDs and the trees from your own copies.
  37. Next, reorder, squash and reword your local commits.

All tutorials