Design and implement a source control strategy practice questions

A push to an existing branch.

Why wrong: For an existing branch push, both 'before' and 'after' are non-zero commit hashes because the ref already exists and is updated from a previous commit to a new commit, so an all-zero 'before' is not present.

A branch deletion.

Why wrong: A branch deletion is the opposite pattern: 'after' is all zeros because the ref is removed, while 'before' holds the last commit hash of the deleted branch, so it does not match the all-zero 'before' condition.

A pull request update.

Why wrong: Pull request updates are delivered as a separate webhook event type with a different payload structure (pullRequest and resource objects), not the push event's before/after ref fields, so they cannot indicate a new branch creation.

Squash commits before pushing to the remote.

Why wrong: Squashing combines multiple commits into one, but all file versions from the original commits remain in the object database until garbage collected; it does not actually delete historical blobs, so the repository size is not meaningfully reduced.

Perform shallow clones when cloning the repository.

Why wrong: A shallow clone limits local history depth, but the remote repository still holds all blobs and commits; it only reduces the local clone's size, not the size of the repository being shared or pushed to.

Regularly run 'git gc' to compress objects.

Why wrong: 'git gc' packs loose objects and prunes unreachable ones, but it does not drop blobs that are reachable from any commit; since all historical file versions are reachable, gc only compresses them and does not reduce the overall logical repository size.

Pass secrets as environment variables to actions.

Why wrong: GitHub Actions automatically injects secrets as environment variables only when you reference them via `${{ secrets.NAME }}` in the `env:` block; manually assigning a secret to an env var makes it visible to every step in the job, and any step can print it to the logs with `echo` or a malicious action. Plain env vars are not automatically redacted by GitHub, so values can leak in debug logs or custom output. The best practice is to reference secrets directly in the `env:` mapping using the secrets context, which triggers masking for the exact value and keeps the secret out of the workflow file.

Use environment secrets to restrict access to specific workflows.

Why wrong: GitHub Environments provide isolated secret stores tied to a deployable environment (e.g., production); a job can only access those secrets if it explicitly declares `environment: production`. You can attach protection rules like required reviewers or a custom deployment branch, so a workflow triggered from a non-approved branch or pull request cannot use production secrets. This granular scoping contains the impact of a compromised workflow because secrets for other environments remain inaccessible, and rotating one environment's secret does not affect others.

Store the same secret in multiple repositories for consistency.

Why wrong: Duplicating a secret across multiple repositories contradicts the principle of least privilege and creates credential sprawl: a leak in any one repository invalidates the same credential everywhere, and rotation requires finding every copy. Instead, use an organization-level secret and enable repository selection to share a single encrypted value with chosen repos, or centralize with an external vault through OIDC so workflows fetch ephemeral credentials. Manual duplication also obscures access history, making it impossible to audit which repo actually used the secret.

on: release: types: [published]

Why wrong: The `release` event with `types: [published]` triggers only when a GitHub Release is published, not when a tag is pushed. Since your goal is to automate on tag creation, this workflow would not run from a simple `git push --tags` unless a release is also manually published.

on: push: branches: ['v*']

Why wrong: The `push` event with `branches: ['v*']` filters branch names, not tag names; GitHub Actions does not apply the `branches` filter to tags. To trigger on tag creation, you must use `tags` on the `push` event or use the `create` event as shown.

on: workflow_dispatch: inputs: tag

Why wrong: The `workflow_dispatch` event enables a manual trigger via the GitHub UI or API, requiring a user to select the `tag` input each time. It does not automatically respond to tag creation, so it cannot fulfill the requirement for automated workflow execution on tag pushes.

Create a GitHub Actions workflow that runs a signature check after push

Why wrong: A GitHub Actions workflow triggered by a push event runs only after the commit has already been accepted onto the branch, so it cannot prevent unsigned commits from entering; it can only report or flag them post-hoc, which fails to enforce a pre-push policy.

Use a commit status check to verify signatures

Why wrong: Commit status checks are attached to commits after they are pushed and are primarily used for CI results; they do not execute before the push is received by GitHub, so they cannot block an unsigned commit from being added to a branch.

Repository rulesets

Why wrong: Repository rulesets in GitHub are a newer, flexible policy layer that can target branches, tags, or entire repositories, and they can enforce required status checks, merge restrictions, and even path-based requirements. However, for the precise scenario of blocking direct pushes to a specific branch while still allowing pull request merges, branch protection rules are the more targeted, conventional mechanism. Rulesets are broader in scope and introduce precedence semantics when combined with branch protection rules, making them less clear-cut for this simple branch-guard need.

CODEOWNERS file

Why wrong: CODEOWNERS only automatically assigns review requests to designated users or teams when a PR modifies matching files. It does not enforce any push restrictions or prevent contributors from pushing directly; it is purely a review-assignment mechanism, not an access control or branch policy.

GitHub Actions

Why wrong: GitHub Actions is a CI/CD and workflow automation system used to build, test, and deploy code, often triggered by pushes or pull requests. It cannot restrict direct pushes by itself; branch protection rules (or repository rulesets) are the mechanisms that enforce push permissions and required reviews.

Migrate from Git to Team Foundation Version Control (TFVC) for better performance

Why wrong: Migrating to TFVC would not reduce build times because the compiler still processes the full solution; it only changes the source control protocol used to fetch and commit files. Centralized version control requires developers to be continuously connected and often uses exclusive locks for binary files, making parallel branch work and offline development significantly harder for a global team. TFVC also scales poorly for large numbers of concurrent users and lacks the distributed collaboration features that Git-based Azure Repos provides.

Stay in a monorepo and use one pipeline with path filters to build only changed components

Why wrong: Path filters only gate which jobs or triggers execute; they do not reduce the actual compilation, testing, or packaging work for components that must be rebuilt because of shared dependencies. In a monorepo, a change to a common library still cascades to many downstream builds, and each pipeline run must check out and evaluate the entire repository. This approach adds YAML condition complexity without delivering the build isolation that independent repositories provide.

Keep the monorepo and disable continuous integration builds to reduce load

Why wrong: Disabling continuous integration does not make the build pipeline faster; the same compile, test, and package steps still execute whenever a developer manually triggers a build. It simply removes the automated feedback loop, so integration errors surface later and developers must wait for a manual queue instead of getting immediate results. Agent load may drop between manual runs, but build duration itself is not improved and the original bottleneck remains.

Configure the repository to use rebase when pulling

Why wrong: This is a Git client configuration option (`git config pull.rebase true`) that affects only a developer's local `git pull` behavior by replaying local commits on top of fetched commits. It does not alter any server-side PR completion policy or how Azure Repos integrates the source branch into a pull request. Even if every developer pulled with rebase, the PR completion merge strategy remains whatever the repository policy specifies, so the shared commit history is unchanged. Therefore, this setting has no effect on messy or low-quality PR commit messages.

Set the branch policy to require a clean fast-forward merge

Why wrong: Requiring a clean fast-forward merge through branch policy means the target branch ref is simply advanced to the source branch's final commit, with no merge commit being created. This enforces that the source branch is up to date with the target, but it does not rewrite, combine, or clean any of the commits coming in. Every original commit, with its original message, is preserved exactly in the target's history, so poor message quality remains fully intact. It is a topology constraint, not a history-quality tool, and therefore does not address the team's concern.

Use rebase merge when completing pull requests

Why wrong: Selecting 'Rebase merge' when completing a PR makes Azure Repos replay each source-branch commit onto the tip of the target branch, producing a linear history without an explicit merge commit. However, this strategy preserves all individual commits and their original messages, so WIP commits, fixups, and poorly worded messages survive unchanged. It aggregates nothing and edits nothing, which means the history may be linear yet still full of meaningless or repetitive entries. This is why rebase merge does not solve the problem of poor commit message quality.

Use the Azure DevOps Migration Tool to directly map TFVC permissions to Git repository permissions.

Why wrong: The Azure DevOps Migration Tool (and Azure Repos' native TFVC import) migrates version control artifacts such as changesets and files, but it does not convert TFVC's path-based ACLs into Git permissions. TFVC security is applied to hierarchical folders and branches via inherited access control lists, whereas Git in Azure Repos governs permissions at the repository and branch level through security groups and branch policies (e.g., requiring pull request reviewers). Since these permission models are structurally incompatible, any security or approval rules must be manually recreated in the new Git environment — the tool cannot 'map' them directly. Attempting to rely on it for permission migration would leave gaps in access control and policy enforcement.

Create a single Git repository with multiple branches that mirror the TFVC branch structure.

Why wrong: TFVC branches are path-based folders within the repository, while Git branches are lightweight pointers to commits; simply recreating TFVC folders as Git branches loses the folder structure and may create a confusing, non-standard layout. Instead, design a Git branching strategy (like feature branching or GitFlow) that fits your team.

Enable Git LFS in the new repository to handle large binary files from TFVC.

Why wrong: Git LFS (Large File Storage) is used to manage large binary files by storing them outside the Git repository, but it is not a tool for migrating from TFVC; it should be considered after the migration to optimize repository size, and enabling it prematurely does not aid in the historical conversion of TFVC data.

Feature branches have long lifetimes and are merged to main only after full feature completion.

Why wrong: Long-lived feature branches accumulate merge conflicts and delay integration, making the main branch unstable and hindering continuous delivery. Merging only after full completion also means the main branch is not always deployable, violating core CD principles.

Hotfixes are merged directly to develop and then cherry-picked to main.

Why wrong: This delays the hotfix deployment to production, as it must go through develop and may bypass the release process. Hotfixes should be based on the production version (main) for immediate deployment, not routed through develop first.

Set the main branch to require all merges to come from pull requests, and for develop, allow direct pushes.

Why wrong: Setting main to require PRs while allowing direct pushes to develop only addresses the merge point for main, not the gitflow requirement that hotfixes also merge into develop. Direct pushes to develop bypass review and let hotfix changes into main without a corresponding develop merge, breaking the branch strategy.

Use branch policies on main and develop that allow only certain source branches to merge, using branch naming conventions.

Why wrong: Branch policies on both main and develop can restrict which source branches are allowed to merge, using wildcard patterns such as feature/* for develop and release/* or hotfix/* for main. This enforces gitflow's naming conventions at the pull request level, ensuring that only branches created for the correct purpose can integrate into the integration and production branches.

Configure a global policy that requires all branches to have a minimum number of reviewers.

Why wrong: A global policy that requires a minimum number of reviewers on all branches is too coarse for gitflow because it applies equally to short-lived feature branches and critical main/develop branches. It fails to enforce source-branch restrictions, so it does not prevent a feature branch from merging directly into main, and it adds unnecessary overhead to every branch merge.

Require pull request reviews before merging, require status checks, and restrict who can push to matching branches.

Why wrong: This configuration requires a pull request review and at least one status check, and it restricts who can push to the protected branch. However, it omits the "require branches to be up-to-date" setting, which means a pull request can be merged even if its head branch is based on an outdated base. Without that requirement, the status checks that ran may have executed against an older commit, so integration failures or regressions introduced by later changes to the target branch could slip through undetected. Branch protection is only fully effective when the merge base is current and the checks reflect the exact final state of the code.

Require pull request reviews before merging, require branches to be up-to-date, and restrict push access to admins only.

Why wrong: This rule enforces pull request reviews and requires branches to be up-to-date, but it does not require any status checks. As a result, CI pipelines, tests, or policy checks are not a mandatory gate for merging—a branch could pass human review yet still have failing tests or no automated validation whatsoever. Moreover, restricting push access to "admins only" is a very narrow push restriction that does not mirror the standard "restrict who can push to matching branches" setting, which should grant access to a specific list of users/teams. Missing required status checks leaves the protected branch vulnerable to merging untested or broken code.

Require status checks, require branches to be up-to-date, and include administrators.

Why wrong: This option does require status checks and requires branches to be up-to-date, and it also includes administrators in the protection rules so that even admins cannot bypass those requirements. However, it fails to require pull request reviews before merging, which is a critical safeguard for a shared monorepo. Without that requirement, changes can be merged directly (or via a pull request with no reviewer approval) as long as the CI passes, eliminating the human code-review gate that catches logic errors, design issues, or policy violations. A complete branch protection policy must combine automated checks with mandatory human review.

Use release branches for each deployment and cherry-pick commits from main.

Why wrong: Release branches cherry-picked from main create divergent commit histories, because each release branch receives only selected commits while main continues to evolve, so the same fix is applied in different contexts and often needs re-application or conflict resolution when the release branch is eventually merged back. Duplicate patches and context-switching overhead arise since developers must remember which commits have been cherry-picked to each branch and track whether the version present on main matches the release. Moreover, even though release branches might seem short-lived, they remain long-lived in practice for each deployment horizon, and their simultaneous modification of shared files leads to merge conflicts that still require manual reconciliation with main, violating the continuous integration principle that everyone integrates frequently.

Use a single main branch and require all changes to be committed directly.

Why wrong: Requiring all changes to be committed directly to main eliminates review and isolation, making it easy for unvalidated work to break the build and forcing developers to resolve merge conflicts in a shared working directory with no branching safety net.

Use GitFlow with separate develop and release branches.

Why wrong: GitFlow's permanent develop and release branches are long-lived, cause substantial merge conflicts when syncing back, and introduce additional ceremony that slows down frequent integration, making it less suitable for teams aiming to reduce merge conflicts and adopt continuous delivery.

Perform a shallow clone of the last commit only.

Why wrong: A shallow clone with --depth 1 only retrieves the latest commit's tree and blobs, reducing local history, but it does not remove large binary files from that snapshot—those objects are still stored and transmitted. Thus, both the central repository size and the clone size remain large, and you lose the full history needed after a TFVC migration.

Use sparse checkout to exclude binary files from the working tree.

Why wrong: Sparse checkout only restricts which directories appear in the working tree; it does not change the objects stored in .git, and all blobs, including large binaries, are still downloaded during clone or fetch. Consequently, the repository size on the server and local disk remains unchanged, so it provides no relief from repository bloat.

Use TFVC to Git converter with default settings.

Why wrong: Default TFVC-to-Git converters (such as git-tfs or the Azure DevOps migration tool) convert the full history and check in every binary file as a regular blob, resulting in a large, unwieldy Git repository. They also fail to automatically integrate Git LFS, so you must explicitly configure LFS and retrofit the migration, making default settings an inefficient approach for repositories with significant binary content.

Add 'on: push: branch: [main]' to the workflow.

Why wrong: Using 'branch' (singular) is invalid YAML syntax for GitHub Actions; the correct key is 'branches' (plural), which expects a list of branch name patterns. With 'branch', GitHub will ignore the filter or the workflow may fail validation, so the workflow would not trigger as intended.

Add 'on: push: paths: [main]' to the workflow.

Why wrong: The 'paths' filter is used to trigger workflows based on file paths changed in the push, not on branch names. To restrict the workflow to a specific branch like 'main', you must use the 'branches' key under 'push', not 'paths'.

Add 'on: pull_request: branches: [main]' to the workflow.

Why wrong: The 'pull_request' trigger fires when pull request events occur (opened, synchronized, etc.), not when code is pushed to a branch. To run the workflow on pushes to 'main', you need to use the 'push' event with a 'branches' filter, not 'pull_request'.

git merge --squash feature/login

Why wrong: Squash merge creates a single commit but still a merge commit.

git cherry-pick f4e5d6c a7b8c9d

Why wrong: Cherry-pick is for individual commits, not the whole branch.

git merge --no-ff feature/login

Why wrong: Creates a merge commit, breaking linear history.

Require pull request reviews before merging.

Why wrong: Requiring pull request reviews enforces human code review but provides no cryptographic proof of commit authorship or content integrity. A reviewer may approve an unsigned commit, so this rule does not meet the requirement of verifying that every commit is signed.

Require status checks to pass before merging.

Why wrong: Requiring status checks to pass runs CI validation (builds, tests) but does not verify the authenticity or integrity of individual commits. An unsigned commit can pass all status checks, so this rule alone cannot enforce commit signing.

Require linear history.

Why wrong: Requiring linear history prevents merge commits by forcing a rebase-based workflow, which simplifies history but has no effect on cryptographic commit signing. Commits in a linear history can still be unsigned, so this rule does not enforce the stated requirement.

Enable 'Build validation' only.

Why wrong: Enabling only 'Build validation' ensures the branch has a successful build before merging, but it does not require any human code review. Without a reviewer requirement, changes can be merged without peer approval, leaving code quality unvetted.

Enable 'Require a minimum number of reviewers' only.

Why wrong: Enabling only 'Require a minimum number of reviewers' mandates a set number of approvals but does not enforce a successful build. This allows changes with compilation errors or test failures to be merged, so the branch is not protected against broken builds.

Enable 'Require a minimum number of reviewers' and 'Comment resolution'.

Why wrong: Enabling 'Require a minimum number of reviewers' and 'Comment resolution' ensures approvals and that review comments are addressed, but it omits 'Build validation'. Without a successful build check, code that fails to compile or breaks tests can still be merged, leaving the main branch vulnerable.

Use the GitHub API to push workflow files to each repository on a schedule.

Why wrong: Using the GitHub API to programmatically push workflow files to each repository on a schedule is not recommended because it introduces high maintenance overhead, requires secure credentials for every repo, and can silently fail or create drift between repositories. It also bypasses the native versioning and audit trail of Git, making it a fragile and non-standard solution for sharing workflows.

Download the workflows from a central blob storage and include them as inline scripts.

Why wrong: Downloading workflow files from central blob storage and including them as inline scripts is not a supported pattern for workflow reuse. GitHub Actions executes steps inside a repository checkout; fetching external blobs at runtime is not equivalent to a reusable workflow and cannot leverage native features like workflow-level inputs, concurrency, or proper logging, so it is both unmaintainable and incorrect.

Store the workflows in a separate repository and use Git submodules to include them.

Why wrong: Using Git submodules to include workflow files is not a valid reuse mechanism because GitHub Actions only discovers workflow files in the `.github/workflows` directory of the base repository, and submodules are not checked out by default unless explicitly configured. Even when configured, submodules are intended for code dependencies, not for sharing Action workflow definitions, and this approach does not integrate with the reusable workflow engine.

Add all team members as administrators of the repository.

Why wrong: Adding all team members as administrators grants full repository control, including the ability to disable or bypass branch protection rules, so they could push directly to main or override required reviews. This undermines the security you're trying to enforce on the main branch.

Remove write permissions for non-core team members and give them read-only access.

Why wrong: Removing write permissions and assigning read-only access prevents team members from creating branches or opening pull requests, which means they cannot contribute changes at all. The goal is to allow contributions through PRs while protecting main, not to block all write operations.

Set the repository to private and invite only core team members.

Why wrong: Setting the repository to private and inviting only core team members controls visibility and access, but it does not restrict what those members can do on the main branch. Core members typically have write or admin permissions, so they can still push directly to main unless a separate branch protection rule is configured.