Carlos Mavros

Version Control at Scale + Advanced Git

Lesson 11 90 min

Beyond the Basics

The previous course covered Git fundamentals and worktrees. This lesson goes deeper: how teams use Git at scale — branching strategies, CI integration, semantic versioning, and code review culture.

Branching Strategies

When multiple people work on the same codebase, branches are how you coordinate without constant conflicts. The choice of branching strategy shapes your development speed, stability, and deployment frequency.

Git Flow

Structure: Two permanent branches (main for production-ready, develop for integration) plus short-lived feature, release, and hotfix branches.

main ────────────────────────────────────────────────○ (tagged v1.2.0)
       \                                          /
develop ─────────○─────────────────────○─────────
                  \                   /
feature/solver    ─○──○──○────────────

Best for: Projects with formal release cycles, versioned software that multiple clients install, strict QA requirements before release.

Not ideal for: Teams doing continuous deployment (main branch is always production).

GitHub Flow

Structure: One permanent branch (main), feature branches, and direct pull requests to main. Main is always deployable.

main ──────────────────────────────────────
        \           /    \           /
feature/A──○──○──○       feature/B──○

Best for: Teams doing continuous deployment, small teams, web services with rolling deployments.

Rule: Main is always production-ready. Feature branches are short-lived. Every merge to main deploys (or could deploy).

Trunk-Based Development

Developers commit directly to main (or to very short-lived feature branches < 24 hours). High-frequency integration, feature flags used to hide incomplete features.

Best for: Mature engineering teams with strong test coverage and CI. Google-scale development culture.

Semantic Versioning (SemVer)

For software distributed to users (libraries, APIs, tools):

MAJOR.MINOR.PATCH

1.0.0  — Initial release
1.0.1  — Bug fix (backward compatible)
1.1.0  — New feature (backward compatible)
2.0.0  — Breaking change (not backward compatible)
git tag v1.2.3                  # Create a tag
git tag -a v1.2.3 -m "Release 1.2.3: improved solver convergence"
git push origin v1.2.3          # Push the tag
git log --oneline v1.1.0..v1.2.3  # Changes between versions

CI Integration

Continuous Integration (CI) means: every push to a branch automatically runs the full test suite and build. If it fails, the branch is blocked from merging.

A minimal GitHub Actions CI pipeline for a Python simulation tool:

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12"]

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest pytest-cov

      - name: Run tests
        run: pytest tests/ --cov=src/ --cov-report=xml

      - name: Check coverage
        run: |
          python -m coverage report --fail-under=80

Code Review Culture

Code review is not about catching bugs (that’s what tests are for). Code review is about:

  • Knowledge sharing — the reviewer learns the codebase; the author gets a second opinion
  • Architectural alignment — catching design decisions that contradict the overall architecture
  • Mentorship — senior engineers teaching patterns to junior engineers through review comments
  • Collective ownership — the whole team understands the whole codebase

Good review practices:

  • Reviewers comment on the code, not the person: “This function has three concerns” not “you wrote this wrong”
  • Authors explain why, not just what: the PR description should explain the problem being solved
  • Disagreements are resolved by criteria (principles, trade-offs, data), not by seniority
  • Small PRs (< 400 lines) are reviewed better than large ones

Exercise 11.1: Branching Strategy Decision

Exercise: For each project, choose a branching strategy and justify it:

  1. An open-source Python library for structural analysis with monthly releases and a community of 50 contributors
  2. A web-based FEM platform with a SaaS model that deploys daily and has 8 engineers
  3. A safety-critical avionics simulation tool that requires DO-178C certification
  4. A startup’s internal data pipeline tool maintained by 2 engineers

For each: name the strategy, explain why it fits, name one risk of this choice.

Quiz

A team uses GitHub Flow. A major bug is discovered in production. The main branch already has 3 unreleased features merged since the last deployment. What is the right response?

  • A) Revert all 3 features, fix the bug, and re-add them one by one
  • B) Create a hotfix branch from the commit hash of the last deployment, fix the bug, and deploy that branch
  • C) Cherry-pick the bug fix onto main after developing it on a feature branch
  • D) Roll back to the previous Docker image and investigate the bug separately
Answer

C) Cherry-pick the bug fix onto main after developing it on a feature branch.

In GitHub Flow, main is always the source of truth. The fix should be developed on a feature branch, tested, reviewed, and merged to main. Then it’s deployed. If the 3 unreleased features are behind feature flags, they stay hidden in production while the fix goes live. If they’re not behind feature flags, option D (rolling back the deployment image) is a valid operational response while the fix is developed, but D alone doesn’t fix the bug — it just buys time.