git merge: Fast-Forward vs 3-Way Merge

Git merge integrates one branch into another, but it does it in two different ways depending on the history. When you merge, Git first checks whether a fast-forward is possible. A fast-forward happens when the branch you're merging into hasn't changed since you branched off. In that case Git just moves the branch pointer forward to catch up — no new commit is created, because there's nothing to reconcile. It's like one timeline simply being ahead of another. The other case is a three-way merge, which happens when both branches have new commits since they diverged. Git can't just move the pointer because both sides changed, so it looks at the common ancestor where the branches split, compares each side against it, and creates a new merge commit. That merge commit is special because it has two parents, one from each branch, and that's what turns Git history into a graph rather than a straight line. In the log you'll see it as a diamond shape. One detail that surprises freshers is that you can force a merge commit even when a fast-forward would work, using the no-fast-forward flag, dash dash no dash f f. A lot of teams do that on main so every feature shows up as a clear, revertable block in the history. Without it, a fast-forward merge leaves no trace that the feature branch ever existed.