# Engineering Git Workflow

## Small commits, meaningful messages

A commit containing "fixed stuff" and 40 unrelated file changes is nearly useless to anyone
reading history later — including future-you. A commit that does ONE logical thing, with a
message describing what and why, is what actually makes `git log` a useful tool rather than
noise. This isn't pedantry — it's what makes rollback (below) and code review actually
practical.

## `main` as a protected source of truth

Real engineering teams treat their main branch as the one everyone trusts to be in a working
state at all times — direct, unreviewed pushes to `main` are typically restricted specifically
BECAUSE it's the shared source of truth every deployment and every other branch is built from.
Feature branches (Module 4) exist precisely so risky, in-progress work never threatens that
trust.

## Review: another set of eyes before history is permanent

Before a change reaches `main`, most real teams have someone else look at it first (a "pull
request" or "merge request," depending on the platform). This isn't about distrust — it's a
second perspective catching mistakes, and a natural point to discuss WHY a change is being made,
not just what it does.

## History and rollback as safety nets

Because every commit is permanent and inspectable, a bad change can be identified precisely (via
`git log`) and reverted deliberately — confident recovery, not panic, when something goes wrong.
This is Module 1's original promise, now fully realized: reproducibility and rollback aren't
theoretical, they're what your daily small-commit discipline actually buys you.

## Why this matters to DevOps, GitOps, and Infrastructure as Code

Everything in this lesson — small deliberate changes, a trusted source of truth, review before
merge, reliable history — is EXACTLY what CI/CD pipelines automate, what GitOps treats a Git
repository as authoritative for, and what Infrastructure as Code relies on to safely manage real
infrastructure through the same discipline you just practiced on plain text files. ROOT 11
builds directly on this course's habits, not a new set of ideas.

## Instructor Notes

**Lesson goal:** Close ROOT 03 by explicitly naming the professional discipline (not just Git
commands) this course was building, and its direct connection to DevOps/GitOps/IaC.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** treating "review" and "protecting main" as bureaucratic
overhead rather than genuine risk management — connect it back to the real cost of a bad change
reaching a shared source of truth unreviewed.

**Discussion question:** "Why might a team enforce small commits and review even when working
alone on a personal project?" (Good answers: future-you benefits from the same clarity; building
the habit now pays off the moment you DO work with others.)