AZ-400: Git for Enterprise DevOps

1-git-enterprise-moc

Work with Git for Enterprise DevOps — MOC

MS Learn path: Work with Git for enterprise DevOps · Source control is the foundation of everything else.

The core idea

How teams collaborate safely on code at scale with Git: branching strategy, pull requests, code review, hooks, and collaborations at enterprise scale.

Planned concepts

git · Trunk/GitFlow · pull-request · merge-conflict · git-hooks · Azure Repos · GitHub · semantic-versioning

Planned modules

Modules in this path

Skills

Source control strategy, branching, PRs & reviews, repo hygiene.

Practice questions

get-started-with-git

Get started with Git

Learning objectives: understand what Git is, how version control works, and the core commands and workflow every developer uses.

Overview

The foundation module: what distributed version control is, why source control underpins the whole DevOps value stream, and how to move a project into Git.

Units

  • What is version control / Git
  • Core Git workflow (clone, add, commit, push)
  • Setting up a repository in Azure Repos or GitHub

Key terms & commands

clone · add · commit · push · pull · fetch · branch · checkout · remote · HEAD · working tree vs. staging

Hands-on

git init / git clone, make a change, stage, commit, push to a remote; inspect git status and git log.

Exam focus

Distributed vs. centralized; the add→commit→push cycle; every clone is a full history.

Path MOC · branching-strategies · pull-requests-and-code-review

branching-strategies

Branching strategies

Learning objectives: compare Git branching models, choose the right one for the release cadence, and keep branches short-lived to reduce conflicts.

Overview

How teams structure branches so the main line stays healthy and features flow to release predictably — the strategic layer above raw Git mechanics.

Units

  • Trunk-based development
  • GitFlow (feature/release/hotfix branches)
  • Choosing a strategy for your release cadence

Key terms & commands

trunk/main · feature branch · release/* · hotfix/* · fast-forward · merge · rebase

Hands-on

Create short-lived branches off main, merge frequently, and observe that conflicts grow as branches age.

Exam focus

Trunk-based ↔ continuous delivery; GitFlow ↔ planned versioned releases; short branches = fewer merge conflicts.

Path MOC · get-started-with-git · pull-requests-and-code-review

pull-requests-and-code-review

Pull requests and code review

Learning objectives: use pull requests to review and merge code safely, and enforce quality through branch policies and required checks.

Overview

The collaboration layer of Git: PRs bundle a diff, discussion, and approvals; branch policies turn “please review” into a mandatory gate protecting the main branch.

Units

  • Creating and reviewing pull requests
  • Branch policies (required reviewers, build validation, no direct push)
  • Merge strategies (merge, squash, rebase)

Key terms & commands

PR · reviewer · approval · branch policy · build validation · squash merge · rebase merge

Hands-on

Open a PR in Azure Repos or GitHub, add a reviewer, require a check to pass, and merge.

Exam focus

PRs are the code-review gate; branch policies enforce review automatically; squash keeps history clean.

Path MOC · get-started-with-git · branching-strategies

git

Git

What it is

Git is a distributed version control system (DVCS) and the de-facto source-control engine behind every major DevOps platform. Every developer has a full copy of the repository (the working tree plus the entire history), so they can commit, branch, and merge locally without a server.

Why it exists

Teams need to track every change to code, collaborate in parallel without overwriting each other, and roll back any point in history. Centralized VCS required a network round-trip for every operation; Git’s distributed model makes version control fast, resilient, and branch-friendly, which is what enables the pull-request workflow.

Key ideas

  • Commit — a snapshot of changes with a message; Git stores the whole project state, keyed by a SHA-1 hash of its contents.
  • Branch — a movable pointer to a commit, letting work proceed in parallel.
  • Repository (repo) — the .git folder holding all objects, refs, and configuration.
  • Remote — a shared copy (origin) that developers push to and fetch/pull from.
  • Working directory / staging area / HEAD — Git’s three-part model: edit, git add to stage, git commit to record.
  • Three states — modified, staged, committed.

Common workflow (memorize)

git clone → git checkout -b feature → edit → git add → git commit → git push → open a pull-request → merge to main.

Exam notes

  • Git is distributed, not centralized — every clone is a full backup.
  • A commit is content-addressed by its hash; history is a chain of commits.
  • git pull = fetch + merge (or --rebase).
  • Azure DevOps and GitHub both host Git repos; they share the same Git engine with different collaboration tooling on top.

branching-strategy · pull-request · merge-conflict · git-hooks · azure-repos · github

📘 Source: Microsoft Learn — Git

branching-strategy

Branching strategy

What it is

A branching strategy is the agreed convention a team uses to create, name, merge, and retire branches. It defines how long-lived or short-lived branches are, which branch is the source of truth, and how features flow into release.

Why it exists

Without a strategy, repositories devolve into a mess of conflicting branches, unmergeable work, and no clear “source of truth.” A strategy gives developers a repeatable path from feature to production while protecting the main line.

Key ideas

  • Main/trunk — the single source of truth that always reflects deployable state.
  • Short-lived feature branches — created from main, merged back quickly (trunk-based), keep merges small and conflicts rare.
  • Long-lived branches — develop, release/*, hotfix/* (GitFlow), increase merge overhead the longer they live.
  • Two dominant models:
    • Trunk-based development — everyone works on short branches off main and integrates continuously. Preferred for CD; fewer merge conflicts, faster feedback.
    • GitFlow — heavier model with main + develop + feature/release/hotfix branches. Suited to scheduled releases with versioning.

Exam notes

  • Trunk-based pairs with continuous delivery; GitFlow pairs with planned, versioned releases.
  • The longer a branch lives, the more likely it is to produce merge conflicts.
  • Choose a strategy that matches the release cadence, not dogma.
  • Protection rules (PR-required, branch policies) enforce the strategy at the platform level.

git · pull-request · merge-conflict · semantic-versioning

📘 Source: Microsoft Learn — Branching Strategy

pull-request

Pull request

What it is

A pull request (PR) is a formal proposal to merge a set of changes from one branch into another. It bundles the diff, a description, and a review conversation, and is the primary mechanism for code review before changes land on the main branch.

Why it exists

PRs make integration a deliberate, reviewed, and recorded step rather than an invisible push. They are the place where quality gates (human review, automated checks) are enforced before code enters the shared line.

Key ideas

  • Source branch → target branch — a PR is reviewed and merged into the target (usually main/develop).
  • Reviewers — teammates approve or request changes; required reviewers can be enforced by branch policies.
  • Automated checks — CI builds, tests, and static analysis run against the PR branch; a PR can be blocked until checks pass.
  • Merge options — merge commit, squash (collapse to one commit), rebase, or fast-forward.
  • Branch policies — e.g. “minimum 1 approval”, “no direct pushes to main”, “build validation required” — these turn PR review from convention into enforcement.

Exam notes

  • PRs are central to code review and to protecting the main branch from bad merges.
  • Branch policies + required reviewers + build validation = the enforcement layer for review.
  • Squash merging keeps history clean; it is a common enterprise default.
  • Same idea in GitHub (pull request) and Azure Repos (pull request); both support the same review workflow.

git · branching-strategy · merge-conflict · azure-repos · github

📘 Source: Microsoft Learn — Pull Request

merge-conflict

Merge conflict

What it is

A merge conflict occurs when Git cannot automatically combine changes from two branches because both modified the same lines of the same file (or one deleted a file the other edited). Git stops and asks a human to decide what the final content should be.

Why it exists

Git merges automatically by comparing the three versions involved — the common ancestor and the two branch tips. When the same line changed differently on each side, there is no unambiguous answer, so Git refuses to guess and surfaces the conflict for manual resolution.

Key ideas

  • How it looks — conflicted files contain <<<<<<<, =======, >>>>>>> markers showing the incoming vs. current content.
  • Resolution — edit the file to the correct content, git add it, then complete the merge (or rebase).
  • Fast-forward vs. true merge — a fast-forward has no conflict because there’s no divergent history.
  • Best practice — resolve quickly and keep branches short-lived; long branches multiply conflicts.

Exam notes

  • Conflicts happen only on convergent edits to the same lines; Git auto-merges everything else.
  • Resolution is a manual, human decision — this is why small, frequent merges (trunk-based) are favored.
  • Knowing how to resolve markers (<<<<<<< / ======= / >>>>>>>) and when to abort (git merge --abort) is a core skill.

git · branching-strategy · pull-request

📘 Source: Microsoft Learn — Merge Conflict

git-hooks

Git hooks

What it is

Git hooks are scripts Git runs automatically at defined points in the Git lifecycle — before a commit, before a push, after a merge, etc. They let you trigger custom actions without remembering to run them.

Why it exists

Hooks enforce consistent behavior (formatting, linting, secret scanning, test runs) at the point where developers naturally act, rather than relying on discipline. They catch problems early, at the developer’s machine (client-side) or on the server (server-side).

Key ideas

  • Client-side hooks — run locally in the working directory: pre-commit (before a commit is created), pre-push, post-commit, post-merge.
  • Server-side hooks — run on the shared host: pre-receive and post-receive run on the server when you push, letting the server reject a push (e.g. secret in a file, size limit, formatting check).
  • Common uses — linting/formatting, running unit tests, blocking secrets/credentials from being committed, generating files, enforcing commit-message conventions.
  • Tools like Husky (npm) and pre-commit (Python) make hooks easy to manage and share.

Exam notes

  • Hooks are environment-specific; client-side hooks live in each clone’s .git/hooks and are not shared by default.
  • Server-side pre-receive hooks can block a push to the remote.
  • In Azure Repos and GitHub, much of what hooks do is provided by branch policies and CI (build validation, required checks) — equivalent server-side enforcement without per-clone setup.

git · pull-request · azure-repos · github

📘 Source: Microsoft Learn — Git Hooks

azure-repos

Azure Repos

What it is

Azure Repos is the source-control service inside Azure DevOps. It hosts Git repositories (cloud-hosted or on-premises via an Azure DevOps Server) and also supports legacy Team Foundation Version Control (TFVC).

Why it exists

Azure Repos gives teams Microsoft’s Git hosting and collaboration tooling tightly integrated with the rest of Azure DevOps — Pipelines, Boards, and Test Plans — so source control, CI/CD, and work tracking live in one place.

Key ideas

  • Git hosting — full Git support with forks, tags, and unlimited private repos.
  • Pull requests & code review — built-in PR workflow with threaded comments.
  • Branch policies — enforce review and build validation on main (e.g. require approvals, prevent direct push, require linked work items).
  • Integration — one click from a PR/branch to a pipeline; links to Azure Boards work items.
  • Access & auth — governed by Azure DevOps organization permissions and PATs/service connections for automation.

Exam notes

  • Two systems: Git (recommended, modern) and TFVC (legacy centralized). AZ-400 focuses on Git.
  • Azure Repos is Azure DevOps’ answer to GitHub; both are Git hosts with branch policies and PR review.
  • Branch policies + build validation = the enterprise quality gate enforced at merge time.

git · github · pull-request · branching-strategy · azure-pipelines

Diagram

azure-repos - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: azure/devops/repos/get-started/what-is-repos

📘 Source: Microsoft Learn — Azure Repos

github

GitHub

What it is

GitHub is the largest Git-based hosting platform and collaboration service, with its own CI/CD engine (GitHub Actions), issue tracking, GitHub Projects-style planning, and a vast ecosystem. Azure DevOps connects to it natively for end-to-end pipelines.

Why it exists

GitHub provides Git hosting plus a rich collaboration surface (pull requests, code review, issues, Actions) at web scale. For AZ-400, GitHub is the non-Azure alternative to Azure Repos — a first-class Git host whose PR and branch-protection model mirrors Azure Repos.

Key ideas

  • Repositories & forks — public/private repos, forking for open collaboration.
  • Pull requests & code review — same PR concept as Azure Repos, with comments, approvals, and required checks.
  • Branch protection rules — require PRs, approvals, and passing status checks before merge.
  • GitHub Actions — event-driven CI/CD workflows in the repo (.github/workflows/*.yml), the GitHub counterpart to Azure Pipelines.
  • Integration with Azure — Azure DevOps / Azure Boards integrate with GitHub repos, and GitHub Actions can deploy to Azure.

Exam notes

  • PR + branch protection on GitHub ≈ PR + branch policies on Azure Repos.
  • GitHub Actions and Azure Pipelines are the two main CI engines in AZ-400; you should know when each fits.
  • Committing to GitHub directly on the default branch is typically blocked by branch protection; changes go through PRs.

git · azure-repos · pull-request · branching-strategy · git-hooks · github-actions

📘 Source: Microsoft Learn — Github

semantic-versioning

Semantic versioning

What it is

Semantic versioning (SemVer) is a convention for version numbers of the form MAJOR.MINOR.PATCH (e.g. 2.3.1). Each segment communicates how backward-compatible a change is, so consumers can safely decide when to upgrade.

Why it exists

Without a versioning contract, it’s impossible to tell whether a new release breaks you. SemVer makes compatibility machine-readable — tools and developers can rely on the number to know whether an update is safe (patch), adds features (minor), or may break the API (major).

Key ideas

  • MAJOR — incompatible, breaking API change. Bump when consumers must change code.
  • MINOR — backward-compatible new functionality. Bump when you add features.
  • PATCH — backward-compatible bug fixes. Bump when you only fix issues.
  • Pre-release & metadata — 1.0.0-beta.1, 2.3.1+build.5 for unreleased builds and build metadata.
  • Common practice — tags map to versions (v1.2.3), packages use SemVer in Azure Artifacts/NuGet/npm, and dependency ranges express “compatible with” via ^/~.

Exam notes

  • Memorize: breaking = MAJOR, new feature = MINOR, fix = PATCH.
  • SemVer lets dependency management declare compatible ranges and tells CD pipelines when to cut a release.
  • Version tags (e.g. v2.3.1) are used to mark releases in Git history.

git · branching-strategy · azure-artifacts

📘 Source: Microsoft Learn — Semantic Versioning