During a merge conflict in the city's Meraki SSID helper repo, an engineer decides the entire conflicting file from the incoming branch is correct. Which resolution completes the merge cleanly?
Select an answer to reveal the explanation.
Short Explanation
When one side's whole file is the truth, check that path out from the winner, stage it, and complete the merge. You are still resolving a conflict—not inventing a new Git verb.
Full Explanation
When the entire conflicting file from the incoming branch is the intended result, the clean merge path is to check that path out from the chosen side (for example the merge --theirs / --ours semantics for that file), stage the resolved content, and complete the merge with a normal commit. That keeps Git’s merge machinery intact: conflict markers leave the index, the tree records a deliberate choice, and history shows a completed merge rather than an abandoned or force-rewritten state.
Cherry-picking only conflicting hunks onto main and abandoning the merge mid-flight leaves the repository in a conflicted merge state or forces a second, incomplete history rewrite; it does not finish the merge Git already started. Reset --hard on both branches does not invent a combined file—it discards working-tree and index state and can wipe both sides’ resolution work without producing a merge commit. Deleting the conflicted file and force-pushing without staging removes the path from the tree and rewrites remote history without ever recording a resolved merge of the two parents.
Exam caveat: “take theirs” or “take ours” for one path is still a conflict resolution step—you must stage and commit; checkout alone does not finish the merge. Operational check: after checkout of the winning path, run git status to confirm the file is staged and no unmerged paths remain, then complete the merge commit before pushing the Meraki SSID helper branch.