AZ-400 Design and implement source control Practice Question
A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?
⚠ Common exam trap
It's easy for candidates to confuse 'squash commit' with 'rebase and fast-forward' because both can produce a linear history, but only squash commit collapses multiple commits into one.
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
✓
Squash commit
B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Rebase and fast-forward
Why it's wrong here
Rebase and fast-forward is incorrect because it rewrites the feature branch commits onto the tip of the target branch and then fast-forwards, resulting in a linear history that preserves each individual commit. Since all original commits remain intact, this approach does not combine changes into a single commit as required.
- ✓
Squash commit
Why this is correct
Squash commit is correct because it merges the feature branch by combining all of its changes into a single new commit on the target branch. This collapses the entire commit history of the feature into one commit, exactly matching the requirement to combine all changes into a single commit.
- ✗
Merge commit (no fast-forward)
Why it's wrong here
Merge commit (no fast-forward) is incorrect because it creates a new merge commit while preserving all the individual commits from both branches. This results in a non-linear history with the feature branch's commits intact, failing to consolidate them into a single commit.
- ✗
Semi-linear merge
Why it's wrong here
Semi-linear merge is incorrect because it first rebases the feature branch onto the target branch and then creates a merge commit, producing a linear history but keeping all original commits. Since the commits are not squashed, this approach does not meet the requirement to reduce the feature branch to a single commit.
Go deeper
Related to this question
Learn chapter
Source Control Strategy Design
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.