Merge Conflicts
git merge feature prints a conflict and stops. Two teammates changed the same line of config.json, and git refuses to guess which one wins, so it hands the disagreement back, written out in plain text on disk.
- ▸The merge combines everything the two sides did not both touch, and stops only where both rewrote the same or touching lines.
- ▸A stopped merge is bytes: labeled blocks in the file, three versions of the path, and a one-line open-merge flag.
- ▸Committing the resolved file writes the same two-parent commit a clean merge would; aborting discards the whole paused state.
Two teammates branched from the same config.json and both edited it. One changed the timeout to 30, the other to 60, on the same line. A third file, README.md, only one of them touched.
Run git merge feature and git does most of the work without asking. It walks the two versions region by region, comparing each against the shared starting point. README.md changed on one side only, so that side is taken whole. Every part of config.json the two did not both touch is combined the same way. The merge only halts where both sides changed the same lines, or lines right next to each other, because there git cannot tell how the two edits should sit together.
That halt is the entire subject. A stopped merge does not mean git broke or that the repository is damaged. It means the engine reached exactly one region it cannot decide, 30 or 60, and it refuses to pick for you. Everything decidable was already decided and written; what is left is the genuine disagreement.
The viz lets you place edits on each side across a few files, then runs the same region-by-region comparison and marks which lines merge silently and which stop. The rule is narrow, with one surprise: edits halt when they land on the same line or on touching lines, and one unchanged line between them is enough for git to take both.