Module 28 Professional Engineering

Version Control & Collaboration

Most vibe coders use git as a save button. They commit with messages like 'fix' and 'stuff' and 'update', merge everything into main directly, have never rebased in their lives, and wouldn't know how to use git bisect if a production bug depended on it. When something goes wrong, they don't reach for the reflog — they panic. This module changes the relationship with git from an anxiety-inducing mystery to a precision tool for managing the history of a collaborative codebase. You'll start with git internals — the DAG of commits, how branches are just pointers, what the index is, how HEAD works, and what the reflog saves you from. This understanding makes every git command make sense instead of requiring memorization. You'll understand the branching strategies used by professional teams — gitflow, trunk-based development, GitHub flow — and the tradeoffs that make each appropriate for different team sizes and deployment frequencies. Interactive rebase is the git feature that separates professional developers from hobbyists — the ability to squash, reorder, and edit commits to produce a clean, reviewable history. Git bisect is the feature that makes finding a regression commit a binary search rather than a manual review. Code review best practices determine whether a team's reviews are genuinely useful or ceremonial checkboxes. This module covers all of it.

What You'll Learn

  • 1
    Git Internals — Objects, refs, the DAG, the index, HEAD, and the reflog
  • 2
    Branching Strategies — Gitflow, trunk-based development, GitHub flow
  • 3
    Merge vs Rebase — What each does, when to use each, the golden rule of rebasing
  • 4
    Interactive Rebase — Squashing, reordering, editing, splitting commits
  • 5
    Git Bisect — Binary search for bugs, automating with test scripts
  • 6
    Code Review Best Practices — What to look for, how to comment, how to receive feedback
  • 7
    Pull Request Workflows — Writing great PR descriptions, review loop, merge strategies
  • 8
    CI Gates, Monorepos, and Git Automation — Protected branches, merge queues, git hooks

Capstone Project: Simulate a Team Development Workflow — Branches, Merge Conflicts, Code Review, CI Gates, and Git Bisect

Simulate a complete team development workflow solo — maintaining a feature branch alongside a simulated main branch with concurrent changes, resolving merge conflicts, using interactive rebase to clean up a messy commit history, writing a pull request description that correctly describes the intent and testing, and using git bisect with an automated test script to find the commit that introduced a specific regression bug.

Why This Matters for Your Career

Git is the source of truth for every professional codebase, and the quality of the git history is a direct measure of the team's engineering culture. A clear git history — with focused commits, descriptive messages, and logical progression — makes code review faster, blame more useful, and bisecting regressions possible. A messy git history is a silent tax on every developer who has to work with it afterward. Trunk-based development, with its emphasis on short-lived branches and continuous integration, is the branching strategy that enables the highest deployment frequency with the lowest merge conflict pain. Understanding why it works, and what practices make it safe — feature flags, small commits, comprehensive CI — is what allows teams to ship multiple times per day without chaos. Code review is the primary mechanism for knowledge sharing, quality enforcement, and mentorship in professional engineering teams. Engineers who give great code reviews — specific, actionable, focused on the code not the author — make their teams better at a rate that compounds over time. Learning to give and receive feedback professionally is a career-critical skill that is rarely explicitly taught.