Stage 2 · Tools
Branching Strategies
Practice: Team Simulation
Simulate a 4-person team with conflicts, reviews, and a hotfix release.
Setup
This exercise puts everything from this module into practice. You will simulate a small team working on a shared codebase — complete with feature work, merge conflicts, code review, and an urgent production hotfix.
You need two terminals and two separate directories representing two developers: Alice and Bob.
mkdir team-sim && cd team-sim
git init --bare shared.git
# Alice clones it
git clone shared.git alice
cd alice
git config user.name "Alice"
git config user.email "alice@example.com"
# Bob clones it
cd ..
git clone shared.git bob
cd bob
git config user.name "Bob"
git config user.email "bob@example.com"A bare repo acts as the shared origin. Both developers clone from it.
# In alice's directory
cd alice
echo "# MyApp" > README.md
git add README.md
git commit -m "feat: initial project README"
git push origin mainThis gives the team a starting point.
Day 1: Feature Branches
Alice and Bob both pick up tasks. Alice works on a login page, Bob works on a settings page. Both create feature branches.
# Alice
git switch -c feat/login-page
echo "# Login Page
Username: ___
Password: ___" > login.md
git add login.md
git commit -m "feat: add login page draft"
git push -u origin feat/login-pageAlice creates a branch and pushes it so the team can see her progress.
# Bob
git pull
git switch -c feat/settings-page
echo "# Settings
Theme: dark
Notifications: on" > settings.md
git add settings.md
git commit -m "feat: add settings page draft"
git push -u origin feat/settings-pageBob pulls first to get Alice's README, then creates his own branch.
Use prefixes like feat/, fix/, chore/ to keep branches organized and enable branch-based automation.
Day 2: Conflicts & Review
Alice finishes her feature first and merges. Bob is still working — but now he needs to pull Alice's changes, which creates a conflict.
# Alice
git switch main
git merge feat/login-page
git push origin mainAlice's feature is merged into main.
# Bob
git switch main
git pull
# Now update his feature branch
git switch feat/settings-page
git merge main
# CONFLICT in README.md (both added content)
# Resolve: keep both contributions
cat README.md
# Edit to combine both sections
git add README.md
git commit -m "fix: resolve merge conflict with main"
git pushBob pulls Alice's merge, updates his branch, and resolves the conflict by keeping both contributions.
After resolving, Bob opens a pull request. You simulate review by examining his diff:
# Check what Bob changed
git diff main..feat/settings-page
# Leave review feedback (simulate with a comment commit)
git switch feat/settings-page
echo "# Review: looks good, minor typo" >> settings.md
git add settings.md
git commit -m "docs: add review feedback"
git pushIn real life this happens via GitHub PR comments. Here we simulate the feedback loop.
Small PRs are easier to review, less likely to conflict, and merge faster. Aim for under 400 lines changed.
Day 3: Emergency Hotfix
Production is broken. A critical bug needs to be fixed immediately — while both developers have unmerged feature work.
# Alice handles the hotfix
git switch main
git switch -c hotfix/fix-login-crash
echo "Emergency fix applied" >> hotfix.txt
git add hotfix.txt
git commit -m "fix: patch login crash (URGENT)"
git push -u origin hotfix/fix-login-crash
# Merge immediately
git switch main
git merge hotfix/fix-login-crash
git push
# Tag the release
git tag -a v1.0.1 -m "Hotfix: login crash"
git push --tagsHotfix branches branch off main, fix the issue, merge back immediately. Never block a hotfix for feature work.
# Bob
git switch main
git pull
# Rebase his feature on the updated main
git switch feat/settings-page
git rebase main
git push --force-with-leaseBob rebases his feature on top of the hotfix so his branch includes the latest main.
Always use --force-with-lease instead of --force. It prevents overwriting commits you haven't seen.
Wrap-Up
You have now simulated a realistic team workflow. Let's see the final state:
git log --oneline --graph --all --decorateThis shows the full branching and merging history of the simulation.
- Feature branches for isolated work
- Pull request and review process
- Merge conflict resolution
- Hotfix branching from main
- Rebasing feature branches on latest main
- Tagged releases for versioning
Every command in this exercise is something you will use weekly as a professional developer. The pattern — branch, work, review, merge — is universal across every engineering team.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.