Let’s build a precise definition before diving into mechanics.

The Simple Definition

Merging is the process of combining the changes from one branch into another, producing a single unified history that contains the work from both. Most commonly, this means taking the finished work from a feature branch and folding it back into the main branch, so the rest of the team can benefit from it.

Why This Concept Exists

Branching lets multiple people (or multiple features) develop in complete isolation, which is fantastic for avoiding interference while work is in progress. But isolated work is only useful once it’s brought back together — a feature sitting forever on its own branch never reaches users. Merging is the deliberate, controlled step that reunites that isolated work with the rest of the project.

Every merge always involves exactly two roles, even if the underlying branches have many commits each.

graph LR
    A[Common Ancestor] --> B[Main branch continues]
    A --> C[Feature branch continues]
    B --> M[Merge Commit]
    C --> M
        

Understanding the “common ancestor” from Chapter 2 is the key to understanding everything Git does during a merge.

Not every merge produces a merge commit. Which type happens depends entirely on whether the branches actually diverged.

Fast-Forward Merge

If the target branch hasn’t received any new commits since the source branch split off from it, there’s nothing to actually combine — the source branch is simply “ahead.” In this case, Git can just slide the target branch’s pointer forward to match the source branch, in a straight line, with no new merge commit needed at all.

Three-Way Merge

If both branches have moved forward independently since they split — which is the far more common real-world case on an active team — Git must compare all three points (the common ancestor, plus each branch’s tip) to work out the combined result, and it records that combination as a proper merge commit with two parents.

graph TD
    subgraph "Fast-Forward"
    A1[main at C1] --> A2[feature adds C2, C3] --> A3[main pointer simply moves to C3]
    end
    subgraph "Three-Way"
    B1[main adds C4] 
    B2[feature adds C5]
    B1 --> B3[Merge Commit combines C4 and C5]
    B2 --> B3
    end
        

This is the single most intimidating part of merging for beginners, so let’s demystify it completely.

A merge conflict happens only when both branches changed the exact same lines of the exact same file in genuinely different ways since they split from their common ancestor. Git is very good at automatically combining changes that touch different areas, but it has no way of knowing which of two competing edits to the same spot is “correct” — that judgment call belongs to a human. When this happens, Git pauses the merge partway through, marks the conflicting section directly inside the affected file, and waits for you to decide how the final version should read.

Once you know what’s happening, resolving a conflict is a calm, mechanical process rather than a scary one.

Merging isn’t the only way to combine branches — rebasing is a common alternative worth understanding by contrast.

Neither approach is universally “better” — merging favors an honest, traceable record of exactly what happened, while rebasing favors a cleaner, easier-to-read straight-line history at the cost of rewriting the past. Many teams use merging for shared branches and reserve rebasing for tidying up their own private, not-yet-shared work.

Merging is the default, foundational way Git combines work, but it comes with its own set of considerations.

A short, practical checklist for keeping merges smooth and conflicts rare.

Merging sits at the center of nearly every collaborative software workflow in the industry today.

No. Merging only combines the history into the target branch — the source branch still exists afterward and can be deleted separately, purely for tidiness, once you no longer need it.

No — most merges complete automatically with no conflict at all, since Git only asks for help when both branches genuinely changed the exact same lines.

Yes, a completed merge can be reversed, though it’s generally cleaner to abandon an in-progress, unfinished merge before it’s committed rather than undoing one afterward.

Technically it’s the simplest possible case — since there’s nothing to combine, Git just moves the branch pointer forward, with no merge commit created.

Some teams prefer a perfectly linear history for readability and choose rebasing instead, but this trades away the honest record of exactly when and how branches diverged, which merging preserves.

Merging is how Git reunites separate lines of development into one shared history. By comparing each branch against their last common ancestor, Git can combine most changes automatically, and only pauses to ask for human judgment when both branches genuinely edited the same content in conflicting ways. Understanding the difference between a simple fast-forward and a true three-way merge — and knowing that a conflict is a normal, manageable event rather than an error — turns merging from an intimidating obstacle into a routine, predictable part of everyday development.