🔀 Merging, Rebasing, and Conflict Resolution

Two Ways to Integrate

In the last lesson you spun off branches and did independent work. Integration is the reverse: folding one branch's changes into another. Git offers two fundamentally different tools for this.

💡 The one-sentence difference: Merging writes a new commit that ties two histories together and keeps the full record of what really happened. Rebasing lifts your commits off their old base and re-plays them on top of another branch, producing a tidy straight line — at the cost of rewriting history.

Neither is "better." They're tools with different trade-offs, and mature teams use both — often on the same feature. Let's take them one at a time.

Merging Fundamentals

Merging integrates the changes from one branch into another. Which kind of merge Git performs depends on how the branches relate.

Fast-forward merge

If the target branch has not moved since the feature branched off, there's no divergence to reconcile. Git simply slides the target pointer forward — no new commit needed. This is a fast-forward.

git switch main
git merge feature   # main just moves forward to C4

Three-way merge

If both branches gained commits since they split, Git can't just slide a pointer. It performs a three-way merge — comparing both tips against their common ancestor — and records the result in a new merge commit with two parents.

Commit C5 above is the merge commit; it's the visible record that these two lines of work were joined here.

Squash merge

A squash merge takes all the feature's changes and lands them as a single new commit on the target, discarding the feature's individual commits. Great for collapsing a noisy "WIP / fix typo / oops" history into one clean entry.

git switch main
git merge --squash feature
git commit -m "Add user profile page"   # --squash does NOT auto-commit

Handy merge options

Rebasing Fundamentals

Where merging joins two histories with a new commit, rebasing moves a branch to a new base. Conceptually Git: finds the common ancestor, saves each of your commits as a patch, resets your branch to the tip of the target, then re-applies those patches one by one as brand-new commits.

git switch feature
git rebase main   # replay feature's commits on top of main's tip

Rebasing shines for three jobs: keeping a long-running feature branch current with main, cleaning up messy local commits before you share them (with interactive rebase), and producing a linear history that some teams prefer.

Interactive rebase

The most powerful form. It opens an editor listing your commits so you can reorder, combine, or rewrite them:

git rebase -i HEAD~5   # curate the last 5 commits

pick   36d1535 Add login form
squash 7bc563a Style login form
squash 08e4e17 Add form validation
reword 2bc4f3c Fix validation bug
drop   0bec652 Debug console.log

# p, pick   = keep the commit
# r, reword = keep, but edit the message
# e, edit   = stop to amend the commit
# s, squash = meld into previous commit
# f, fixup  = like squash, but discard this message
# d, drop   = remove the commit

Interactive rebase is a time machine for your commits: use it to turn a scratch-pad of experimental commits into a clean, reviewable story before opening a pull request.

Merge vs. Rebase

When to merge

• Integrating a finished feature into a shared branch
• When the branch is already pushed and others may depend on it
• When you want an explicit record of when integration happened (GitFlow style)

When to rebase

• Updating your private feature branch with the latest main
• Cleaning up local commits before sharing them
• Keeping a linear history (Trunk-Based style)

git switch feature
git rebase main            # linear, up-to-date feature history
git switch main
git merge --no-ff feature  # one merge commit records the integration

Understanding Conflicts

A conflict happens when Git can't decide how to combine two changes automatically — almost always because the same lines of a file were edited differently on each side. Conflicts aren't errors or failures; they're Git asking a human to make a judgement call.

When a conflict occurs, Git rewrites the affected region of the file with markers showing both versions:

<<<<<<< HEAD
Users can log in with email
=======
Users can log in with username
>>>>>>> feature-branch

• <<<<<<< HEAD — start of your current branch's version
• ======= — divider between the two versions
• >>>>>>> feature-branch — end, and the name of the incoming branch

git status during a conflict tells you exactly where you stand:

$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   README.md

Resolving Conflicts

The process is always the same six steps:

1. Run git status to see which files conflict.
2. Open each conflicting file and find the marker blocks.
3. Decide the correct result — keep one side, combine both, or write something new.
4. Delete the <<<<<<<, =======, and >>>>>>> lines.
5. git add <file> to mark it resolved.
6. Finish: git commit for a merge, or git rebase --continue for a rebase.

Combining both changes

Often the right answer takes something from each side. Given the conflict from the previous section, a good resolution merges the intent:

Users can log in with email or username

Useful conflict commands

# Give up and go back to the pre-merge state
git merge --abort
git rebase --abort

# Take one whole side for a file, then mark resolved
git checkout --ours   path/to/file    # keep current branch's version
git checkout --theirs path/to/file    # keep the incoming version
git add path/to/file

# Launch a configured visual merge tool
git mergetool

Most editors help too. VS Code shows conflicts inline with one-click "Accept Current / Incoming / Both" buttons and a three-way merge editor, which is far easier than editing markers by hand for anything complex.

Preventing conflicts in the first place

• Integrate frequently — the longer branches diverge, the worse conflicts get.
• Keep changes small and focused so overlaps are rare.
• Communicate when you're editing shared files.
• Standardize formatting with tools like Prettier/ESLint so whitespace and style don't cause phantom conflicts.

Hands-on Exercise

mkdir conflict-demo && cd conflict-demo
git init -b main
echo "Welcome" > README.md
git add README.md && git commit -m "Add README"

git switch -c branch-a
echo "Welcome — installation guide" > README.md
git commit -am "Document installation"

git switch main
git switch -c branch-b
echo "Welcome — usage guide" > README.md
git commit -am "Document usage"

git switch main
git merge branch-a          # fast-forward, no conflict
git merge branch-b          # CONFLICT in README.md
# Edit README.md to the single line:
#   Welcome — installation and usage guide
git add README.md
git commit                  # completes the merge
git log --graph --oneline

Best Practices

Summary & Quiz

📚 Further Reading

• Atlassian — Merging vs. Rebasing
• Pro Git — Rebasing
• Pro Git — Advanced Merging
• Atlassian — Merge Conflicts

🚀 What's Next?

You can now integrate branches and resolve conflicts. Next we turn Git's complete history into a tool you can search, navigate, and — when necessary — safely rewrite and recover from.