Git Merge Conflict Simulator
Resolve Git merge conflicts in a browser lab. Read the conflict markers and the three index stages, edit the file to what it should be, take a side with --ours or --theirs, see why they swap during a rebase, back out with git merge --abort, and catch a clean merge that breaks the build.
Category: DevOps
What You Will Learn
- Read Git conflict markers: <<<<<<< HEAD, ======= and >>>>>>>
- Inspect the base, ours and theirs versions with git show :1: :2: :3:
- Resolve a conflict by editing the file, then git add and git commit
- Use git checkout --ours and --theirs to take a whole side, for example for a binary file
- Understand why ours and theirs swap during a git rebase
- Back out of a bad merge with git merge --abort
- Catch a semantic conflict: a clean merge that breaks the tests
Topics covered: git, merge-conflict, version-control, rebase, terminal, devops, educational, interactive
// simulator
Git Merge Conflict Simulator
Resolve Git merge conflicts in a browser lab. Read the conflict markers and the three index stages, edit the file to what it should be, take a side with --ours or --theirs, see why they swap during a rebase, back out with git merge --abort, and catch a clean merge that breaks the build.
// CONFLICT (content)
Git Merge Conflict Simulator
Each lesson opens on a real-looking conflict. Read the markers, resolve the file, take a side, survive a rebase, back out with --abort, and catch the merge that Git called clean.
Branch
main
Unmerged
1
Staged
0
The merge stopped. Ask Git what state the repository is in.
Merging feature/retry into main
- HEAD
- main @ e41c9d2
- MERGE_HEAD
- feature/retry @ 9b27c40
- README.mdclean
- config.yamlboth modified
:1: base (common ancestor)
service: api timeout: 30 retries: 3
:2: ours: main (HEAD)
service: api timeout: 45 retries: 3
:3: theirs: feature/retry
service: api timeout: 60 retries: 3
During a merge (now)
--ours = the branch you are on
--theirs = the branch you are merging in
During a rebase
--ours = the rebased result so far: the branch you rebase onto, plus your commits already replayed
--theirs = your commit being replayed
About this merge conflict simulator
What you'll learn
- What the conflict markers delimit, and which side is which
- The index stages Git keeps for an unmerged file: up to three, base, ours and theirs
- That resolving means writing the file you want, not picking a side
- When taking a whole side is right, as with a binary file
- Why --ours and --theirs swap meaning during a rebase
- How to back out of a merge with git merge --abort
- Why a clean merge can still break the build
Key commands covered
- Inspect: git status, git diff, git show :1:/:2:/:3:<file>, git log --merge
- Resolve: edit the file, git add, git commit
- Take a side: git checkout --ours / --theirs, git checkout -m to start over
- Rebase: git rebase --continue, --abort
- Escape: git merge --abort
| During a | --ours / HEAD | --theirs |
|---|---|---|
| merge | the branch you are on | the branch you are merging in |
| rebase | the rebased result so far: the branch you rebase onto, plus your commits already replayed | the commit being replayed |
The conflict Git cannot see
Git merges text. When two branches change different lines that depend on each other, the merge can be textually clean while the combined code is broken. Run your tests on the merge result, not only on each branch: CI on merge commits, or a merge queue that tests the combined code before it lands.
Learn by breaking things
This simulator does not run real Git. It models each repository in the browser, with the output real Git prints, so you can make the mistakes here first. For the model behind branches and commits, try the Git Concepts Simulator, and read why Git is best learned by breaking something and getting it back.
Overview
A merge conflict is Git telling you that two branches changed the same lines and it will not guess which version to keep. This simulator puts you inside small repositories frozen at that moment and lets you resolve them with real commands. The engine keeps HEAD, the index and the working tree separately the way Git does, and its output follows what recent Git versions print. The lessons start with reading the conflict markers and the base version, then resolving by editing the file, then taking a whole side with git checkout --ours or --theirs. One lesson shows that during a rebase ours and theirs are swapped, because the branch you are rebasing onto becomes ours. Another shows the escape hatch, git merge --abort, which puts everything back as it was. The last lesson is the one Git cannot see: two branches that merge cleanly but break the code together, which is why a clean merge still needs tests. You leave knowing how to read git status during a conflict instead of panicking at it.
Try this
- Open "Read the conflict" and run git status to see which files are both modified.
- In "Resolve by editing", fix the file, then git add it and commit to finish the merge.
- Try "Rebase flips ours and theirs" and check which version git checkout --ours keeps during a rebase.
Frequently asked questions
- What do the conflict markers mean?
- The lines between <<<<<<< and ======= are your side (HEAD), the lines between ======= and >>>>>>> are the incoming side, and with diff3 style a ||||||| section shows the common ancestor.
- Why are ours and theirs reversed during a rebase?
- A rebase replays your commits on top of the other branch, so HEAD is the branch you are rebasing onto. That makes it ours, and your own commit becomes theirs.
- How do I cancel a merge with conflicts?
- Run git merge --abort, or git rebase --abort during a rebase. Git returns the branch to where it was before the operation; if you had uncommitted changes when the merge started, merge --abort may not be able to restore them, so commit or stash first.
Try next
// simulator
Preview Environment Simulator
See how a pull request becomes a temporary copy of your app, complete with a private URL, safe test data, review checks, and automatic cleanup.
// game
Heroku-Style Name Generator
Generate names the way Heroku, Docker, Kubernetes, and petname do, see how the word lists combine, and learn when the birthday problem makes random names collide.
// simulator
How Docker Works Under the Hood
Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.