AZ-400 - Design and Implement Source Control
1. Git Fundamentals
Git is a distributed version control system where every developer has a full copy of the repository, including its complete history. This makes most operations local and fast. Understanding Git internals is essential for the AZ-400 exam.
Core Git Concepts
Repository Structure
A Git repository consists of three main areas: the Working Directory (your actual files), the Staging Area / Index (files prepared for the next commit), and the Repository / .git directory (the complete history). Commits are snapshots of your staging area identified by SHA-1 hashes. Each commit points to its parent commit(s), forming a directed acyclic graph (DAG).
Key Git Commands
git clone creates a local copy of a remote repository. git fetch downloads changes from remote without merging. git pull fetches and merges (or rebases with --rebase). git push uploads local commits to the remote. git stash temporarily saves uncommitted changes. git reset moves the branch pointer (soft/mixed/hard modes). git revert creates a new commit that undoes a previous commit.
Branching and Merging
Branches in Git are lightweight pointers to commits. Creating a branch is nearly instantaneous. Merging combines the work from two branches.
Merge vs Rebase
Merge creates a new merge commit that combines two branch histories, preserving the complete history. Rebase replays commits from one branch on top of another, creating a linear history. Use merge for shared/public branches (main, develop) and rebase for local feature branches before merging. Never rebase commits that have been pushed to a shared repository.
Cherry-Picking
Cherry-picking applies a specific commit from one branch to another without merging the entire branch. This is useful for applying hotfixes from a release branch to main, or selectively backporting features. The command git cherry-pick <commit-hash> creates a new commit with the same changes but a different hash.
2. Branching Strategies
Common Branching Models
Git Flow
Git Flow uses two permanent branches: main (production-ready code) and develop (integration branch). Supporting branches include feature/* (branched from develop), release/* (branched from develop for release preparation), and hotfix/* (branched from main for urgent fixes). Git Flow is well-suited for projects with scheduled release cycles.
GitHub Flow
GitHub Flow is a simpler model with only one permanent branch: main. Developers create feature branches from main, open pull requests for review, and merge back to main when approved. Deployments happen directly from main. This model is ideal for continuous delivery and web applications.
Trunk-Based Development
Trunk-based development emphasizes frequent integration to a single main branch (trunk). Developers work in short-lived feature branches (lasting hours to a few days) or commit directly to trunk using feature flags. This approach minimizes merge conflicts, supports continuous integration, and is recommended for mature DevOps teams.
3. Azure Repos
Azure Repos provides Git repositories (and TFVC) hosted in Azure DevOps. It integrates tightly with Azure Boards, Azure Pipelines, and Azure Test Plans.
Branch Policies
Configuring Branch Policies
Branch policies protect important branches by enforcing rules before changes can be merged. Key policies include: Require a minimum number of reviewers (set count and allow/disallow self-approval), Check for linked work items (ensure traceability), Check for comment resolution (all PR comments must be resolved), Limit merge types (allow only specific merge strategies like squash merge), and Build validation (require a successful build before merging).
Pull Request Workflow
Pull requests in Azure Repos support required reviewers, optional reviewers, auto-complete, draft PRs, and automatic linking to work items. Reviewers can approve, approve with suggestions, wait for author, or reject. The PR can include build validation policies that trigger a pipeline run on the proposed merge result.
Repository Security
Azure Repos permissions are managed at the repository and branch level. Key permissions include Contribute (push to repo), Create branch, Force push (rewrite history), Manage permissions, and Bypass policies when pushing. The latter should be restricted to break-glass scenarios only.
4. TFVC (Team Foundation Version Control)
TFVC vs Git
TFVC is a centralized version control system. Developers check out files, modify them, and check them back in. Only one developer can check out a file at a time (with exclusive locks). TFVC supports server workspaces (operations require server connectivity) and local workspaces (offline support with reconciliation). Git is recommended for new projects; TFVC is supported primarily for legacy codebases.
5. GitHub Integration
GitHub and Azure DevOps
Azure DevOps integrates with GitHub repositories for source control while using Azure Boards for work tracking and Azure Pipelines for CI/CD. The Azure Boards app for GitHub enables linking GitHub commits and PRs to Azure Boards work items using AB# syntax. Azure Pipelines can be configured to trigger on GitHub repository events (push, PR) using a GitHub service connection.
← Back to AZ-400 Preparation Topics