Git: the ledger every change signs (commits, branches, merge and rebase)

The board where “deploy = merge a PR”, “rollback = git revert” and “audit = git log” sit in one corner as if they were obvious. This lesson is the book those three lines are written in.

Before you start. Two lessons lean on this one without explaining it. Infrastructure as Code & GitOps keeps the whole system’s blueprint “in git” and lets a patrol, a program that keeps checking, make reality match whatever is filed there. The Assembly Line (CI/CD) starts its assembly line at “a commit lands”, where a commit is one saved change to the code. It trusts a hash, a fingerprint computed from every byte of a thing, so that any change to the thing gives a different fingerprint.

The idea in 30 seconds

A commit is a full snapshot of every file, plus its author, time, message and the commit before it. Git stores snapshots, not lists of changes.
Git names every file and commit by a hash of its contents, so unchanged files are stored once and any edit to old history changes every hash after it.
A branch is a tiny file holding one commit hash, and HEAD records which branch you are on. Committing moves the branch forward; the commits never move.
A merge joins two lines with a new commit that has two parents and leaves both lines intact. A rebase recopies commits onto another line, giving them new hashes.
Never rebase commits other people have already built on: they keep the old hashes and end up with the same change twice.
GitOps and CI/CD assume this: a commit is the unit of deploy, main is the desired state, a pull request is the review gate, and revert adds history instead of erasing it.

Read the story · Skip to the numbers