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:
mainpoints at commitc1.featurehas one new commit on top ofc1, call itc2.mainhasn'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.