TECH **Git & GitHub Branch Management & Best Practices: Zero-Fluff Study Guide**

Git & GitHub Branch Management & Best Practices: Zero-Fluff Study Guide

(Git Flow, GitHub Flow, and Real-World Workflows)

1. What This Is & Why It Matters

Branch management is how you organize work in Git/GitHub without stepping on teammates’ toes, breaking production, or losing track of changes. Think of it like a construction site: - Main branch (main/master) = The finished building (production-ready code).
- Feature branches = Scaffolding where workers (developers) build new rooms (features).
- Release branches = Final inspections before moving in (QA/staging).
- Hotfix branches = Emergency repairs (critical bug fixes).

Why it matters in production:
- Without a branching strategy, teams merge chaos into main, breaking deployments, overwriting work, or deploying unfinished features.
- With a strategy, you: - Deploy multiple features in parallel without conflicts.
- Roll back bad changes instantly.
- Isolate experiments (e.g., a risky refactor) without affecting others.
- Automate CI/CD (e.g., GitHub Actions) to run tests only on relevant branches.

Real-world scenario:
You’re a DevOps engineer at a SaaS company. A critical bug is reported in production. Without a branching strategy: - You’d have to dig through main to find the bug, risking more breakage.
- New features in progress might accidentally get deployed.
- Rollbacks would be manual and error-prone.

With Git Flow or GitHub Flow: - You create a hotfix branch from main, fix the bug, and merge it back without touching in-progress features.
- CI/CD pipelines automatically deploy the fix to production.

2. Core Concepts & Components

1. Branch

• Definition: A movable pointer to a commit in Git’s history.
• Production insight: Branches are cheap (just a 40-byte file), so create them liberally. Deleting old branches keeps the repo clean.

2. main/master Branch

• Definition: The default branch containing production-ready code.
• Production insight: Never commit directly to main—use pull requests (PRs) to enforce code reviews and CI checks.

3. Feature Branch

• Definition: A short-lived branch for developing a single feature or bugfix (e.g., feature/user-auth).
• Production insight: Name branches consistently (e.g., feature/, bugfix/, docs/) to make them self-documenting.

4. Release Branch (Git Flow only)

• Definition: A branch for final testing before deploying to production (e.g., release/1.2.0).
• Production insight: Use this to freeze features while QA tests. Only bug fixes go here—no new features.

5. Hotfix Branch (Git Flow only)

• Definition: A branch for urgent production bug fixes (e.g., hotfix/500-error).
• Production insight: Hotfixes must be merged into both main and develop to avoid regressions.

6. Pull Request (PR) / Merge Request (MR)

• Definition: A request to merge a branch into another (e.g., feature/login → main).
• Production insight: PRs are not just for merging—they’re for code reviews, discussions, and CI checks. Require approvals before merging.

7. Git Flow

• Definition: A strict branching model with main, develop, feature, release, and hotfix branches.
• Production insight: Best for versioned software (e.g., mobile apps, desktop apps) where releases are infrequent and require QA.

8. GitHub Flow

• Definition: A simpler model with only main and feature branches. Deployments happen directly from main.
• Production insight: Best for web apps and SaaS where you deploy multiple times a day (e.g., GitHub, Netflix).

9. Trunk-Based Development

• Definition: A minimalist approach where developers work in small, short-lived branches (or directly on main with feature flags).
• Production insight: Used by high-velocity teams (e.g., Google, Facebook) to reduce merge conflicts.

10. Branch Protection Rules

• Definition: GitHub/GitLab rules to enforce workflows (e.g., "Require PR approvals before merging to main").
• Production insight: Always enable branch protection on main to prevent accidental force-pushes or direct commits.

3. Step-by-Step Hands-On: Implementing Git Flow

Prerequisites

• Git installed (git --version).
• A GitHub/GitLab account.
• A project repo (or create one: git init my-project).

Step 1: Initialize Git Flow

Git Flow is a set of Git extensions (not built into Git). Install it:

# macOS (Homebrew)
brew install git-flow-avh

# Linux (Debian/Ubuntu)
sudo apt-get install git-flow

# Windows (Git Bash)
git clone https://github.com/petervanderdoes/gitflow-avh.git
cd gitflow-avh
make install

Initialize Git Flow in your repo:

git flow init

You’ll be prompted to set branch names. Use defaults (press Enter for all):

Branch name for production releases: [main]
Branch name for "next release" development: [develop]
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Verify:

git branch

You should see:

* develop
  main

Step 2: Create a Feature Branch

Start a new feature (e.g., "user-login"):

git flow feature start user-login

This creates and checks out feature/user-login.

Make changes:

echo "function login() { ... }" > auth.js
git add auth.js
git commit -m "Add login function"

Finish the feature (merges to develop):

git flow feature finish user-login

This: 1. Merges feature/user-login into develop.
2. Deletes the feature branch.
3. Checks out develop.

Step 3: Create a Release Branch

When develop is ready for QA, create a release:

git flow release start 1.0.0

This creates release/1.0.0 from develop.

Test and fix bugs:

echo "Fix login bug" >> auth.js
git add auth.js
git commit -m "Fix login bug"

Finish the release (merges to main and develop):

git flow release finish 1.0.0

This: 1. Merges release/1.0.0 into main.
2. Tags main with 1.0.0.
3. Merges back into develop.
4. Deletes the release branch.

Step 4: Hotfix a Production Bug

A critical bug is found in production (main). Create a hotfix:

git flow hotfix start 1.0.1

This creates hotfix/1.0.1 from main.

Fix the bug:

echo "Fix critical auth bug" >> auth.js
git add auth.js
git commit -m "Fix critical auth bug"

Finish the hotfix (merges to main and develop):

git flow hotfix finish 1.0.1

This: 1. Merges hotfix/1.0.1 into main.
2. Tags main with 1.0.1.
3. Merges back into develop.
4. Deletes the hotfix branch.

Step 5: Push to GitHub

Push all branches and tags:

git push origin main develop --tags
git push origin feature/* release/* hotfix/*

4. ? Production-Ready Best Practices

Security

• Protect main and develop branches with GitHub branch protection rules:
• Require PR approvals (2+ reviewers).
• Require status checks (CI must pass).
• Restrict who can push.
• Use signed commits (git commit -S) to verify author identity.
• Rotate deploy keys if a team member leaves.

Cost Optimization

• Delete old branches (they clutter the repo and slow down git fetch).
  bash git branch --merged | grep -v "\*\|main\|develop" | xargs git branch -d
• Use shallow clones (git clone --depth 1) for CI/CD to save bandwidth.

Reliability & Maintainability

• Name branches consistently:
• feature/short-description (e.g., feature/user-auth).
• bugfix/short-description (e.g., bugfix/login-error).
• docs/short-description (e.g., docs/api-guide).
• Keep branches short-lived (merge within days, not weeks).
• Use .gitignore to exclude build files, secrets, and local configs.
• Tag releases (git tag -a v1.0.0 -m "Release 1.0.0") for easy rollbacks.

Observability

• Monitor branch age (old branches = stalled work).
  bash git for-each-ref --sort=committerdate refs/heads/ --format='%(committerdate:short) %(refname:short)'
• Set up GitHub Actions to:
• Run tests on PRs.
• Auto-delete merged branches.
• Notify Slack on failed merges.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which branching model is best for a web app with daily deployments?"
2. Answer: GitHub Flow (simple, main is always deployable).

3. Trap: Git Flow is overkill for continuous deployment.

4. "How do you fix a critical bug in production using Git Flow?"

5. Answer: Create a hotfix branch from main, fix, merge back to main and develop.

6. Trap: Don’t branch from develop—hotfixes must come from main.

7. "What’s the difference between git merge and git rebase?"

8. Answer:
   • merge: Creates a merge commit (preserves history).
   • rebase: Rewrites history (cleaner, but don’t use on shared branches).

9. Trap: Rebasing shared branches can break others’ work.

10. "How do you enforce code reviews before merging to main?"

11. Answer: Enable branch protection rules requiring PR approvals.
12. Trap: "Require 1 approval" is not enough—use 2+ for critical repos.

7. ? Hands-On Challenge

Challenge:
You’re working on a team using Git Flow. A teammate accidentally merged a broken feature into develop. How do you: 1. Revert the bad merge without losing other work? 2. Ensure the fix is applied to both develop and the next release?

Solution:

# 1. Find the bad merge commit (use `git log --oneline --graph`)
git revert <bad-merge-commit-hash>  # Reverts the merge commit

# 2. Create a hotfix branch from main (if the bug is in production)
git flow hotfix start fix-broken-feature
# Fix the bug, commit, then:
git flow hotfix finish fix-broken-feature

Why it works:
- git revert undoes the merge without rewriting history.
- Hotfix ensures the fix propagates to both main and develop.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Git Flow Official Docs – The original Git Flow article.
2. GitHub Flow Guide – GitHub’s take on branching.
3. Atlassian Git Tutorials – Deep dives on Git Flow vs. GitHub Flow.
4. GitHub Branch Protection Rules – How to lock down main.