Recap — Conflict Markers and Resolution Strategies

# Conflict Markers and Resolution Strategies Merge conflicts feel scary but they're routine. Understanding what they actually look like and the resolution flow makes it mechanical. ## When conflicts happen Both branches modified the SAME LINES of the same file differently since they diverged. ```bash git merge feature # Auto-merging app.py # CONFLICT (content): Merge conflict in app.py # Automatic merge failed; fix conflicts and then commit the result. ``` Git inserts markers into the conflicted file. ## The markers ```python def greeting(): >>>>>> feature ``` Three sections: - ` >>>>>> feature`: The INCOMING branch's version. You edit the file to resolve. The file ends up however you want it. ### Resolution options 1. **Keep yours (HEAD)**: delete the bottom half + markers. 2. **Keep theirs (feature)**: delete the top half + markers. 3. **Combine**: hand-craft the merged version using parts of each + your own additions. After editing, the file should be valid code (no leftover markers). ## The flow ```bash git merge feature # Conflict! # Edit conflicted files vim app.py # (or open in IDE) git add app.py # mark as resolved git status # check there are no more conflicts git commit # finalize the merge (or `git merge --continue`) ``` If you change your mind: ```bash git merge --abort # back out completely ``` ## Finding conflicted files ```bash git status # both modified: app.py # both modified: utils.py ``` These need resolution. Visit each, edit, `git add`. ## Three-way merge view (advanced) Git internally has THREE versions during a merge: - **Base**: the common ancestor. - **Ours** (HEAD): your branch's version. - **Theirs** (incoming): the branch you're merging. For a conflict, knowing base helps. Enable in your editor: ```bash git config --global merge.conflictstyle diff3 ``` Now markers show the base too: ```python >>>>>> feature ``` Useful: see how each side diverged from common ancestor; make better decisions. ## IDE integrations Most IDEs (VS Code, IntelliJ, etc.) have built-in merge tools: - VS Code: open the conflicted file; click "Accept Current/Incoming/Both Changes" inline buttons. - IntelliJ: side-by-side three-way merge view. These can save time vs hand-editing markers. ## Merge tool from CLI ```bash git mergetool ``` Opens a configured tool (vimdiff by default; can configure VS Code, etc.). ```bash git config --global merge.tool vscode git config --global mergetool.vscode.cmd 'code --wait $MERGED' ``` ## Resolution strategies (the "what to keep" question) ### Strategy 1: Take theirs entirely If you're merging a small fix into your branch and your local changes were experimental: ```bash git checkout --theirs -- file.txt # take incoming version git add file.txt ``` ### Strategy 2: Take yours entirely If you don't want to incorporate the incoming changes: ```bash git checkout --ours -- file.txt git add file.txt ``` ### Strategy 3: Merge manually (most common) Edit the file; combine logic from both sides. ### Strategy 4: Talk to the other developer Sometimes the right resolution requires understanding their intent. Slack them. Don't guess. ## Common conflict scenarios ### Renamed file modified by both Git tries to detect renames. If it succeeds: standard content conflict on the new name. If not: shows as add/delete pair — manual resolution required. ### Both branches added the same file with different content Conflict on creation. Resolve by editing the file (no markers; just two versions). Decide what to keep. ### Both branches deleted the file; one resurrected it Confusing. Use `git log --all -- file.txt` to see history. ### Binary files Markers don't work for binaries (images, PDFs). Git shows you both versions; choose one: ```bash git checkout --ours -- image.png # OR --theirs git add image.png ``` ## Preventing conflicts - **Pull often.** Don't let your branch drift far from main. - **Communicate.** If you're refactoring widely, tell others to avoid those files. - **Smaller PRs.** Less area; less chance of conflict. - **Squash before sharing.** Cleaner history; fewer rebase conflicts. ## After resolution Verify: ```bash git status # should be clean git diff --staged # see exactly what's being committed git commit # finalize ``` A merge commit's default message is: ``` Merge branch 'feature' into main # Conflicts: # app.py ``` Edit if you want; or commit as-is. ## Common conflict mistakes 1. **Forgetting to remove markers.** Code won't compile; tests fail. 2. **Resolving incorrectly under pressure.** Take a moment; re-read both sides. 3