Merging Mechanics

Merging is where a branch stops being a private experiment and becomes part of the product. This module makes what Git does during a merge completely predictable.

Why This Module Matters

git merge has a reputation it does not deserve. Testers hear the word and picture something irreversible. In reality a merge is one of the most boring operations in Git: it finds the point where two lines of history split apart, and combines everything that happened on both sides since.

What surprises people is that Git has two different ways of doing it. Sometimes it just slides a label forward and nothing new is created — a fast-forward. Sometimes it writes a brand-new commit with two parents — a merge commit. Knowing which one you're about to get, and why, is the difference between a merge you understand and a merge you hope works.

There is also a habit in here that saves whole afternoons: pulling main into your test branch regularly, instead of discovering a week of drift at the worst possible moment.

What You'll Learn

• What git merge actually computes: the merge base, and the changes on each side
• The direction rule — you always merge into the branch you are standing on
• Fast-forward vs. merge commit: when each happens and how to force either one
• Refreshing your test branch from main so you're testing against current code
• Reading git log --graph --oneline and recognising a merge on sight

Pro Tip

Before any merge, run git status and git branch --show-current. Merging the right branch into the wrong one is by far the most common merge mistake, and it is entirely preventable in two seconds.