- Which action most directly records that this file has been resolved?
Answer: Run git add for the edited file so its current content replaces the unmerged index entries.
When resolving a Git merge conflict, it helps to understand how Git's index works. The index (staging area) holds multiple versions of a conflicted file — one for each side of the merge — marked as "unmerged." Git considers the conflict resolved only when those unmerged entries are replaced by a single staged version. Simply editing the working-tree file doesn't touch the index at all, which is why git status still shows both modified even after you've removed the conflict markers.
The fix is A: running git add <file> tells Git to take your edited working-tree content and write it into the index as a single, normal entry, replacing the unmerged slots. That's the explicit signal Git needs to consider the conflict resolved. After this, git status will show the file as "staged for commit," and you can safely run git commit to finalize the merge.
B is wrong because git status is a read-only command — it reports state but never modifies the index. Re-running it will show the same both modified status indefinitely.
C is wrong because git commit does not automatically pick the working-tree version of an unmerged file. Git will actually refuse to commit while unresolved conflicts remain in the index, throwing an error about unmerged paths.
D is wrong because running git merge again doesn't replay the merge using your edited file; it would either error out or overwrite your manual work entirely.
A useful rule of thumb: in Git, editing a file changes the working tree, but only git add promotes that change into the index where it counts.
- The team decides to retain the value from
feature-timeout. Which edit correctly resolves this conflict? Answer: Replace the entire marked region with timeout=60, and then stage the file.
When Git encounters conflicting changes during a merge, it annotates the file with conflict markers to show you exactly what's in dispute. The <<<<<<< HEAD section shows your current branch's version, and the >>>>>>> feature-timeout section shows the incoming branch's version, separated by =======. Your job is to manually decide what the final file should look like, then remove all conflict markers and stage the file.
Since the team wants to keep feature-timeout's value, the correct resolution is to replace the entire marked block — from <<<<<<< through >>>>>>>, inclusive — with just timeout=60, then run git add application.properties to stage the resolved file. That's exactly what B does.
A is wrong because it keeps timeout=30, which is the HEAD (main branch) value — the opposite of what the team decided. Always match the resolution to the business decision, not the branch you're currently on.
C is a tempting trap: it sounds "fair" to keep both lines, but the result would be a properties file with two conflicting timeout assignments. Most parsers would use whichever appears last, and the intent is ambiguous — this is not a valid resolution.
D is the most dangerous option. Leaving conflict markers in the file means your application ships literal <<<<<<< text into its configuration, which will almost certainly cause a runtime or parse error. You must never stage a file that still contains conflict markers.
A reliable strategy: always search your codebase for <<<<<<< before committing — many teams even add a pre-commit hook to catch accidentally staged conflict markers.
- Which replacement for the entire conflicted region correctly resolves both the Git conflict and the stated Java behavior?
Answer: Use if (cache.contains(id)) return cache.get(id); followed by return repository.find(id);.
When you encounter a Git merge conflict in Java, you're actually facing two separate problems at once: resolving the conflict markers syntactically, and ensuring the resulting code implements the correct logic. Don't let the Git noise distract you from what the code actually needs to do.
The stated requirement is a classic cache-aside pattern: check the cache first, and fall back to the repository only when necessary. Answer A implements this correctly — if (cache.contains(id)) return cache.get(id); followed by return repository.find(id); — because the conditional ensures only one return executes per call, and the behavior matches the spec exactly.
Answer B is a Java compilation error in disguise. Once the first return statement executes, the second becomes unreachable code, and Java will refuse to compile it. Even if it compiled, you'd always return the cached value and never reach the repository.
Answer C reflects a misconception about how Git merge conflicts work. The "incoming" branch (feature-repository) has no special authority over the final result — Git is simply asking you to decide. Blindly keeping only the repository call ignores the caching requirement entirely.
Answer D makes the same mistake in reverse, falsely assuming HEAD "wins" during a merge. HEAD just means your current branch; it carries no precedence. Keeping only cache.get(id) abandons the repository fallback the feature branch was designed to add.
Study tip: Whenever you see a merge conflict question, mentally strip away the conflict markers and ask, "What does the business logic require?" Git resolution is about intention, not precedence.
- What should the relevant final content contain after a correct resolution?
Answer: host is "production", port is 9090, and mode is "strict".
When merging branches in Git, it helps to think of each file as a combination of independent changes made on separate branches. Your job is to understand which branch changed which line, and then apply conflict resolutions selectively — one conflict doesn't affect the others.
Here's the breakdown: the original file had host = "localhost", port = 8080, and mode = "safe". On main, only host and mode were touched — changing them to "production" and "strict". On feature, only port and mode were touched — changing them to 9090 and "fast". When you merge feature into main, Git automatically integrates non-conflicting changes: host stays "production" (from main), and port becomes 9090 (from feature) — no conflict there. The only conflict is mode, since both branches changed it from "safe". Resolving in favor of main means keeping "strict". That gives you C: host = "production", port = 9090, mode = "strict".
A is wrong because it keeps port at 8080, ignoring the clean, non-conflicting change from feature. B is wrong because it uses host = "localhost" (the original value, not main's change) and keeps mode = "fast" from feature, which contradicts the stated resolution decision. D is wrong for two reasons: it reverts host back to "localhost" and also loses the port update from feature.
A good strategy is to remember that conflict resolution only applies to the conflicting lines — all other changes from both branches are merged automatically. Don't accidentally discard clean changes when manually editing a conflict marker.
- Which sequence normally completes the interrupted merge while preserving the chosen resolution?
Answer: Edit the file, run git add on it, and then run git merge --continue.
When a Git merge halts due to a conflict, Git pauses and waits for you to manually resolve the dispute before it can finalize the merge commit. Understanding the required sequence — edit, stage, continue — is the key to answering this question correctly.
The correct sequence is A: you first edit the conflicted file to establish the desired content, then run git add on that file to mark the conflict as resolved (staging it tells Git "I've handled this"), and finally run git merge --continue to complete the merge and create the merge commit. This preserves your chosen resolution exactly as intended.
B is wrong because the order is backwards and the final command is destructive. Running git add before editing means you're staging the unresolved, conflict-marker-filled file, not your intended resolution. Worse, git merge --abort cancels the entire merge rather than completing it — throwing away all progress.
C is wrong because running git commit without first staging the resolved file skips a required step. Git won't know the conflict is resolved, and the unstaged changes won't be included in the commit. Staging after a commit makes no logical sense in this workflow.
D is wrong on both ends. git merge --continue doesn't open an interactive prompt for file editing — that's not how it works. And git reset --hard would discard all uncommitted changes, undoing your resolution entirely.
A useful memory trick: think Edit → Add → Continue as your conflict-resolution mantra. The staging step is the signal Git needs to know a conflict is settled before it proceeds.
- What will normally happen if the developer now attempts to complete the merge?
Answer: Git refuses to complete the merge because messages.properties remains unmerged in the index.
When working with Git merges, it helps to think of the index (staging area) as the gatekeeper. Git tracks merge conflicts through unmerged entries in the index — and it won't let you finalize a merge until every one of those entries is resolved and staged. Editing a file in your working directory is not enough; you must explicitly git add it to mark the conflict as resolved.
That's why C is correct. Even though the developer properly edited messages.properties, skipping git add means Git still sees it as an unmerged path in the index. When the developer runs git commit (or git merge --continue), Git inspects the index, finds the lingering unmerged entry, and refuses to proceed — typically printing an error like "You have unmerged paths."
A is wrong because editing a file changes only the working tree, not the index. Git has no way of knowing whether your edit actually resolved the conflict — that confirmation comes from staging the file with git add.
B is wrong because Git does not perform partial merge commits. A merge is atomic: either all conflicts are resolved and the merge commit is created, or nothing is committed. Git won't silently split the resolution across multiple commits.
D is wrong because Git doesn't silently choose a version on your behalf once a conflict is flagged. Automatic resolution happens before conflicts are surfaced; once a conflict is marked in the index, the developer must resolve it manually.
A useful mental model: **edit resolves the content, but git add resolves the conflict** in Git's eyes. Never confuse the two steps.
- Which command is the most appropriate additional check?
Answer: Run git diff --check to inspect changed lines for whitespace errors and leftover conflict markers.
When working with Git after resolving merge conflicts manually, you need to think carefully about which commands actually inspect file content versus those that simply report metadata or history. This question tests whether you know which Git command can actively scan changed lines for problematic content before you commit.
git diff --check is specifically designed for this scenario. It examines the diff of your working directory against the index, flagging both whitespace errors and leftover conflict markers like <<<<<<<, =======, and >>>>>>>. It's a lightweight safety net that warns you before you accidentally commit broken files — making D the correct answer.
Choice A is tempting but wrong. git status --short only shows the state of files (modified, untracked, staged) — it doesn't parse file contents or scan for specific text patterns like conflict markers. It has no awareness of what's inside a file.
Choice B is irrelevant to the task. git branch --merged lists branches that have already been merged into the current branch. It says nothing about file contents or conflict markers and has no inspection capability whatsoever.
Choice C is similarly off-base. git log --oneline displays abbreviated commit history. It can't validate working file contents against anything — it only shows past commit messages and hashes.
A useful study tip: on exam questions involving Git, pay attention to whether a command operates on file content versus metadata (history, branch status, staging state). Commands like git diff family operate on content; commands like git log, git status, and git branch operate on metadata.
- Which sequence appropriately resolves the conflict according to that decision?
Answer: Run git checkout --theirs -- Config.java, and then run git add Config.java.
When Git encounters a modify/delete conflict, it pauses the merge and asks you to manually decide the outcome. The key mental model here is understanding what --ours and --theirs mean during a merge: --ours refers to the branch you're on (main), and --theirs refers to the branch being merged in (feature). Since the developer wants to keep the modified file from feature, they need --theirs.
Option B is correct because git checkout --theirs -- Config.java restores the version of Config.java from the feature branch, placing it in the working directory. Running git add Config.java then stages it, telling Git the conflict is resolved and this file should be included in the merge commit. That's the complete, correct two-step resolution.
Option A goes in the opposite direction — --ours would retrieve main's version of the file, but main deleted it. This effectively retrieves nothing useful, and following it with git rm would just stage the deletion, which is the opposite of the intended outcome. Option C compounds the confusion by running git rm first (removing the file) and then trying to check out --ours, which again points to the deleted version on main — the file would still be gone. Option D is a trap: git add alone on an unresolved conflict file doesn't fully make sense, and git merge --abort cancels the entire merge rather than resolving it, discarding all progress.
A good rule of thumb: in a merge conflict, --theirs always means "the branch I'm pulling in." When you want to accept an incoming change, reach for --theirs, then git add to finalize the resolution.
- Which statement best describes what can happen next?
Answer: Git can create the commit because staging marks the path resolved, although the Java source may not compile.
When working with Git merges, it's essential to understand the separation between Git's staging mechanism and the actual file content. Git does not parse or validate what's inside a file — it only tracks whether a path has been explicitly staged after a conflict.
Once you run git add on a conflicted file, Git marks that path as resolved in the index, regardless of what the file contains. This means the commit can proceed normally. The danger, of course, is that if you accidentally left a conflict marker like <<<<<<< HEAD in the source, that literal text becomes part of your Java file. The Java compiler has no idea what that syntax means, so your code will likely fail to compile — but Git itself doesn't care.
D is correct for exactly this reason: staging signals resolution to Git, the commit succeeds, but the leftover marker corrupts the Java source.
A is wrong because Git does not scan file contents during staging to detect remaining markers. The git add command simply updates the index state — it does not re-inspect for unmerged markers after the fact.
B is wrong because Git has no mechanism to "restart" conflict resolution based on finding a marker in an already-staged file. Once staged, the conflict is considered resolved from Git's perspective.
C is wrong because Git never auto-edits file content during a commit. It would be dangerous and unexpected behavior for a version control system to silently modify your source files.
A useful rule of thumb: always open and search your resolved files for <<<<<<<, =======, and >>>>>>> before staging — your IDE or a simple grep can save you from a broken commit.
- Which command is designed for this situation?
Answer: Run git merge --abort to cancel the in-progress merge and restore the prior state.
When working with Git merges, it helps to think of the process as having a clear "emergency exit" — a way to undo everything if things go wrong before the merge is finalized. That's exactly what this question tests.
When you run git merge experiment and encounter conflicts, Git enters a special mid-merge state. Your working tree is modified, but no merge commit has been created yet. If your conflict resolution attempts make things worse, git merge --abort is designed precisely for this moment — it cancels the in-progress merge and restores your branch to the exact state it was in before you ran the merge command. This is option B, and it's the correct answer.
Option A is wrong because git merge --continue does the opposite of what the developer wants — it resumes a paused merge after you've resolved conflicts and staged the files, moving toward a merge commit, not away from one. Option C is wrong because git add . stages files for a commit; it doesn't discard edits or reconstruct anything — running it mid-conflict would actually make the situation harder to escape cleanly. Option D is wrong because git commit --amend modifies the most recent existing commit, but no merge commit exists yet in this scenario, so amending is irrelevant and potentially destructive to unrelated history.
A good memory anchor: think of --abort as the "undo the whole merge" flag and --continue as the "finish the merge" flag. On any exam question involving mid-merge recovery, if the developer wants to cancel rather than complete, --abort is your answer.
