git merge: bring the work home

Merging answers one question: bring the work from that branch into this one. The direction matters, and it trips up everyone at first. You stand on the branch you want the work to arrive in — almost always main — and you name the branch the work comes from. git merge feature, run from main, means: make main include everything feature did.

Run it backwards — standing on feature, merging main — and you get the opposite: feature absorbs main's work. The command is symmetrical; your position decides the direction. Check the star before you merge.

The easiest merge happens when the destination has not moved since the branch was created. main is exactly where feature left it, so there is nothing to combine — git simply slides main's label forward to feature's newest commit. Git tells you it did this by printing Fast-forward, along with the files that arrived.

It is called fast-forward because no new commit is created — the label just moves forward along the existing chain. The histories reconnect without ceremony, and the log looks like the branch work happened in a straight line.

Merging a branch whose work is already present gets you Already up to date. — not an error, just git confirming the destination already contains everything. You will see this constantly when you merge twice by accident or merge a branch you already merged.

When main and the branch both collected new commits, git can still usually merge automatically — it combines the two lines, file by file, taking both sides' changes. That combined photograph is called a merge commit, and git announces it with Merge made by the 'ort' strategy.

But if both sides changed the same lines of the same file, no machine can know which wording you meant. Git stops and asks for a human decision — a conflict. That moment is important enough to get its own course, which is exactly next.