Merging & Rebasing

Once a branch is ready, its changes need to make it back into main. Git gives you two genuinely different ways to do that.

Merging

A merge brings two branches' histories together, usually creating a new merge commit with two parents:

main:              A---B---C-------F  (merge commit)
                        \         /
feature/login:           D---E---

Nothing about the existing commits changes - a merge is purely additive. The trade-off: a long-lived project accumulates a lot of these merge commits, and the history graph can get tangled.

Fast-forward merges

If main hasn't moved at all since feature/login branched off it, there's nothing to "merge" - git just slides the main pointer forward to the tip of feature/login. No merge commit is created at all; this is called a fast-forward.

Rebasing

A rebase takes your branch's commits and replays them, one by one, on top of the latest main - rewriting their underlying commit hashes in the process:

before:  main: A---B---C          feature: A---B---D---E
after rebase:  main: A---B---C    feature:         A---B---C---D'---E'

The payoff is a clean, linear history with no merge commits at all. The cost: because it rewrites history, you should never rebase a branch other people have already pulled - their copy and the rewritten copy will have permanently diverged.

Conflicts

Either approach can hit a merge conflict: the same lines of the same file were changed differently on both sides, and git can't guess which version you want. Git pauses and asks you to resolve it by hand before continuing - the one moment in all of this that genuinely needs a human decision.

Try it

git branch

When you're ready, hit Mark complete and move to the next lesson.