Integrating a Feature Branch While Keeping Main Branch History Linear
Network Topology
You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?
Quick Answer
Rebasing the feature branch onto main first (git rebase main feature/login), then merging with git merge --ff-only, is what actually enforces linear history: the rebase replays the feature commits cleanly on top of the latest main, and the fast-forward-only merge just moves the main pointer forward with no merge commit, refusing to proceed if a true fast-forward isn't possible.
⚠ Common exam trap
It's easy for candidates to confuse `--no-ff` (which preserves history but creates a merge commit) with the requirement for linear history, or they incorrectly think `git cherry-pick` is a valid way to integrate an entire feature branch.
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 rebase main feature/login then git merge --ff-only
The team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.
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 merge --squash feature/login
Why it's wrong here
Squash merge creates a single commit but still a merge commit.
- ✗
git cherry-pick f4e5d6c a7b8c9d
Why it's wrong here
Cherry-pick is for individual commits, not the whole branch.
- ✗
git merge --no-ff feature/login
Why it's wrong here
Creates a merge commit, breaking linear history.
- ✓
git rebase main feature/login then git merge --ff-only
Why this is correct
Rebase creates linear history; fast-forward merge preserves it.
Go deeper
Related to this question
Learn chapter
Designing and Implementing Instrumentation Strategy
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.
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.
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 →
Same concept, more angles
3 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE are valid Git merge strategies available in Azure Repos pull requests?
easy- ✓ A.Semi-linear merge
- ✓ B.Merge commit (no fast-forward)
- C.Fast-forward only
- ✓ D.Squash merge
- E.Rebase only
Why A: Among the given options, the valid merge strategies are: 'Merge commit (no fast-forward)' (Option B), 'Semi-linear merge' (Option A), and 'Squash merge' (Option D). 'Merge commit (no fast-forward)' preserves the full history of both branches. 'Semi-linear merge' rebases the source branch onto the target before creating a merge commit, ensuring linear history. 'Squash merge' combines all source branch commits into a single commit on the target. Note that Azure Repos also supports 'Rebase and fast-forward' as a valid merge strategy, but it is not among the options. Options C and E are not valid merge strategies in Azure Repos pull requests.
Variation 2. Your team uses Git with Azure Repos. You notice that the commit history on the main branch contains many merge commits and commit messages like 'fix merge conflict'. You want a linear history for better traceability. What should you change?
medium- A.Configure the repository to use rebase when pulling
- B.Set the branch policy to require a clean fast-forward merge
- C.Use rebase merge when completing pull requests
- ✓ D.Use squash merge when completing pull requests
Why D: Squash merge collapses all feature branch commits into a single commit on the main branch, eliminating merge commits and preserving a linear history. This directly addresses the problem of cluttered commit messages like 'fix merge conflict' by discarding intermediate commits and their messages. Squash merge is configured in the Azure Repos branch policy for pull request completion.
Variation 3. Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?
easy- ✓ A.Rebase merge
- B.Merge commit
- ✓ C.Squash merge
- D.Three-way merge
- E.Fast-forward merge
Why A: A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.
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.