Learn Git Branching: the visual “lab” every sysadmin and developer should keep handy

Share on Pinterest Share on LinkedIn Share on WhatsApp
Share on Pinterest Share on LinkedIn Share on WhatsApp

Mastering Git isn’t about memorizing commands; it’s about understanding the graph—branches, commits, pointers, and how HEAD, branch refs, and tags move with each operation. Learn Git Branching (LGB) turns that graph into an interactive game so you can rehearse, safely, the surgery you’d never risk on a live repo. For SRE/DevOps and engineering teams, it’s a practical tool for onboarding, ongoing training, and incident simulations around version control.

What Learn Git Branching is (and isn’t)

  • What it is: a repo simulator with a live animated commit graph. Every command you type mutates the DAG in real time. Across 34 levels, you practice eight core commands (and variants): branching, merging, rebase, reset, cherry-pick, etc.
  • What it isn’t: a replacement for git or a coverage of every edge case (submodules, LFS, hooks). It’s a trainer to cement Git’s mental model and build speed and confidence.

Direct access (Spanish UI available):

Why it matters to admins and developers

  1. It models the graph, not the shell. In production, the risk isn’t typing git; it’s knowing consequences. What’s the difference between git reset --hard and git revert? What does rebase do to shared history? LGB shows it live.
  2. Accelerates onboarding. New hires ramp in 1–2 focused sessions with self-contained challenges.
  3. Operational safety. Practice history surgery—rewrites, rescue flows with the reflog mental model, pre-release cleanup—without endangering the monorepo.
  4. Standardizes workflows. Visualize GitFlow, Trunk-Based, and release/hotfix branches to align dev, QA, and ops practices.

A 90-minute adoption plan (mixed SRE/Dev team)

Block 1 (20’): fundamentals

  • commit, branch, checkout, merge (intro levels).
  • Visualize fast-forward vs merge commit.
  • Golden rule: never rewrite shared public history.

Block 2 (35’): “danger with guardrails”

  • rebase (linearize local history before push).
  • reset (--soft, --mixed, --hard): when each is appropriate.
  • reflog concept for rescues (LGB isn’t a real shell, but you can practice the pointer moves with reset/cherry-pick to mimic recovery).

Block 3 (25’): flows and policy

  • Feature branches + PRs vs Trunk-based.
  • Release strategies (tags, support branches, hotfix cherry-pick).
  • Naming conventions & protected-branch rules in your forge (GitHub/GitLab).

Assignment (10’): a git golf challenge (solve a level in the fewest commands), rotating drivers for collaborative reasoning.

Sandbox clinic: history surgery you can see

In LGB, run levels to list challenges; or enter sandbox and try:

# Create branches and diverge history
git checkout -b feature/login
git commit
git commit
git checkout main
git commit

# Attempt 1: explicit merge with a merge commit
git merge feature/login

# Undo and try a linear rebase flow
undo
git checkout feature/login
git rebase main
git checkout main
git merge feature/login  # now FF
Code language: PHP (php)

Key talking points while watching the DAG:

  • Fast-forward vs merge commit: when a straight line aids readability, and when a merge node is valuable documentation.
  • rebase rewrites SHAs—safe only for local/unpushed work.
  • reset moves pointers; objects may persist until GC, so rescue is often possible (hence the reflog mental model).
  • cherry-pick creates new commits (new SHAs); great for controlled hotfixes across branches—use judiciously.

Recommended policies by context

Large monorepo (Trunk-based + feature flags)

  • Rule: short-lived branches, small PRs, squash merges to main.
  • Before push: git pull --rebase or git fetch && git rebase origin/main.
  • Protected branches: main, release/* with mandatory checks.
  • Hotfix: hotfix/x.y.z branch, cherry-pick to main and active release/*, finalize with signed tag.

Product with LTS lines (GitFlow-ish)

  • develop for integration, release/* freezes features.
  • Prefer rebase on feature branches before merging to keep history tidy.
  • Avoid uncontrolled cross-merges between release/* and develop; prefer targeted cherry-picks.

Using it offline (brown-bag or internal training)

Docker (air-gapped friendly):

docker run -p 8080:80 ghcr.io/pcottle/learngitbranching:main
# Open http://localhost:8080
Code language: PHP (php)

Local build (for custom tweaks):

git clone https://github.com/pcottle/learnGitBranching
cd learnGitBranching
yarn install
yarn gulp build
open ./index.html
Code language: PHP (php)

Classroom tips:

  • Project LGB and hand out command cheat sheets.
  • Use the Level Builder to reflect your company’s conventions (branch names, release cadence).
  • Track git golf by pairs to reward precision and understanding.

Common mistakes—and how LGB makes them obvious

  1. rebase on shared branches.
    • Risk: force-push overwrites teammates’ work.
    • Rule: rebase local only; for remotes, prefer merge or revert.
  2. Confusing reset --hard with revert.
    • reset --hard moves pointers and discards local changes.
    • revert creates a new inverse commit (safe on public branches).
  3. Detached HEAD confusion.
    • LGB shows HEAD pointing to a commit, not a branch.
    • Fix: git switch -c fix/foo to anchor your work on a branch.
  4. Cherry-pick cascades.
    • Duplicated commits, recurring conflicts.
    • Policy: label PRs and automate backports where practical.

Exercise checklist (quick wins)

  • FF vs merge commit: reproduce both, choose deliberately.
  • Interactive rebase (simulated): reorder/squash before merging a feature.
  • Lost-commit rescue: simulate loss with reset, recover by pointer moves (explain reflog conceptually).
  • Branch hygiene: delete merged branches safely; tag releases.
  • Simultaneous hotfix: cherry-pick to release/2.4 and main, avoid divergence.

Forge-level best practices to pair with LGB

  • Branch protection (main, release/*): required checks, code review, disallow force-push.
  • Conventional Commits for auto-changelog & semantic-release.
  • PR templates with test checklist, impact, and rollback plan.
  • CI rules that block merges unless the branch is FF relative to main (or auto-rebase).
  • Signed tags (vX.Y.Z) and reproducible artifacts.

Metrics your CTO/Head of Eng will appreciate

  • Lead time from feature branch open → merge.
  • Revert rate and conflict counts per sprint.
  • Average branch age (alert if > 14 days).
  • Squash/merge ratio by repo (history consistency).
  • Time to recovery from a simulated “oops” (via LGB + runbook).

Bottom line

For technical teams, seeing the DAG is the difference between habit and precision under pressure. Learn Git Branching gives a safe space to visualize each decision and to operationalize good judgment: when to rebase, when to merge, when to revert, and how to undo without panic. Fold LGB into onboarding, version-control game days, and continuous training—the cost is minimal; the reduction in incidents is measurable.

FAQ

Is this only for juniors?
No. Juniors nail the mental model; seniors practice history surgery and align policies visually. Especially useful in large monorepos with many code owners.

Can I create levels that mirror our real flows?
Yes. Use the Level Builder to produce a JSON level and share via gist/URL. Great for formalizing release/backport flow.

How do I run a session without Internet?
Use Docker (ghcr.io/pcottle/learngitbranching:main) or a local build (yarn gulp build) and serve index.html on the internal network.

Rebase or merge for integrating a feature?
Rule of thumb: rebase locally to clean up before the PR; merge (with or without squash) on shared branches. Never rebase public active branches.

Share on Pinterest Share on LinkedIn Share on WhatsApp

Related articles

Scroll to Top