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?