What's changed: Deepened AZ-400 Chapter 2 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
2.1Git and Branching Strategy
Understand source control foundations—Git (distributed VCS), branching strategies (trunk-based / GitHub Flow / GitFlow), feature branches, and merge vs rebase. Develop safely in parallel as a team.
Source control is the foundation of DevOps. Centered on Git, choose a branching strategy that fits the team for safe parallel development.
2.1.1Git and branching
- Trunk-based: integrate small and often to main; short-lived branches; great with CI/CD.
- GitHub Flow: main + short-lived feature branches + PRs; simple, fits continuous delivery.
- GitFlow: layered main/develop/feature/release/hotfix; for strict release management.
- Merge vs rebase: merge preserves history, rebase linearizes history.
Common on AZ-400: small frequent integration = trunk-based (fits CI/CD), simple main + PR = GitHub Flow, layered strict release = GitFlow, preserve history = merge, linearize = rebase. Long-lived branches cause merge hell; prefer short-lived branches with frequent integration.
Manage large binaries with Git LFS to avoid repo bloat. Choose mono-repo vs multi-repo based on team structure and dependencies.
AZ-400 probes the design skill to "pick a branching strategy fitting the team and delivery goals, aligned with CI/CD." Trunk-based development integrates small and often to main (the trunk), keeping branches short-lived (hours-to-days) to minimize merge conflicts and integration risk—the standard is to hide unfinished features behind feature flags while keeping the production branch always releasable, the best fit for CI/CD. GitHub Flow is a simple continuous-delivery model of main + short-lived feature branches + PRs. GitFlow is a layered model with develop/release/hotfix for products needing clear release cycles or multiple coexisting versions, but long-lived branches increase merge burden, so trunk-based is increasingly recommended. For history, distinguish merge (merge commit preserving branch history) from rebase (re-applying commits to linearize), and avoid rebasing shared branches since it rewrites history (squash-merging a PR into one commit is also common). Handle large binaries with Git LFS (pointer + separate storage), and choose mono-repo (easy integration/cross-cutting changes but needs scaling effort) vs multi-repo (independent/loosely coupled but cross-cutting changes are tedious) by team structure and dependencies. The key is a baseline of short-lived branches + frequent integration + PR review + CI, tuned to the product’s release requirements.
| Strategy | Traits | Best for |
|---|---|---|
| Trunk-based | Small frequent to main; short-lived; flags | High-frequency CI/CD; continuous deploy |
| GitHub Flow | Main + short branches + PRs | Simple continuous delivery |
| GitFlow | Layered develop/release/hotfix | Clear release cycles / multiple versions |
| Merge vs rebase | Preserve / linearize history | Audit-focus / clean history |
Scenario: A SaaS team wanting to deploy to production many times a day struggles with merge conflicts and integration delays. → Adopt trunk-based development, keeping branches short-lived (merged same day). Hide unfinished features behind feature flags so main stays always-releasable. Require build validation (CI) and reviews on PRs, and squash-merge to tidy history. Retire the long-lived develop branch (GitFlow) to eliminate integration lag.
FAQ: Merge or rebase? Merge is safe for shared branches (e.g., main), preserving branch history and auditability. Use rebase to update your own local, unshared feature branch for a linear history. The rule is "never rebase published history." Squash-merging a PR consolidates a feature’s small commits into one, keeping main’s history readable.
Exam trap: Choosing GitFlow’s long-lived develop/feature branches when you want high-frequency CI/CD is counterproductive—long-lived branches delay integration and cause merge hell. For high-frequency delivery, trunk-based (short-lived branches + flags) is correct. Also, rebasing a shared main to rewrite history is forbidden (it breaks others’ history).
2.1.2Section summary
- Strategy = trunk-based / GitHub Flow / GitFlow
- Integration = short-lived branches + frequent merge / history = merge vs rebase
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To maximize CI/CD, you want a short-lived-branch strategy integrating small and often to main. Which?
Q2. You want strict release management with layered branches (main/develop/release/hotfix). Which strategy?
Q3. When bringing a feature branch into main, you want a linear history. Which operation?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.