Phase 1: Git for Real Work · ~40 minutes · git

Branching and Merging for Real Work

A merge conflict isn't Git breaking. It's Git correctly refusing to guess which of two real, competing edits you actually want.

Hiring signal: Reads a merge conflict as a normal, expected event with a clear resolution process, not a crisis

What you will learn

Explain a branch as a movable pointer, not a copy of the code
Explain a merge commit as a real commit with two parents
Resolve a real merge conflict by hand
Predict the resulting commit graph shape from two divergent branch histories

Introduction

Type: Learn Languages: Git Prerequisites: Lesson 01 (What Git Actually Tracks) Time: ~40 minutes

Objective

Learning objectives

Explain a branch as a movable pointer, not a copy of the code
Explain a merge commit as a real commit with two parents
Resolve a real merge conflict by hand
Predict the resulting commit graph shape from two divergent branch histories

What you're building

Using a fresh repository:

Create two branches from the same starting commit, each editing the same file in a way that genuinely conflicts (like this lesson's pricing.py example — both branches adding different content near the same lines)
Merge one into the other, triggering a real conflict — save the actual conflict markers Git inserts
Resolve it by hand (keeping both changes, if that's the sensible resolution) and complete the merge commit
Run git log --graph --oneline --all and save the real output showing the two-parent merge structure
Write one paragraph in merge_notes.txt explaining what specifically made this a conflict rather than an automatic merge (per this lesson's explanation of what Git's line-based merging can and can't decide on its own)

Branch A and Branch B both diverged from the same commit in a shared file. Branch A adds a new function at the very top of the file. Branch B adds a different new function at the very bottom, with several unchanged, unrelated functions in between. Will merging these two branches produce a conflict?

A conflict happens specifically when both branches change the same lines, or lines close enough together that Git's merge can't confidently treat them as separate edits — not merely 'the same file.' When the two additions are separated by real, unchanged content (this lesson's own resulting-graph example verified this directly: a function added at the top and a different one added at the bottom of the same file merged automatically, with no conflict at all), Git can identify them as two distinct, non-overlapping changes and combine both without asking a human anything. This lesson's pricing.py example conflicted specifically because both additions landed at the same point in the file, immediately adjacent to each other — proximity, not merely 'same file,' is what actually triggers a conflict.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.