Merge strategies overview in Git - Deep Dive

Overview - Merge strategies overview

What is it?

Merge strategies in Git are methods used to combine changes from different branches into one. They decide how Git integrates the histories and contents of branches when you merge them. Different strategies handle conflicts and histories in unique ways to suit various workflows. Understanding these helps keep your project history clear and your code stable.

Why it matters

Without merge strategies, combining changes from multiple people or features would be chaotic and error-prone. It would be hard to track what changed, when, and why. Merge strategies solve this by providing structured ways to integrate work, avoid conflicts, and maintain a clean project history. This makes teamwork smoother and reduces bugs caused by conflicting code.

Where it fits

Before learning merge strategies, you should understand basic Git concepts like branches, commits, and how to create and switch branches. After mastering merge strategies, you can explore advanced Git topics like rebasing, cherry-picking, and resolving complex conflicts. This knowledge fits into the broader journey of mastering version control and collaborative software development.

Mental Model

Core Idea

Merge strategies are the rules Git follows to combine different lines of work into a single, coherent history.

Think of it like...

Imagine two friends writing a story together on separate pages. Merge strategies are like different ways they decide to combine their pages into one book—whether by stacking pages, rewriting parts, or blending paragraphs carefully.

┌─────────────┐       ┌─────────────┐
│ Branch A    │       │ Branch B    │
│ (Feature 1) │       │ (Feature 2) │
└─────┬───────┘       └─────┬───────┘
      │                     │
      │                     │
      └───── Merge ─────────┘
             │
      ┌──────┴───────┐
      │ Merged Branch│
      └──────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Git branches basics

Concept: Learn what branches are and why they exist in Git.

Branches in Git are like separate paths where you can work on different features or fixes without affecting the main project. Each branch has its own history of changes. This lets multiple people work independently and safely.

Result

You can create, switch, and work on branches without disturbing others.

Knowing branches is essential because merge strategies only make sense when you have multiple branches to combine.

2

Foundation

What is merging in Git?

Concept: Merging means combining changes from one branch into another.

When you finish work on a branch, you often want to bring those changes back into the main branch. Git merges the histories and files from both branches. Sometimes this is automatic, sometimes you must fix conflicts.

Result

Your main branch now includes the new changes from the feature branch.

Understanding merging as combining histories helps you see why conflicts happen and why strategies matter.

3

Intermediate

Fast-forward merge explained

🤔Before reading on: do you think a fast-forward merge creates a new commit or just moves a pointer? Commit to your answer.

Concept: Fast-forward merge moves the branch pointer forward when no divergent changes exist.

If the branch you want to merge has all its commits ahead of the current branch, Git just moves the current branch pointer forward. No new commit is created. This keeps history linear and simple.

Result

The main branch pointer moves forward to include the feature commits without extra merge commits.

Knowing fast-forward merges helps you understand when Git keeps history clean and when it creates extra commits.

4

Intermediate

Recursive merge strategy basics

🤔Before reading on: do you think recursive merge can handle multiple merge bases or just one? Commit to your answer.

Concept: Recursive merge can handle complex histories with multiple common ancestors by merging them recursively.

When branches have diverged and have multiple common ancestors, Git uses the recursive strategy. It finds a virtual merge base by merging common ancestors first, then merges the branches. This helps resolve complex histories.

Result

A new merge commit is created combining changes from both branches with a clear history.

Understanding recursive merge explains how Git manages complicated branch histories and why merge commits appear.

5

Intermediate

Ours merge strategy overview

🤔Before reading on: do you think 'ours' strategy keeps changes from both branches or only one? Commit to your answer.

Concept: The 'ours' strategy keeps the current branch's content, ignoring the other branch's changes during merge.

When you want to record a merge but keep your current branch's content unchanged, you use 'ours'. Git creates a merge commit but discards changes from the other branch. Useful for ignoring unwanted changes.

Result

Merge commit is created, but the content stays exactly as the current branch had it.

Knowing 'ours' helps in special cases like ignoring experimental branches or resolving conflicts by choosing one side.

6

Advanced

Octopus merge for multiple branches

🤔Before reading on: do you think octopus merge can handle conflicts well or is it best for simple merges? Commit to your answer.

Concept: Octopus merge merges more than two branches at once but works best when no conflicts exist.

Git can merge multiple branches simultaneously using the octopus strategy. It creates one merge commit combining all branches. However, it cannot handle conflicts well, so it is used mainly for simple merges like integrating many topic branches.

Result

One merge commit includes all branches, but merge fails if conflicts occur.

Understanding octopus merge shows how Git can combine many branches quickly but with limits on conflict resolution.

7

Expert

When and why to avoid recursive merges

🤔Before reading on: do you think recursive merges always produce the cleanest history? Commit to your answer.

Concept: Recursive merges can create complex histories and large merge commits that are hard to understand or revert.

In large projects with many merges, recursive merges can produce tangled histories with many merge commits. Sometimes rebasing or squash merges create cleaner, easier-to-follow histories. Experts choose merge strategies based on project needs and history clarity.

Result

Choosing the right strategy improves project maintainability and developer understanding.

Knowing the tradeoffs of recursive merges helps experts maintain clean, understandable project histories.

Under the Hood

Git stores commits as snapshots linked by parent pointers. When merging, Git finds a common ancestor commit (merge base) and compares changes from both branches to that base. Depending on the strategy, it either moves pointers (fast-forward), creates a new commit combining changes (recursive), or applies special rules (ours, octopus). It uses a three-way merge algorithm to combine file changes and detect conflicts.

Why designed this way?

Git was designed to support distributed work with many branches and contributors. Merge strategies provide flexible ways to combine work while preserving history and minimizing conflicts. The recursive strategy was introduced to handle complex histories with multiple merge bases, improving accuracy. Alternatives like rebase exist but serve different workflows.

┌───────────────┐
│ Commit A      │
└──────┬────────┘
       │
┌──────┴────────┐
│ Merge Base    │
└──────┬────────┘
       │        ┌───────────────┐
       │        │ Commit B      │
       │        └───────────────┘
       │
┌──────┴────────┐
│ Commit C      │
└───────────────┘

Merge process:
1. Find merge base
2. Compare changes from base to each branch
3. Combine changes
4. Create new merge commit or move pointer

Myth Busters - 4 Common Misconceptions

Quick: Does a fast-forward merge create a new commit? Commit yes or no before reading on.

Common Belief: Fast-forward merges always create a new merge commit.

Reality: Fast-forward merges do not create new commits; they just move the branch pointer forward.

Why it matters: Believing this causes confusion about why some merges have no new commits and can lead to unnecessary merge commits.

Quick: Does the 'ours' merge strategy keep changes from both branches? Commit yes or no before reading on.

Common Belief: The 'ours' strategy merges changes from both branches equally.

Reality: 'Ours' keeps only the current branch's content, ignoring the other branch's changes.

Why it matters: Misusing 'ours' can cause loss of important changes and unexpected project states.

Quick: Can octopus merge handle conflicts well? Commit yes or no before reading on.

Common Belief: Octopus merge can resolve conflicts between multiple branches automatically.

Reality: Octopus merge fails if conflicts exist; it only works well with conflict-free merges.

Why it matters: Expecting conflict resolution leads to failed merges and wasted time troubleshooting.

Quick: Does recursive merge always produce the simplest history? Commit yes or no before reading on.

Common Belief: Recursive merges always create the cleanest and easiest-to-understand history.

Reality: Recursive merges can create complex histories with many merge commits that are hard to follow.

Why it matters: Assuming this can lead to messy project histories that confuse developers and complicate debugging.

Expert Zone

1

Recursive merges can create multiple merge commits when branches have been merged before, which can clutter history if not managed.

2

Fast-forward merges keep history linear but lose the context of a feature branch, which can be important for understanding development flow.

3

The 'ours' strategy is often used to mark a branch as merged without actually integrating its changes, useful in special workflows like ignoring experimental branches.

When NOT to use

Avoid recursive merges in projects that require a clean, linear history; use rebasing or squash merges instead. Do not use 'ours' when you need to preserve changes from both branches. Avoid octopus merges if conflicts are likely; merge branches pairwise instead.

Production Patterns

Teams often use fast-forward merges for small, linear changes to keep history clean. Recursive merges are common for integrating long-lived feature branches. 'Ours' is used in release branches to ignore hotfix branches that were merged elsewhere. Octopus merges are used in automated scripts to combine many topic branches quickly when conflicts are unlikely.

Connections

Conflict resolution

Builds-on

Understanding merge strategies helps you know when and why conflicts occur and how to resolve them effectively.

Rebasing

Alternative approach

Knowing merge strategies clarifies when to use merges versus rebasing to maintain project history and collaboration flow.

Collaborative writing

Similar pattern

Like merging branches, collaborative writing involves combining edits from multiple authors, requiring strategies to integrate changes smoothly.

Common Pitfalls

#1 Creating unnecessary merge commits with fast-forward merges.

Wrong approach:

git merge --no-ff feature-branch

Correct approach:

git merge feature-branch

Root cause:

Misunderstanding that fast-forward merges do not create merge commits and forcing them unnecessarily clutters history.

#2 Using 'ours' strategy expecting to combine changes from both branches.

Wrong approach:

git merge -s ours feature-branch

Correct approach:

git merge feature-branch

Root cause:

Confusing 'ours' as a normal merge strategy rather than a way to ignore changes from the other branch.

#3 Trying to octopus merge branches with conflicts.

Wrong approach:

git merge branch1 branch2 branch3

Correct approach:

git merge branch1
git merge branch2
git merge branch3

Root cause:

Not knowing octopus merge cannot handle conflicts leads to failed merges and wasted effort.

Key Takeaways

Merge strategies define how Git combines changes from different branches to maintain project history and code integrity.

Fast-forward merges move branch pointers without creating new commits, keeping history linear when possible.

Recursive merges handle complex histories by creating new merge commits that combine changes from diverged branches.

'Ours' strategy records a merge but keeps only the current branch's content, useful for ignoring changes.

Octopus merges combine multiple branches at once but only work well when no conflicts exist.