Implementing and managing source control. It is the single most important tool for any team writing code, because without it, you are managing chaos. For the AZ-400 exam, understanding source control is fundamental — every other topic about building, testing, and deploying software builds on this foundation.
Jump to a section
A simple way to picture Implementing and Managing Source Control
3 distinct versions of a single house plan exist: one on the architect's laptop, one the builder has marked up with pencil, and one the electrician sketched on a napkin. No one knows which is the real current plan.
This is exactly what happens with software code without source control. Instead of house blueprints, you have computer files called 'source code' — the instructions that tell software what to do. Source control is a single, master copy of those instructions stored in a central place, like a cloud service. Every change anyone makes is tracked. Think of it like a Google Doc for code: you can see who changed what, when, and why. You can even rewind to any previous version if a mistake is made.
For a renovation project, when the architect updates the master blueprint, the builder and electrician immediately see the latest version. Nobody works from an old, wrong copy. Similarly, in software, source control ensures every developer on a team works from the same, most up-to-date code. It prevents the chaos of multiple conflicting versions and provides a complete history of every change, which is essential when a new feature breaks something and you need to know exactly what changed.
Source control, also called version control, is a system that tracks and manages changes to files over time. Think of it as the ultimate 'undo' button for your entire project, but way more powerful. It keeps a complete history of every change ever made, who made it, when they made it, and why (they write a short message explaining their change).
Before source control existed, developers worked like people passing a single physical notebook back and forth. One person would take the notebook, make changes, and then physically hand it to the next person. If two people needed to work at the same time, someone had to wait. Worse, if someone lost the notebook or spilled coffee on it, the work was gone. Teams tried to avoid this by emailing files to each other, which led to chaos: 'final_v3_really_final_FINAL.doc' is a real problem.
Source control solves this by storing your project's files in a central repository (often called a 'repo'). A repository is simply a database that holds all your files and their history. When a developer wants to work on a file, they 'clone' (download) the entire repository to their own computer. They make their changes locally, then 'commit' those changes back to the repository. A commit is a snapshot of all the changes made at that point in time. Each commit gets a unique ID, like a receipt number, so you can always find it again.
There are two main types of source control: centralized and distributed. - Centralized version control systems (like Team Foundation Version Control, or TFVC) have a single 'master' server that holds all the files. Developers 'check out' a file to edit it, and no one else can edit it until they 'check it in'. This prevents conflicts but can be slow and creates a single point of failure — if the server goes down, nobody can work. - Distributed version control systems (like Git, which is used by Azure Repos and GitHub) are different. Every developer has a complete copy of the entire repository, including its full history, on their own computer. This means you can work offline, commit changes locally, and then synchronise with the central repository when you reconnect. Git is by far the most popular system today and is the focus of the AZ-400 exam.
Git works by taking a snapshot of your files at the moment you make a commit. If a file hasn't changed since the last commit, Git just links to the previous version to save space. This makes it incredibly fast and efficient. The core workflow in Git is:
You modify files in your 'working directory' (your local folder).
You 'stage' the changes you want to include in your next commit. Think of staging as putting files in a box before you send them.
You 'commit' the staged changes, which creates a new snapshot in your local repository.
You 'push' your commits to the central remote repository so others can see them.
Branches are a powerful feature of Git. A branch is essentially a separate line of development. Imagine a tree: the main trunk is the stable code everyone uses. You can create a branch (a new limb) to work on a new feature without affecting the stable trunk. When the feature is finished and tested, you 'merge' that branch back into the main trunk. This allows multiple people to work on different features simultaneously without stepping on each other's toes.
For team collaboration, pull requests (PRs) are key. A pull request is not a Git command; it is a feature of platforms like Azure Repos or GitHub. It is a formal way to propose changes from one branch to another. Team members can review the code, leave comments, and approve or reject the changes before they are merged. This is the standard way code quality is maintained in professional environments.
Azure DevOps, Microsoft's suite of tools that is central to the AZ-400 exam, includes Azure Repos, a service for hosting Git repositories. It also supports TFVC for legacy projects. Managing source control in Azure DevOps means setting up repositories, managing permissions, creating branch policies (rules like 'a pull request must have at least two reviewers before it can be merged'), and integrating with other Azure services like CI/CD pipelines.
In summary, source control replaces chaotic file-sharing with a structured, auditable, and collaborative system. It is not just about saving files; it is about managing the entire lifecycle of a software project’s codebase.
Create a Repository
This is the starting point. In Azure Repos, you create a repository (repo) to store all project files. You choose between Git or TFVC. For most new projects, select Git. This sets up the central storage location where the entire history of the project will live.
Clone the Repository
Each developer copies (clones) the remote repository from Azure Repos to their own local computer using 'git clone'. This creates a complete local copy of all files and the entire commit history. Now the developer can work offline if needed.
Create and Switch to a Feature Branch
Before making any changes, the developer creates a new branch (e.g., 'feature-add-search') from the main branch using 'git branch' and switches to it using 'git checkout'. This isolates the new work from the stable code, so experiments do not break anything for other team members.
Make Changes, Stage, and Commit
The developer edits files in their local working directory. They use 'git add' to stage specific changes (preparing them for a snapshot) and then 'git commit' to create a snapshot of the staged changes with a descriptive message. Multiple commits can be made on the feature branch.
Push the Branch to the Remote Repository
The developer uses 'git push' to upload their local commits and the feature branch to Azure Repos. This makes the changes visible to the team and backs them up to the remote server. Others can now see the work in progress.
Create and Complete a Pull Request
In the Azure Repos web interface, the developer creates a Pull Request (PR) to merge the feature branch into the main branch. The PR is assigned to one or more reviewers. They review the code, leave comments, and approve or request changes. Once approved and all branch policies pass (e.g., required reviewers, successful build), the PR is completed, merging the changes into the main branch.
An IT professional, typically called a DevOps engineer or a developer, uses source control every single day. Here is a concrete scenario of what that looks like in a realistic business context.
Imagine you work for a company called 'ShopSmart', which sells products online. The company has a team of five developers working on the website's main codebase, which is stored in a Git repository in Azure Repos. The main branch, called 'main' (or sometimes 'master'), contains the code that is currently live on the website, serving thousands of customers. Any change to the main branch must be handled carefully.
Step-by-step, here is what happens when a developer, Priya, needs to fix a bug where the checkout button on the website is not working:
Step 1: Priya opens her terminal or Git client (like Visual Studio Code) and creates a new branch from the main branch. She names it 'fix-checkout-button'. This branch is an isolated copy of the code that she can safely experiment on.
Step 2: She makes changes to the relevant files (for example, the checkout button's CSS and JavaScript code). She saves her changes locally.
Step 3: She stages the specific files she changed using 'git add' and then commits those changes with a message like 'Fixed checkout button issue where it was not responding to clicks'. This commit is saved to her local 'fix-checkout-button' branch.
Step 4: She pushes her branch and its commits to the remote repository in Azure Repos using 'git push origin fix-checkout-button'. This makes her changes visible to the team but does not affect the main branch.
Step 5: She goes to Azure Repos in her web browser and creates a Pull Request (PR) to merge her 'fix-checkout-button' branch into the 'main' branch. In the PR description, she explains what the bug was and how she fixed it. She also adds two other developers as reviewers.
Step 6: The reviewers get notifications. They look at the code changes, make comments, and ask for a small improvement. Priya makes the tweak, pushes another commit to the same branch, and the PR is updated automatically.
Step 7: The reviewers approve the PR. The company has a branch policy that requires at least one approval and that all automated tests pass. The CI/CD pipeline (a topic covered later in the exam) has already run tests against Priya's branch automatically. Since everything passes, the branch policy is satisfied.
Step 8: An authorised team member (or Priya herself, depending on permissions) clicks 'Complete merge'. The 'fix-checkout-button' branch is merged into the 'main' branch. The bug fix is now in the main codebase.
Step 9: The merge triggers a new build and deployment pipeline that automatically deploys the updated code to the production website. The bug is now fixed for customers.
The day-to-day work also involves managing permissions (who can push directly to the main branch versus who must use pull requests), cleaning up old branches after they are merged, and resolving merge conflicts (when two people change the same lines of code in different ways). The engineer also spends time configuring branch policies in Azure Repos, such as ensuring every PR has a linked work item from Azure Boards (the project management tool). These policies are critical for audit trails and quality control, which are heavily tested in the AZ-400 exam.
The AZ-400 exam tests 'Implementing and Managing Source Control' thoroughly. Here is exactly what you need to focus on to pass.
First, you must know the difference between Git and TFVC (Team Foundation Version Control). The exam will present scenarios and ask which system is appropriate. Git is distributed, allows offline work, and is the modern standard. TFVC is centralised, requires constant server connectivity, and is only used for legacy projects. If the scenario mentions a team working offline or needing a full local copy of history, the answer is Git. If it mentions locking files to prevent anyone else from editing them, the answer is TFVC.
Second, you need to understand the core Git workflow commands. You will get questions like 'Which command moves changes from the working directory to the staging area?' The answer is 'git add'. 'Which command records the changes in the local repository?' The answer is 'git commit'. 'Which command sends local commits to the remote repository?' The answer is 'git push'. 'Which command downloads changes from the remote repository to your local repository?' The answer is 'git pull'. Do not confuse 'pull' with 'fetch' — 'fetch' only downloads the data but does not merge it into your working files. 'Pull' does both.
Third, Azure Repos specific features are heavily tested. You need to know:
Repository types: Git (distributed) and TFVC (centralized).
Branch policies: rules applied to branches (especially the main branch). The exam loves questions about requiring a minimum number of reviewers for pull requests, requiring linked work items, and enforcing a successful build before merging.
Pull request workflows: who can create, approve, and complete a PR. Know the difference between 'complete' (merge) and 'abandon' (close without merging).
Forks: a copy of a repository that is not a branch. Forks are useful for open-source contributions where the contributor does not have write access to the original repo.
Fourth, common exam traps include: - 'Branching vs. forking': A branch is within the same repository. A fork is a separate copy of the entire repository. If a scenario involves an external contributor who is not on the team, the answer is usually 'fork'. If it involves an internal developer, the answer is 'branch'. - 'Merge vs. rebase': Both combine changes. Merge creates a new commit that ties two branches together. Rebase rewrites history by replaying changes on top of another branch. The exam expects you to know that rebase creates a linear history but should never be used on public branches because it rewrites history. Merge is safer for collaboration. - 'Git LFS (Large File Storage)': Git struggles with large binary files (videos, images, compiled DLLs). Git LFS replaces these files with text pointers in the repo and stores the actual large files on a remote server. The exam asks when to use it.
Fifth, be able to describe the role of '.gitignore' files. These tell Git which files or directories to ignore (e.g., temporary files, build outputs, local configuration files like appsettings.Development.json). The exam tests why you would exclude certain files.
Finally, understand the relationship between source control and the rest of Azure DevOps. Source control is the input for CI/CD pipelines. The exam will link them — for example, 'When a pull request is merged into main, what should happen automatically?' The answer is: trigger a build pipeline.
Memorise these exact concepts: TFVC vs Git, git add/commit/push/pull/fetch, branch policies, pull requests, forks, merge vs rebase, Git LFS, .gitignore, and the integration with Azure Pipelines.
Source control tracks every change to your code, who made it, and why, acting as a complete historical record and safety net.
Git is a distributed version control system, meaning every user has a full local copy of the repository and its history, enabling offline work.
Branches in Git are lightweight and allow multiple features or bug fixes to be developed in isolation before being merged back into the main codebase.
Pull requests are the standard mechanism for code review and quality control before merging changes into a protected branch like 'main'.
In Azure Repos, you can choose between Git (modern, distributed) and TFVC (legacy, centralized) based on your team's needs and workflows.
Branch policies in Azure Repos enforce rules such as requiring a minimum number of reviewers, passing automated builds, and linking work items before a pull request can be completed.
The .gitignore file is essential for preventing temporary files, build outputs, and sensitive configuration files from being tracked in source control.
Merge creates a new commit that preserves the branch history, while rebase rewrites history to create a linear timeline — use rebase with caution on shared branches.
These come up on the exam all the time. Here's how to tell them apart.
Git
Distributed: every user has a full local copy of the repository and its history.
Supports offline work: you can commit and branch without a network connection.
Branching is lightweight: creating a branch creates a pointer, not a copy of files.
TFVC (Team Foundation Version Control)
Centralised: one server holds the master copy; users check out files one at a time.
Requires constant network connection to perform most operations.
Branching is heavy: creating a branch often creates a server-side copy of the files.
Merge
Creates a new commit that has two parent commits, preserving the history of both branches.
Non-destructive: it does not alter existing commit history.
Best for collaboration because it clearly shows where branches diverged and came together.
Rebase
Rewrites history by moving commits from one branch to the tip of another, creating a linear timeline.
Destructive to local history: never use rebase on commits that others have already pulled.
Used to keep a clean, linear project history, but can cause problems with shared branches.
Branch
Exists within the same repository; no copy of the repo is made.
Anyone with read access to the repo can create a branch.
Used for feature work, bug fixes, and experiments within a team.
Fork
Creates a whole new copy of the repository under a different user's account.
Used when an external contributor does not have write access to the original repository.
Changes from a fork must be proposed via a pull request to the original repo.
Commit
Records a snapshot of your staged changes to your local repository.
Does not require an internet connection.
Creates a permanent (but not unchangeable) entry in the local history.
Push
Uploads commits from your local repository to a remote repository (e.g., Azure Repos).
Requires an internet connection.
Makes your commits visible to other team members.
Mistake
Source control is only for big software companies with large teams.
Correct
Source control is valuable even for a single developer working on a personal project. It provides automatic backups, a complete history of changes, and the ability to experiment with branches without fear of breaking things.
People think source control adds unnecessary overhead for small projects, but the time saved by having a safety net and a clear history easily outweighs the initial learning curve.
Mistake
Git and GitHub are the same thing.
Correct
Git is a version control tool that runs on your computer. GitHub (or Azure Repos) is a website that hosts Git repositories and adds collaborative features like pull requests and issue tracking.
The names are similar and beginners often use them together, so they conflate the tool with the platform.
Mistake
Once you commit a file, that version is permanently saved forever.
Correct
Commits in Git can be changed or deleted, especially if you have not pushed them to a remote repository. Even after pushing, a commit is not truly 'permanent' — it can be undone or rewritten using commands like 'git reset' or 'git rebase', though this is dangerous with shared branches.
New users believe Git's history is immutable like a blockchain, but Git explicitly allows history rewriting, which is a source of both power and confusion.
Mistake
A branch is a separate copy of the entire codebase stored on the server.
Correct
In Git, a branch is simply a lightweight pointer (a 'pointer' is a reference that points to a specific commit) to a particular commit. No files are copied when you create a branch; it just creates a new label. The actual files are stored as a directed acyclic graph of snapshots.
This misconception comes from how TFVC or other version control systems work, where creating a branch literally copies all files. Git's branching model is what makes it so fast and efficient, but it is counterintuitive.
Mistake
A pull request is a Git command.
Correct
A pull request (PR) is not a Git command. It is a feature of hosting platforms like Azure Repos, GitHub, or GitLab. The underlying Git command being used is 'git merge' or 'git rebase', but the PR process adds code review and approval workflows on top.
Beginners hear 'pull request' and assume it is related to the 'git pull' command. They are completely separate concepts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'git fetch' downloads new commits and branches from the remote repository to your local machine but does not merge them into your current working files. 'git pull' does both: it fetches the changes and then automatically merges them into your current branch.
Yes. If the file was previously committed to the repository, you can use 'git checkout' or 'git restore' to bring back the version from a previous commit. This is one of the main benefits of source control.
This causes a merge conflict. Git will tell you it cannot automatically merge the changes. You must manually open the conflicted file, decide which changes to keep (or combine them), and then commit the resolved version. Azure Repos has a built-in merge conflict editor to help.
No. You should add sensitive files like connection strings with passwords and local development settings to a '.gitignore' file. Instead, use secure mechanisms like Azure Key Vault or environment variables to manage secrets.
A branch is a separate line of development within the same repository. A fork is a complete copy of an entire repository, usually to a different user's account. Forks are typically used when an external contributor wants to contribute to a project they do not have write access to.
No. Git is a distributed system. You can commit changes, create branches, and view history completely offline. You only need an internet connection when you want to push your changes to a remote repository (like Azure Repos) or pull changes from it.
You've finished Implementing and Managing Source Control. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?