Design and implement a source control strategy →hardMultiple ChoiceObjective-mapped

AZ-400 git revert Practice Question

Network Topology

You are debugging a recent issue introduced in the main branch. Based on the exhibit, which command would you run to revert the 'Fix login bug' commit while preserving the merge commit?

⚠ Common exam trap

The trap is that candidates assume `git revert HEAD` works for any commit, but reverting a merge commit requires the `-m` flag to specify which parent to keep. Without it, Git returns an error. Also, using `-m 2` would revert the wrong set of changes.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

git revert -m 1 HEAD

The 'Fix login bug' commit is a merge commit. To revert a merge commit while preserving its merge parent (i.e., the mainline), you must use `git revert -m 1 HEAD`. The `-m 1` flag specifies that the first parent (the main branch) should be kept, effectively reverting the changes brought by the merge. Option C, `git revert HEAD`, would fail because Git requires the `-m` flag when reverting a merge commit. Option B destroys history, which is not desired. Option D uses `-m 2`, which would revert the changes from the secondary parent (the feature branch), not the merge itself.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
git revert -m 1 HEAD
Why this is correct
git revert -m 1 HEAD is the correct approach because the -m 1 flag specifies the first parent (the mainline) as the baseline against which to reverse the changes brought in by the merge commit. This creates a new commit that undoes the merge's net effect on the main branch while preserving the original merge commit and the full branch history, making it a safe, non-destructive reversal for an already-integrated merge.
✗
git reset --hard HEAD~1
Why it's wrong here
git reset --hard HEAD~1 moves the branch pointer back one commit, completely discarding the merge commit and all changes introduced by the merged feature branch. This rewrites the main branch's history, which is dangerous if the merge was already pushed to a shared remote, as it creates divergence with remote and other collaborators' clones. The merge record is permanently lost, and any commits built on top of the merge may become orphaned, leading to confusing and potentially conflicting states.
✗
git revert HEAD
Why it's wrong here
git revert HEAD without the -m flag fails because Git cannot determine which parent of the merge commit should be treated as the mainline; it aborts with an error stating that reversing a merge requires a -m option. A merge commit has multiple parents, and the command must know whether to revert against the first parent (mainline) or the second parent (feature branch), so omitting -m leaves the operation ambiguous and impossible to execute.
✗
git revert c3a2b1e -m 2
Why it's wrong here
git revert c3a2b1e -m 2 instructs Git to reverse the merge using the second parent, which is the feature branch's commit, as the reference point. This does not undo the merge's effect on the mainline; instead, it attempts to revert the feature's changes from the feature branch's perspective, which can produce a commit that conflicts with or does not match the desired restoration of the main branch's pre-merge state. It mistakenly targets the wrong parent, so the resulting history is not the clean reversal needed.

Go deeper

AZ-400 git revert Practice Question

Why each option matters

Option-by-option breakdown

Related to this question