Practical Exercise: Simulate a Full Git Flow Release Cycle With a Team of 3
This capstone exercise brings together this module's entire content — Git Flow's branch model, Semantic Versioning, Conventional Commits, CHANGELOG.md, and branch protection — into one realistic, complete simulation: a full release cycle, played out solo but taking on three distinct developer roles in sequence, including a feature, a formal release, and an urgent hotfix.
Learning Objectives
- Set up a repository following Git Flow's main/develop branch structure.
- Simulate two developers completing separate features using Conventional Commits.
- Simulate a release manager preparing, tagging, and shipping a formal release with a changelog.
- Simulate an urgent hotfix, correctly reaching both main and develop.
Key Terms to Know Before This Git Flow Release Cycle Exercise
- Simulated team role: Playing the part of a specific team member (e.g., 'Developer A', 'Release Manager') to practice a complete, realistic multi-person workflow solo.
- Complete release cycle: The full sequence from individual feature development through a batched release to eventual hotfix handling, exercising every branch type in a strategy.
- Role-appropriate commit: A commit whose message and content reflect what that specific simulated role would realistically be doing at that point in the cycle.
How to Simulate a Complete Git Flow Release Cycle, Step by Step
**Setup: Initialize the repository with Git Flow's structure.**
```
mkdir git-flow-exercise && cd git-flow-exercise
git init
echo "# Project" > README.md
git add README.md
git commit -m "chore: initial commit"
git switch -c develop
```
**Role 1 — 'Developer A': builds a feature, using Conventional Commits.**
```
git switch -c feature/dark-mode
echo "// dark mode toggle" > darkmode.js
git add darkmode.js
git commit -m "feat(ui): add dark mode toggle"
git switch develop
git merge feature/dark-mode
git branch -d feature/dark-mode
```
**Role 2 — 'Developer B': builds a second, independent feature.**
```
git switch -c feature/export-csv
echo "// csv export logic" > export.js
git add export.js
git commit -m "feat(reports): add CSV export functionality"
git switch develop
git merge feature/export-csv
git branch -d feature/export-csv
```
**Role 3 — 'Release Manager': prepares, tags, and ships the release, following this module's SemVer and CHANGELOG.md lessons.** Since both features are new, backward-compatible functionality (no breaking changes), the next version is a **MINOR** bump:
```
git switch develop
git switch -c release/1.1.0
# Stabilization: create the changelog entry (this module's CHANGELOG.md lesson)
cat > CHANGELOG.md << 'EOF'
# Changelog
## [1.1.0] - 2026-08-06
### Added
- Dark mode toggle for the UI.
- CSV export functionality for reports.
EOF
git add CHANGELOG.md
git commit -m "chore(release): prepare 1.1.0 changelog"
# Ship the release
git switch main
git merge release/1.1.0
git tag -a v1.1.0 -m "Release version 1.1.0"
git switch develop
git merge release/1.1.0
git branch -d release/1.1.0
```
**Urgent scenario — 'On-call developer': a critical bug is found in production, requiring an immediate hotfix.** Since it's a bug fix with no breaking change, this is a **PATCH** bump:
```
git switch main
git switch -c hotfix/csv-export-crash
echo "// fixed: handle empty dataset in CSV export" >> export.js
git add export.js
git commit -m "fix(reports): handle empty dataset in CSV export to prevent crash"
# Ship the hotfix to BOTH main and develop (Git Flow's dual-merge requirement)
git switch main
git merge hotfix/csv-export-crash
git tag -a v1.1.1 -m "Hotfix: prevent CSV export crash on empty dataset"
git switch develop
git merge hotfix/csv-export-crash
git branch -d hotfix/csv-export-crash
```
**Final verification.**
```
git log --oneline --graph --decorate --all
```
This should clearly show: the initial commit, two feature merges into `develop`, a release branch merging into both `main` (tagged `v1.1.0`) and back into `develop`, and finally a hotfix branch merging into both `main` (tagged `v1.1.1`) and back into `develop` — a complete, realistic Git Flow release cycle, exercising every single branch type from this module's Git Flow lesson, correctly versioned per Semantic Versioning, with a properly maintained CHANGELOG.md, and commit messages following Conventional Commits throughout.
Full Git Flow Release Cycle: Visual Walkthrough
Draw the complete Git Flow diagram from this module's Git Flow lesson, now populated with this specific exercise's actual content: 'develop' receiving two feature merges ('feat(ui): dark mode', 'feat(reports): CSV export'). 'release/1.1.0' branching from develop, adding a changelog commit, then merging into BOTH main (tagged v1.1.0) and back into develop. 'hotfix/csv-export-crash' branching from main, adding a fix commit ('fix(reports): handle empty dataset'), then merging into BOTH main (tagged v1.1.1) and back into develop. Caption: 'Every branch type from Git Flow exercised in one complete, realistic cycle.'
Release Cycle Exercise Steps: Quick Reference Table
| Phase | Simulated Role | Key Actions | Module 9 Concepts Applied |
|---|---|---|---|
| Setup | N/A | Initialize repo with main + develop branches | Git Flow structure (Lesson 2) |
| Feature development | Developer A, Developer B | Build features on feature/* branches, merge into develop | Git Flow feature branches, Conventional Commits |
| Release preparation | Release Manager | Create release/1.1.0, write CHANGELOG.md, merge into main (tagged) + develop | Git Flow release branches, SemVer, CHANGELOG.md |
| Urgent hotfix | On-call developer | Branch from main, fix, merge into main (tagged) + develop | Git Flow hotfix branches, SemVer PATCH bump |
Simulating the Release Cycle: Command Syntax
# Full sequence (condensed) — see explanation section for complete, step-by-step commands
# Setup
git init && git switch -c develop
# Developer A + B: two features merged into develop
git switch -c feature/dark-mode && git commit -am "feat(ui): add dark mode toggle" && git switch develop && git merge feature/dark-mode
git switch -c feature/export-csv && git commit -am "feat(reports): add CSV export" && git switch develop && git merge feature/export-csv
# Release Manager: release/1.1.0 -> main (tagged v1.1.0) + develop
git switch -c release/1.1.0
# ... write CHANGELOG.md, commit ...
git switch main && git merge release/1.1.0 && git tag -a v1.1.0 -m "Release 1.1.0"
git switch develop && git merge release/1.1.0
# On-call: hotfix/csv-export-crash -> main (tagged v1.1.1) + develop
git switch main && git switch -c hotfix/csv-export-crash
# ... fix, commit ...
git switch main && git merge hotfix/csv-export-crash && git tag -a v1.1.1 -m "Hotfix"
git switch develop && git merge hotfix/csv-export-crash
# Verify the complete history
git log --oneline --graph --decorate --allBreaking Down the Release Cycle Exercise Example
This condensed sequence mirrors the full, detailed walkthrough in the explanation section, compressing it to show the overall shape of the complete cycle: two features merging into `develop`, a release branch batching them into a tagged `v1.1.0` release on `main` (while also syncing back to `develop`), and finally a hotfix branch addressing a critical bug directly from `main`, tagged `v1.1.1`, and also synced back to `develop` — exercising every single Git Flow branch type from this module's second lesson in one connected, realistic scenario, with version numbers correctly following this module's Semantic Versioning rules (a MINOR bump for the new features, a PATCH bump for the bug-fix-only hotfix) throughout.
How This Exact Release Cycle Mirrors Real Team Processes
- This exact release cycle — feature development, batched release preparation with a changelog, and an eventual urgent hotfix — mirrors almost precisely the real, recurring rhythm of teams actually practicing Git Flow in production environments with formal, versioned releases.
- The specific version numbering choices in this exercise (a MINOR bump for the batched features, a PATCH bump for the hotfix) directly demonstrate the Semantic Versioning judgment calls a real release manager makes routinely, deciding exactly which number to increment based on the actual nature of the changes involved.
- Teams new to Git Flow often run through an exercise very similar to this one during onboarding, specifically to build confidence with the model's dual-merge requirements before relying on it for genuinely important, real releases.
- The changelog maintained in this exercise directly follows the Keep a Changelog structure from earlier this module, exactly the kind of artifact a real release manager would produce and commit as part of preparing any formal release.
Git Flow Release Cycle Interview Questions and Answers
Q1. Walk through the complete Git Flow release cycle you would follow to ship two completed features as a formal release.
Once features have been merged into develop via their own feature branches, create a release branch from develop, use it for final stabilization — including updating the CHANGELOG.md with the new version's changes — then merge that release branch into both main (tagging the new version, following Semantic Versioning) and back into develop, ensuring any stabilization fixes aren't lost from ongoing development.
Q2. In this exercise, why is the release tagged as v1.1.0 rather than v2.0.0 or v1.0.1?
Both features added were new, backward-compatible functionality with no breaking changes, which corresponds to a MINOR version bump under Semantic Versioning — incrementing from 1.0.0 to 1.1.0, resetting PATCH to zero, rather than a MAJOR bump (reserved for breaking changes) or a PATCH-only bump (reserved for bug fixes with no new features).
Q3. Why does the hotfix in this exercise branch from main rather than from develop?
Following Git Flow's model from earlier in this module, a hotfix branches directly from main to isolate the urgent fix from any potentially unstable, in-progress work that might exist on develop, ensuring the fix is based on the last known-good, actually released state.
Git Flow Release Cycle Quiz: Test Your Understanding
1. In this exercise, why is the release tagged v1.1.0 rather than v2.0.0?
- Version numbers are chosen arbitrarily
- Both features added were new, backward-compatible functionality with no breaking changes, corresponding to a MINOR bump under Semantic Versioning
- v2.0.0 was already used by a previous release
- MINOR bumps are always used regardless of the actual changes
Answer: B. Both features added were new, backward-compatible functionality with no breaking changes, corresponding to a MINOR bump under Semantic Versioning
Explanation: Per this module's Semantic Versioning lesson, new backward-compatible functionality (like both features in this exercise) corresponds specifically to a MINOR version bump, not a MAJOR bump reserved for breaking changes.
2. Why does the hotfix branch in this exercise merge into BOTH main and develop, rather than just main?
- This is a technical requirement of Git itself, unrelated to any strategy
- To ensure the fix is both actually shipped (via main) and not lost from ongoing development when develop's work is eventually released (via develop)
- Because develop cannot receive any merges
- Merging into both is optional and was done arbitrarily in this exercise
Answer: B. To ensure the fix is both actually shipped (via main) and not lost from ongoing development when develop's work is eventually released (via develop)
Explanation: This directly follows Git Flow's dual-merge requirement for hotfixes (this module's second lesson), ensuring the critical fix reaches production immediately while also being preserved in develop's ongoing history.
3. What version bump does the hotfix in this exercise represent, and why?
- MAJOR, because it's urgent
- PATCH, because it's a backward-compatible bug fix with no new functionality or breaking changes
- MINOR, because it touches the export.js file
- No version bump is needed for a hotfix
Answer: B. PATCH, because it's a backward-compatible bug fix with no new functionality or breaking changes
Explanation: The hotfix purely corrects a bug (handling an empty dataset) without adding new functionality or breaking anything, which corresponds exactly to a PATCH version bump under Semantic Versioning.
Common Mistakes When Simulating This Release Cycle
- Merging a feature branch directly into main instead of develop, violating Git Flow's defined branch structure from earlier in this module.
- Choosing the wrong SemVer increment for the release or hotfix, not correctly distinguishing between MAJOR, MINOR, and PATCH based on the actual nature of the changes.
- Forgetting to merge the release or hotfix branch back into develop after merging into main, risking changes being lost from ongoing development.
- Skipping the CHANGELOG.md update during release preparation, missing an opportunity to practice this module's changelog maintenance lesson.
Git Flow Release Cycle Exercise: Exam-Ready Quick Notes
- Complete cycle: setup (main + develop) → feature branches merge into develop → release branch merges into BOTH main (tagged) and develop → hotfix branch (from main) merges into BOTH main (tagged) and develop.
- SemVer judgment: new backward-compatible features = MINOR bump. Bug-fix-only hotfix = PATCH bump.
- CHANGELOG.md updated during release preparation, following Keep a Changelog structure.
- Final verification: git log --oneline --graph --decorate --all should show the complete, correctly-shaped history.
Git Flow Release Cycle Exercise: Key Takeaways
- This exercise exercises every single Git Flow branch type from this module's second lesson in one connected, realistic, complete scenario.
- Correctly applying Semantic Versioning requires genuine judgment about the nature of each specific change — new functionality versus a pure bug fix.
- Completing this full cycle — features, a formal release with a changelog, and an urgent hotfix — demonstrates practical fluency with this entire module's content working together.
Frequently Asked Questions About This Release Cycle Exercise
Q1. What is the correct sequence of steps for a complete Git Flow release cycle?
Individual features are built on feature/* branches and merged into develop. Once enough features have accumulated, a release/* branch is created from develop for final stabilization (including updating the changelog), then merged into both main (tagged with the new version) and back into develop. An urgent hotfix follows a similar dual-merge pattern but branches directly from main instead of develop.
Q2. How do I decide whether a release should be a MAJOR, MINOR, or PATCH version bump?
Ask whether the release includes any breaking, incompatible changes (MAJOR), only adds new, backward-compatible functionality (MINOR), or contains only backward-compatible bug fixes with nothing new or breaking (PATCH) — following this module's Semantic Versioning lesson.
Q3. Why does this exercise's hotfix branch from main instead of develop?
Following Git Flow's model, a hotfix branches directly from main to isolate the urgent fix from any potentially unstable, in-progress work that might exist on develop, ensuring it's based on the last known-good, actually released state.
Q4. What should the final git log --graph output look like after completing this exercise?
It should show two feature branches merged into develop, a release branch that merged into both main (with a v1.1.0 tag) and back into develop, and a hotfix branch that merged into both main (with a v1.1.1 tag) and back into develop — the complete, correctly structured Git Flow history.
Q5. What does completing this exercise demonstrate about my understanding of this module?
It demonstrates practical, hands-on fluency with Git Flow's complete branch model, correct Semantic Versioning judgment for different types of changes, Conventional Commits message structure, and proper CHANGELOG.md maintenance — all of this module's major concepts working together in one realistic, connected workflow.
Summary
This capstone exercise simulates a complete, realistic Git Flow release cycle, taking on three sequential roles to exercise every branch type covered in this module's Git Flow lesson. Starting from a repository initialized with `main` and `develop`, two simulated developers each build a feature on their own `feature/*` branch, using Conventional Commits, and merge back into `develop`. A simulated release manager then creates a `release/1.1.0` branch, adds a properly structured `CHANGELOG.md` entry following the Keep a Changelog convention, and merges the release into both `main` (tagged `v1.1.0`, a MINOR bump since both features were new, backward-compatible functionality) and back into `develop`. Finally, a simulated on-call developer handles an urgent production bug via a `hotfix/*` branch created directly from `main`, merging the fix into both `main` (tagged `v1.1.1`, a PATCH bump since it's a pure bug fix) and `develop` — completing the dual-merge pattern Git Flow requires for both release and hotfix branches. Verifying the final history with `git log --oneline --graph --decorate --all` confirms a complete, correctly structured Git Flow history, demonstrating practical fluency with this entire module's branching strategy, Semantic Versioning, Conventional Commits, and changelog maintenance content working together as one connected, realistic workflow.