Course contents

Fast-forward merge

Sign in to run this lab and save your progress

Learn

You've built something on a feature branch. Now you want that work in main. That's called merging.

This lesson covers the simplest kind of merge, the one Git can do without you thinking about it. Later lessons will cover the harder kinds.

Fast-forward: the trivial case

Picture the current state:

  • main points at commit c1.
  • feature has one new commit on top of c1, call it c2.
  • main hasn't moved since you branched.

Since c1 is a direct ancestor of c2, "merging feature into main" doesn't actually require combining anything. Git can just slide main's pointer forward from c1 to c2, and the two branches are back in sync.

That slide is called a fast-forward merge. It's the fastest possible kind of merge because Git literally just updates one pointer. No new commit, no history change, no chance of a conflict.

The command

git switch main
git merge feature

git merge <branch> means: "take the commits from <branch> and bring them into the branch I'm currently on." Git looks at the shape of history, sees that a fast-forward is possible, and does it:

Updating 0633b47..a1b2c3d
Fast-forward
 feature.txt | 1 +
 1 file changed, 1 insertion(+)

Now main and feature both point at the same commit again.

When it's NOT a fast-forward

If main has also gained commits since the branch split, the two sides have diverged. There's no straight line for Git to slide along, so it has to actually combine the two branches into a new "merge commit". That's a real merge, and it's covered in the next module.

For now, remember the rule: fast-forward is possible when the target branch hasn't moved. If main has been quiet while you were on feature, merging back is trivial. If main has been busy, you'll have real merging work to do.

Forcing a merge commit even when you don't need one

Some teams like history to show "these commits came from a branch", even when a fast-forward would have worked. The flag is:

git merge --no-ff feature

This creates a merge commit instead of doing the pointer slide. The commits from feature are still there, but there's an extra commit joining them into main, which some people find easier to read in git log --graph later. Neither approach is wrong; it's a team style choice.

Cleaning up

Once a feature branch has been merged, it usually has no purpose anymore. To delete the branch label (the commits stay):

git branch -d feature

The -d (delete) refuses to delete a branch that hasn't been merged, which is a helpful safety check. -D forces deletion, which is what you'd use for an abandoned experiment. Reach for -d and let Git stop you if you're wrong.

Your task

You're on main. There's a feature branch that's one commit ahead of main (and main itself hasn't moved since the branch was created). Bring the feature commit into main. Because main hasn't diverged, git can just move main's pointer forward without creating a new merge commit — this is a fast-forward. After this, both main and feature should point at the same commit.