A finished feature branch that adds Meraki SSID helpers should join the shared development line while keeping both histories visible. Which official Git operation is the correct way to combine the branch?
Select an answer to reveal the explanation.
Short Explanation
Merging is like connecting a side trail back to the main path and leaving the trail markers. When the feature is done, merge brings it into the shared line. Cherry-pick or squash are not the official DEVCOR 1.10.a answer here.
Full Explanation
Merging the feature branch into the shared development line—fast-forward if history is linear, otherwise a merge commit—is the correct official Git operation to combine a finished Meraki SSID-helpers branch while keeping both histories visible. Merge reconnects the side trail to the main path and preserves the branch’s commit story. That matches the requirement to join the shared line without discarding how the feature evolved.
Cherry-picking only the latest commit and discarding branch history as policy drops intermediate commits the team may need for blame, revert granularity, and review context. Squashing the branch into one commit as the only allowed answer may be a house style elsewhere, but it is not the official combine operation named here when both histories should remain visible. Deleting the remote feature branch without integrating its commits abandons the work instead of joining it to the shared line.
Exam caveat: team policies may still prefer squash merges for cleanliness—read the question’s visibility requirement; here histories should remain visible, which points to merge. Operational check: after merge, run git log on the shared branch and confirm the feature commits (or merge commit linking them) are reachable, then delete the remote feature branch only after that integration is verified.