Two engineers share a Python automation repo where both edited the SD-WAN inventory parser on separate branches and Git blocks the merge with conflict markers in the same function. The main branch must stay deployable and history must show the fix. Which branching and merging workflow resolves the merge conflict?
Select an answer to reveal the explanation.
Short Explanation
You can keep main deployable by updating your feature branch, resolving the parser conflict, and merging only after tests pass. That reviewed resolution also leaves the fix visible in history.
Full Explanation
Updating the feature branch from main first brings the latest base into the work being integrated. You then inspect the conflict markers and edit the parser function to preserve the intended logic, stage and commit the resolution, and merge into main only after tests pass. This records the fix in history and helps keep main deployable. Resolving and committing the conflict before merging without first updating from main may leave changes from the latest base unaccounted for or introduce further conflicts. Updating, resolving, committing, and merging without running tests skips the stated validation step and risks making main undeployable. Keeping the reviewed incoming implementation wholesale can be valid when that side is authoritative, but both engineers edited this function, so choosing one side may discard required logic from the other; the conflict must be resolved with the intended combined behavior. Exam caveat: a clean merge or passing CI alone does not prove that the intended behavior survived conflict resolution; review the result against both changes. Practical check: inspect the final parser function and its diff, confirm no conflict markers remain, run the relevant tests, and verify the merged commit is present on main.