The 'Design a source control strategy' domain of the AZ-400 exam is all about managing change without chaos. This concept is the bedrock of modern software development, and you need to understand its strategies to pass the exam and work effectively in a real team. It solves the fundamental problem of how multiple people can edit the same files at the same time without destroying each other's work.
Jump to a section
A simple way to picture Source Control Strategy Design
The lead architect on a major house renovation project. They are not the one hammering nails or laying pipes. Their job is to design the master plan that ensures every single tradesperson – the electrician, the plumber, the carpenter, the plasterer – works from the same, single, definitive set of blueprints.
Before this plan existed, the trades might work from scattered sketches on napkins or emailed photos. One morning, the plumber installs pipes based on a Tuesday email, while the carpenter builds a wall based on a Thursday phone call. The result? The wall goes up right where the pipe needs to run. Chaos.
This plan is the 'source of truth'. It is stored in a central digital folder that everyone can access but no one can secretly change. When a change is needed – say the homeowner wants a bigger window – the architect updates the master blueprint, creating a new, clearly labelled 'Version 2'. The old 'Version 1' plan is not deleted; it is archived. The plumber, who is working on the ground floor using Version 1, can finish their job without the electrician, who starts tomorrow, accidentally using Version 2’s new wall positions. This orchestration prevents costly rework and ensures every worker is coordinated, but only if everyone commits to using the official plan at the right time.
Source control, also known as version control, is a system that records changes to a file or set of files over time so that you can recall specific versions later. Imagine a word processor that saves every single revision you make, not just the final document. That is source control in a nutshell.
Why does it exist? Before source control, teams would share files over email or shared network drives. This led to the 'lost email' problem and the 'final_v3_reallyfinal.docx' nightmare. If two people made different changes to the same file, one person's work would silently overwrite the other's. Source control replaces this chaos with a structured, accountable history of changes.
Here is how it works. The core of a source control system is a repository (a central database of the project's files and their history). A developer clones (downloads) this repository to their local machine to work. They make changes, then perform a commit. A commit is like taking a snapshot of the current state of the files. It saves the changes to the local repository. Crucially, each commit has a unique ID and a message describing what was changed and why.
To share their work with the team, the developer performs a push, sending their commits to the central repository. To get their teammates' latest work, they perform a pull, downloading new commits from the central repository.
The most important design decision in source control strategy is the branching model. A branch is a separate line of development. The main branch, often called main or master, represents the official, stable version of the project. When a developer works on a new feature or a bug fix, they create a feature branch from the main branch. This isolates their work. They commit their changes to this feature branch without affecting the main branch. When the feature is complete and tested, they create a pull request (a request to merge their feature branch back into the main branch). A pull request is a collaboration tool: teammates review the code, discuss it, and approve it. Once approved, the feature branch is merged back into main.
This branching strategy enables several crucial things:
Isolation: One developer's experimental, broken code does not affect the stable version used by customers.
Parallel development: Multiple developers can work on different features simultaneously without interfering with each other.
Release management: The team can create a release branch from main at a specific point, then stabilise that branch for a production launch while other developers continue to add new features to main for the next release.
What does this replace? It replaces the manual, risky process of copying files and hoping for the best. It provides a complete, auditable history of every change: who changed what, when, and why. This is invaluable for debugging (you can find exactly when a bug was introduced), for compliance (you can prove what code was in production at a specific date), and for collaboration.
For the AZ-400 exam, you need to design a strategy that fits the team's workflow. Common models include:
GitHub Flow: A simple model with a single main branch and feature branches. Ideal for continuous deployment.
Git Flow: A more complex model with multiple long-lived branches (main, develop, release, hotfix). Suited for projects with scheduled releases.
Trunk-Based Development: Developers work on very short-lived feature branches (less than a day) and merge back into main (the 'trunk') frequently. This is a key practice for teams practising continuous integration.
1. Analyse the Team's Workflow
Before choosing any branching model, assess how the team ships software. Do they release once a month (scheduled), multiple times a day (continuous), or in hotfixes? This determines whether you need formal release branches (Git Flow) or simple feature branches (GitHub Flow).
2. Initialise the Repository and Create the Main Branch
Create the central repository in Azure Repos or GitHub. The main branch is the stable, production-ready version. Configure a branch policy immediately to prevent any direct pushes to main. This forces all changes to go through pull requests.
3. Define the Branching Strategy
Document the strategy: e.g., 'For every new feature, create a branch from main named feature/descriptive-name. Once finished, create a pull request. The team will use squash merges to keep history linear.' This ensures everyone agrees on the rules before work begins.
4. Set Up Branch Policies and Protections
In the repository settings, enable branch policies on main: require a minimum number of reviewers (e.g., 1), require a successful build from a CI pipeline, require linked work items, and enable comment resolution (all comments must be resolved). This enforces the rules without relying on memory.
5. Train the Team on Pull Request Etiquette
Run a session where everyone creates a sample pull request. Teach them how to write good descriptions, request specific reviewers, and use the 'Squash merge' button. Explain that the goal is to keep main clean and the history readable. Practice resolving a merge conflict together in a sandbox.
6. Implement a Release and Hotfix Workflow
For scheduled releases, create a release branch from main at the cut-off date. Only bug fixes go into this branch. For emergency hotfixes, create a hotfix branch from the production release tag. After the fix, merge back into both main and the current release branch. Document this to avoid confusion during incidents.
Consider a team of four developers at a small e-commerce company called 'ShopNow'. They are designing a source control strategy for a new shopping cart feature.
First, their senior developer, Priya, opens Azure Repos (a Microsoft source control service) and initialises a new repository for the project. She creates the initial main branch with the basic project skeleton. She then establishes a branch policy: no one can push directly to the main branch. Every change to main must come through a pull request with at least one reviewer’s approval.
Next, each developer works on a separate part of the feature:
Dev A (Alex) takes the 'Add to Cart' button. He creates a local branch called feature/add-to-cart-button. He writes code, commits locally, and pushes the branch to the central repository. He then creates a pull request to merge his branch into main. He tags Dev B as a reviewer because Dev B's work on the 'Cart Page' might conflict.
Dev B (Ben) takes the 'Shopping Cart Page'. He creates a branch called feature/cart-page. He discovers he needs a function to calculate tax that Alex has already written. Instead of rewriting it, he pulls the latest main branch, which does not yet have Alex’s branch merged, so he cannot see it. This is a sticking point.
The team holds a quick stand-up. Priya suggests that to avoid this problem, they should practise more frequent merges. Dev A gets his pull request approved and merged. Dev B then pulls the updated main branch, which now contains Alex's tax function. Ben can now use that function in his own code.
Dev C (Clara) is working on the 'Checkout' page. She is using a feature flag (a configuration toggle) to hide her unfinished work from customers. She creates a branch from main, adds her code behind the flag, and merges her branch back to main quickly. Her incomplete code is in main but switched off, so it does not affect anyone.
In this scenario, the real-world activities are:
Creating and enforcing branch policies in Azure Repos.
Managing pull requests with code review and work item links.
Resolving merge conflicts when two people edit the same line of the same file. (For instance, if Alex and Ben both edited the functions.js file at the same line, the system would flag a conflict that one developer must manually resolve).
Using feature flags to decouple deployment from release.
Setting up branch protection rules to prevent direct pushes to main.
Agreeing on a branching strategy that matches the team's release cadence (ShopNow ships weekly, so they adopt a simplified GitHub Flow).
This practical activity is what you will be tested on in the exam and what you will do daily in the job.
The AZ-400 exam focuses heavily on the 'why' behind source control decisions, not just the 'how'. You will not be asked to type git commit commands. Instead, you will be presented with scenarios and asked to choose the correct strategy, tool, or policy.
Questions typically fall into these patterns:
Scenario-Based Strategy Selection: 'A team ships software to production every 12 weeks. Which branching strategy is most appropriate?' The correct answer is likely Git Flow because it supports formal release branches and maintenance branches. The trap is choosing GitHub Flow (which assumes frequent, daily deployments) or Trunk-Based Development (which requires very high discipline and automation).
Tool Selection: 'You need to manage binary artifacts (like compiled libraries or Docker images) alongside your source code. Which Azure DevOps component should you use?' The answer is Azure Artifacts, not Azure Repos (which is for source code). The trap is confusing 'source control' with 'artifact management'.
Policy Enforcement: 'The team wants to ensure every code change is reviewed. What should you configure?' The answer is a branch policy on the main branch requiring a minimum number of reviewers. The trap might be 'require a successful build' which ensures code compiles but does not enforce human review.
Merge Type Selection: 'You want to preserve a clean, linear history. Which merge type should you use?' The answer is 'squash merge' (combines all feature branch commits into one single commit in main) or 'rebase and fast-forward'. The trap is a standard merge that creates a merge commit, which clutters the history.
Key concepts the exam loves to test:
Azure Repos vs. GitHub: You need to know both are options on Azure DevOps. The exam expects you to know the specific capabilities of each, like GitHub's built-in pull request templates and Azure Repos' integration with work items.
Branch Policies: Be crystal clear on what they can enforce: minimum number of reviewers, successful build, linked work items, comment resolution. The exam will present a scenario like 'enforce code review and ensure code compiles' – the answer is a branch policy requiring both a reviewer and a successful build.
Feature Flags: This is a major theme. The exam tests the concept of 'release' versus 'deploy'. You can deploy code to production while keeping it 'off' using a feature flag. This enables trunk-based development. Know the feature management tool in Azure: Azure App Configuration's feature management section.
Git Hooks: They may ask about automation triggers. A pre-commit hook can run linters before a commit is allowed. A post-receive hook can trigger a build. Know the difference.
Repository Structure: Repos vs. monorepos. A monorepo (single repository for all projects) vs. multiple repos. The exam tests the trade-offs (monorepo simplifies dependency management but can become large; multiple repos enforce modularity but complicate cross-project changes).
Common traps include: choosing GitFlow when the team deploys multiple times a day, or choosing multiple repos when the ask is about a single microservice. Always read the scenario carefully for the release cadence and team size.
The branching strategy you choose depends on your team's release cadence: use Git Flow for scheduled releases, GitHub Flow for continuous deployment, and trunk-based development for high-discipline, fast-moving teams.
A branch policy on the main branch that requires pull requests and code reviews is the single most effective way to maintain code quality and prevent bugs from reaching production.
Source control is not just about storing code; it is about recording a complete, auditable history of every change, including who made it, when, and why.
Feature flags decouple deployment from release, allowing you to deploy incomplete code to production while keeping it hidden from users until it is ready.
A well-written commit message explains the 'why' behind a change, not just the 'what', because the 'what' is visible in the code diff itself.
Merge conflicts occur when two developers edit the same line of the same file; resolving them requires manual intervention and communication between the developers involved.
Azure Repos and GitHub are both GitHub-based services on Azure DevOps, but Azure Repos offers deeper integration with work items and policies, while GitHub offers a broader open-source community and built-in CI/CD with GitHub Actions.
Squash merging combines all commits from a feature branch into a single commit on the main branch, keeping the history clean and linear.
These come up on the exam all the time. Here's how to tell them apart.
Git Flow
Uses multiple long-lived branches: main, develop, release, hotfix.
Designed for projects with scheduled, infrequent releases (e.g., monthly).
More complex to manage; requires merging between multiple branches.
GitHub Flow
Uses only one long-lived branch: main, with short-lived feature branches.
Designed for projects with continuous deployment (multiple deploys per day).
Simpler to manage; only requires merging feature branches back to main.
Merge Commit
Preserves the full history of all individual commits from the feature branch.
Creates a merge commit that shows the branch was merged.
History can be cluttered with many small, intermediate commits.
Squash Merge
Combines all commits from the feature branch into a single commit in main.
Does not create a merge commit; history is linear.
Cleaner, easier-to-read history, but loses the granularity of the feature branch's commits.
Single Repository (Monorepo)
All code for multiple projects lives in one repository.
Simplifies cross-project dependency management (one build pipeline).
Repository can become very large in size and history.
Multiple Repositories (Polyrepo)
Each project or microservice has its own repository.
Enforces strong modularity and independent versioning.
Makes cross-project changes harder; requires updates across multiple repos.
Mistake
Source control is only about storing your code in a cloud server like GitHub.
Correct
Source control is primarily about tracking changes and managing collaboration, not just storage. The cloud server is just one part. The real value is the history, branching, and merging capabilities.
Beginners equate 'cloud storage' (like Dropbox) with source control because both store files remotely. They miss the fundamental difference: source control manages versions and merges, while cloud storage only keeps the latest version.
Mistake
A single 'main' branch is always enough if you just commit directly to it.
Correct
Committing directly to main bypasses code review and can lead to broken code affecting everyone immediately. Branches provide isolation, allowing experimentation and parallel development without risk.
It feels simpler to just 'save to main'. Beginners fear the complexity of branching and merging. They do not realise that the cost of fixing a broken main branch when everyone is working on it is much higher than learning to branch.
Mistake
The main purpose of a commit message is to describe what you did, like 'Added button'.
Correct
The commit message should explain why you made the change, not just what you changed. The 'what' is visible in the code diff. The 'why' provides context for future developers. A better message is 'Add checkout button to fix missing payment flow on mobile'.
This comes from a focus on the present moment. Beginners think of the commit message as a personal note to themselves. They do not yet appreciate that code is read far more often than written, and the 'why' is what makes the history useful.
Mistake
Git is the same as GitHub or Azure Repos.
Correct
Git is the underlying version control software (the engine). GitHub and Azure Repos are web-based platforms that host Git repositories (the service). You can use Git locally without any platform.
Marketing and common speech conflate the tool with the platform. Beginners hear 'I use GitHub' and think that is the tool, not realising they are using Git via a GitHub interface. The exam tests the difference between Git commands and the platform features (like branch policies).
Mistake
Once you merge a branch back to main, you should delete the branch locally, but it is okay to leave it on the remote server.
Correct
You should delete the branch both locally and remotely once merged. Cleaning up remote branches prevents clutter in the repository and avoids confusion about which branches are active. Azure Repos and GitHub will prompt you to delete after a merged pull request.
Beginners think remote deletion is dangerous because they might need the branch again. They do not realise that the merged commits are permanently in main's history, so the branch name itself is unnecessary. Clutter is seen as harmless, but in large teams, it causes disorganisation.
Mistake
Pull requests are only for merging code.
Correct
Pull requests are a collaboration feature for code review, discussion, and automated checks. They provide a space to discuss the change, run CI pipelines, and check policies before merging. They are as much about communication as they are about merging.
The name 'pull request' sounds like a technical action (asking to pull code). Beginners see it as a mechanical step, not a social and process-oriented one. They skip the review process, thinking they just need to get code in.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A commit saves your changes to your local Git repository, like saving a file on your own computer. A push sends those committed changes from your local repository to the remote central repository (like Azure Repos or GitHub) so others can see them.
Use Git Flow if you handle scheduled releases (e.g., once a month) and need release branches and hotfix branches. Use GitHub Flow if you deploy to production multiple times a day and want a simpler workflow with just a main branch and short-lived feature branches.
A branch policy prevents developers from pushing changes directly to a protected branch (like main). It can require code review, a successful build, and linked work items, ensuring that every change is reviewed, tested, and traceable before it becomes part of the stable codebase.
A merge conflict happens when two branches have changed the same line of the same file. You must open the file in your editor, look for conflict markers (<<<<<<<, =======, >>>>>>>), choose which version to keep or write a new one, remove the markers, save, commit, and then complete the merge.
A .gitignore file tells Git which files or folders to ignore (not track in version control). You use it to exclude temporary files, local configuration files, build outputs (like .exe or .dll), and sensitive data like passwords, keeping your repository clean and secure.
Yes, it is safe and recommended. After a branch is merged into main, all its commits are part of main's history. Deleting the branch declutters the repository. If you need the exact state of the branch again, you can recreate it from the merge commit in main.
You've finished Source Control Strategy Design. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?