Task 2.1: Design and implement branching strategies for the source code

• ATrunk-based development with short-lived branches, and unfinished features merged but turned off with feature flags

  Correct

  Small daily merges keep conflicts small, and flags let incomplete features reach main without being visible.

• BLong-lived feature branches merged into main only when each feature is complete

  Incorrect

  That's the current model, which causes the merge conflicts.

• CA develop branch that collects all features, merged into main once a month

  Incorrect

  Monthly integration into main delays releases and still batches conflicts.

• DA personal fork for each developer, synced with main at the end of each sprint

  Incorrect

  Syncing once a sprint is no more frequent than today's feature branches.

Keeping branches short-lived and merging them often into main avoids the large merges of long-lived branches; feature flags let incomplete work be merged and kept hidden until it's ready, so main stays releasable.

• AA Limit merge types policy that allows only squash merge

  Correct

  Squash merge condenses a topic branch into one commit on main, and the policy blocks other merge types.

• BA Check for comment resolution policy set to Required

  Incorrect

  Comment resolution checks review comments, not how commits land.

• CA team agreement that authors rebase their branches before completing

  Incorrect

  An agreement isn't enforced, and rebasing keeps every commit.

• DA Minimum number of reviewers policy with reset of votes on push

  Incorrect

  Reviewer settings don't change the merge type.

Squash merging creates a single commit on the target branch with the file changes of the topic branch, keeping history clean. The Limit merge types branch policy controls which merge strategies are allowed when completing pull requests.

• ARemove the administrators from the repository and add them back with Write access

  Incorrect

  That takes away the admin role, which they must keep.

• BAdd a CODEOWNERS entry that names the administrators as owners of every file

  Incorrect

  Code owners request reviews; they don't stop admins from bypassing the rule.

• CRequire signed commits on main

  Incorrect

  Signed commits verify authorship; they don't force review or checks.

• DTurn on the protection setting that applies the rules to administrators as well

  Correct

  Administrator protection prevents bypassing the branch rules even by repository administrators.

GitHub branch protection rules can require pull requests, reviews and status checks, signed commits and linear history, and can be enforced for administrators so the rules can't be bypassed even by repository admins.

• ATurn on Allow completion even if some reviewers vote to wait or reject

  Incorrect

  That loosens the policy further.

• BRaise the minimum number of reviewers to two

  Incorrect

  Two approvals could still include the author's.

• CTurn on Reset all code reviewer votes on push

  Incorrect

  Resetting votes on push doesn't stop self-approval.

• DTurn off Allow requestors to approve their own changes

  Correct

  The author can still vote, but the vote no longer counts toward the minimum.

In the minimum number of reviewers policy, Allow requestors to approve their own changes lets the creator's vote count. When it's off, the creator can still vote Approve, but that vote doesn't count toward the required number.

• AImmediately, because the policy applies to every pull request

  Incorrect

  Draft pull requests don't trigger the pipeline.

• BOnly after the pull request is completed

  Incorrect

  Validation runs before completion, not after.

• CNever, because drafts skip all policies permanently

  Incorrect

  Policies apply once the pull request is no longer a draft.

• DOnly after the pull request is published as ready for review

  Correct

  Draft pull requests don't trigger a pipeline, even with a branch policy.

In Azure Repos Git, pull request validation comes from the target branch's build validation policy, and draft pull requests don't trigger a pipeline even when the policy is configured.

• A!/docs/*

  Incorrect

  An exclusion with nothing included before it specifies no files, so the build wouldn't run for code changes either.

• B/docs/*

  Incorrect

  This applies the policy only to changes under /docs, the opposite of what's needed.

• C/*;!/docs/*

  Correct

  It includes every file and then excludes /docs, so only pull requests that touch other files need the build.

• D!/docs/*;/*

  Incorrect

  Filters apply left to right, so the final /* includes /docs again and every pull request needs the build.

A build validation policy can carry a path filter, and the policy then applies only to files that match it. Paths prefixed with ! exclude files that an earlier path included, and the filters are applied left to right: an exclusion on its own matches nothing.

• ACopy the policies to each new branch by hand after it's created

  Incorrect

  Manual copying leaves new branches unprotected until someone remembers.

• BPut the policies on main only

  Incorrect

  Policies on main don't protect other branches.

• CConfigure the policies on a branch pattern such as release/*

  Correct

  Pattern-based protection applies to current and future branches that match.

• DLock each release branch when it's created

  Incorrect

  Locking blocks changes; it doesn't apply review and build policies.

Branch protection can use patterns, so the same policies apply to every current and future branch matching criteria such as release/*.

• ARequire linear history

  Incorrect

  Linear history prevents merge commits; it doesn't verify authors.

• BRequire signed commits

  Correct

  Signed commit enforcement verifies authorship cryptographically.

• CRequire status checks to pass

  Incorrect

  Status checks verify builds, not authorship.

• DAllow force pushes

  Incorrect

  That weakens protection.

GitHub branch protection can require signed commits, which verify the authorship and integrity of commits, and linear history, status checks and reviews.