This lesson delivers on a promise the course has been carrying since module 7. In lesson 07-06 we drew an explicit boundary: there we talked about continuous integration — automatically checking that what gets integrated works — and left for here how that code reaches users. In 07-04 we deferred the mechanics of environments and promotion. And in 05-05, when creating the annotated tag v1.4.0, we said that tags would be the piece that triggers a deployment.

It all converges here.

The change of perspective is a large one. Until now, Git has been a tool used by people: Ana writes code, Bruno reviews, Carla integrates. From this point on, Git is also — and above all — a tool used by machines. Pipelines that clone, read tags, compare hashes, build artefacts and publish to production without anybody pressing anything. In an organisation with continuous deployment, the vast majority of the day's git clone runs are executed by a server, not by a person.

And that changes the weight of every operation. When git push origin main means "this will be in production in four minutes", rigour stops being a professional virtue and becomes an operational requirement.

1. Git as the single source of truth
2. Continuous integration, delivery and deployment
3. What triggers a deployment and how it is tied to Git
4. The artefact is identified by the commit hash
5. Infrastructure as code
6. GitOps: the repository as the desired state
7. Secrets in an automated world
8. Automatic versioning and changelog
9. Rolling back in production
10. Making the pipeline independent of a human

The underlying idea of DevOps, as far as Git is concerned, is an extension of what you already know: the repository stops containing only code.

Historically, a repository contained the application. Everything else — how the server is configured, which version of the database there is, what environment variables exist, how it gets deployed — lived in somebody's head, in a document, in a web console or in a script on an administrator's desktop.

The change consists of putting all of that into Git as well:

That last row is the most valuable and the most underestimated. If app.js starts needing a new environment variable, the commit that introduces the code and the one that declares the variable are the same commit. There is never a revision of the repository in which the code asks for something the configuration does not provide.

If something can break production, it must be in Git.

Configuration, infrastructure, database migrations, the definition of the pipelines, access policies. Anything that is a text file and affects the behaviour of the system.

And the corollary, which is just as important:

If something is in Git, it must not be changed outside Git.

Modifying the production configuration from a web console creates drift: the repository says one thing and reality says another. As soon as drift exists, the repository stops being the source of truth and the whole edifice falls down. It is the problem GitOps attacks head-on (section 6).

With one absolute exception, already established in lesson 08-05: secrets, never. Passwords, API keys, private certificates, tokens. They go in a secrets manager and are injected at deployment time. We shall come back to this in section 7.

Three terms that are constantly confused, and whose difference is exactly where the human button is.

The difference between delivery and deployment is exactly one click. And the decision to remove that click is not technical but one of confidence: it is removed when the test suite is so good and the rollback so fast that a human watching the screen adds no safety, only latency.

1. Tests you genuinely trust. If the team runs manual tests "just in case" before deploying, it is not ready.
2. Rollback in minutes. The insurance is not "never failing", but "fixing it before it matters".
3. Progressive deployment. Releasing the new version to a percentage of the traffic and observing before completing.
4. Observability. Metrics and alerts that detect a problem before users do.
5. Small changes. This is the connection with Trunk Based Development (lesson 07-05): the smaller the change, the lower the risk and the easier it is to identify the cause.

That last point deserves emphasis, because it is where Git and DevOps touch directly. Continuous deployment forces small, well-scoped commits. If you integrate a change of 2,000 lines and production breaks, you do not know which of the 2,000 it was. All the discipline of module 8 — atomic commits, messages that explain the why, a readable history — goes from being a good practice to being an operational tool.

There are three mechanisms, and it is worth understanding what mental model each one implies.

Mental model: "the main branch is what is on staging". The branch stops being just a line of development and becomes the pointer to an environment.

It is the natural mechanism for non-production environments. Every integration into main updates staging, with no ceremony.

Here what we promised in lesson 05-05 is delivered.

Mental model: "the tag v1.4.0 is a releasable version, and publishing it is deploying it".

Three details that matter a great deal:

1. An annotated tag is required, not a lightweight one. Remember from lesson 05-05 that a lightweight tag is just a reference to a commit, whereas an annotated one is an object in its own right with an author, a date, a message and the option of a signature. For production, that is exactly what you want: a record of who declared that version and when. The git cat-file -t check returns tag for annotated ones and commit for lightweight ones.

2. The signature is verified. git tag --verify checks the GPG signature (lesson 08-05). That way, creating a production tag requires a private key, not just write permissions.

3. It is checked that the tag is on main. git merge-base --is-ancestor prevents deploying a tag placed on a branch that was never integrated. It is a safeguard against the mistake of tagging from the wrong branch, which happens more often than you would think.

Very important: the deployment step rebuilds nothing. It retrieves the artefact that was already built when that commit went into main. We shall come back to this in the next section, because it is one of the golden rules of delivery.

Mental model: "any commit on main is a candidate; somebody decides which one and when".

It is the most flexible mechanism and the one you need in order to go back quickly, as we shall see in section 9.

The three mechanisms combined, each in its place:

This is probably the most important practice in the whole lesson, and the one most teams get wrong.

Every artefact built — container image, package, binary — is tagged with the full hash of the commit it came from.

The hash is the canonical identifier; v1.4.0 and main are readable aliases pointing at it. Exactly the same relationship as in Git between a commit hash and the references that point at it (lesson 03-01): references move, the hash does not.

1. It removes ambiguity. task-manager:latest means nothing: it is a moving tag that points at the last thing somebody built. task-manager:4f8a2e6c9d3b... identifies an exact, reproducible content.

2. It gives complete traceability. Faced with an error in production, the chain is walked from end to end without asking anybody:

From the container in production to the ticket, in five commands and without opening any interface.

3. It makes it possible to verify consistency. Is what we think is deployed actually deployed?

4. It makes idempotent deployment possible. Deploying the same hash twice produces exactly the same result. With latest, there is no way to know.

The artefact is built ONCE and that same artefact travels through every environment.

If every environment rebuilds the artefact, what you tested is not what you deploy. Between one build and the next, the versions of the dependencies, the base image or the compiler version may change. The artefact that passed the tests and the one that reaches production would be two different things, and all the prior validation would stop meaning anything.

What does change between environments is the configuration, which is injected at deployment time: environment variables, secrets, service addresses. The artefact is the same binary; the environment parameterises it.

It is worth having the artefact itself know where it came from:

That git describe --tags --always --dirty is a gem for this. It produces strings such as:

That -dirty suffix is a valuable alarm. An artefact marked as dirty was built from a dirty working copy, which means it is not reproducible from the repository. The pipeline should reject it:

And in the application, expose that information:

A /version endpoint that reports the exact hash being run resolves, on its own, the most frequent question during an incident: "what is actually in there?".

The infrastructure — servers, networks, databases, load balancers, permissions — is declared in versioned text files, and a tool takes care of making reality match what is declared.

Everything Git knows how to do with code now applies to the infrastructure:

That git blame over an infrastructure file is a capability that did not exist ten years ago. The question "why does this service have 512 MB and not 256?" goes from being archaeology to being a command.

The standard practice consists of computing the plan of changes in the proposal — so that it can be reviewed — and applying it only after integration:

Posting the plan on the proposal is what turns infrastructure review into something real: the reviewer does not read a declarative file and imagine the effect, they read the effect: "2 resources will be destroyed, 1 created and 3 modified".

They deserve a separate mention, because this is where the model breaks if you are not careful. Migration files are versioned like everything else:

But there is a fundamental asymmetry: code is easily reverted; data is not. A git revert of the commit that added a column does not bring back the data that column contained.

Hence the golden rule of migrations, which conditions how commits are written:

Every migration must be backwards compatible for at least one deployment. The old version of the code must carry on working with the new schema.

In practice, that turns "renaming a column" into a sequence of three deployments:

1. Add the new column; the code writes to both and reads from the old one.
2. Migrate the data; the code reads from the new one.
3. Remove the old column.

Three commits, three deployments, and at no point a state in which reverting the code breaks the application. It is a perfect example of how operational constraints translate into how commits are split.

GitOps is an operating model with a very specific premise:

The desired state of the system is declared in a Git repository. An agent running inside the system continuously compares the actual state with the declared one and reconciles the differences.

The difference from the above is subtle but important: it is not the pipeline that pushes the changes to the system, but an agent inside the system that pulls them.

The security advantage is decisive and deserves explaining: in the push model, your CI system needs write credentials over production. That makes CI the most valuable target in the organisation. In GitOps, the pipeline only needs permission to write to a Git repository; the agent, which lives inside the system, pulls the changes. Nothing external has access to production.

Deploying is literally making a commit:

The agent detects the commit within seconds and reconciles.

And promotion to production is just as simple:

Notice the elegance: promotion between environments is copying a line from one file to another. Nothing is rebuilt, nothing is re-tagged. It is the literal embodiment of "build once, deploy many times".

If a commit in the state repository deploys to production, then access control over the repository IS access control over production. That forces you to take seriously what we saw in lesson 07-06:

And an organisational consequence: the separation between "application repository" and "state repository" stops being a fad and becomes a security decision. You develop in the first; you deploy in the second. Each with its own permissions.

The most valuable property of GitOps is drift detection. If somebody changes something by hand in production — to "fix it quickly" at three in the morning — the agent detects that the actual state does not match the declared one and reverts it.

It is uncomfortable the first time it happens to you. And it is exactly what should happen: it forces every change to go through Git, which is what keeps the repository being the source of truth. Without that reconciliation, "everything is in Git" is a statement that quietly degrades until it is false.

We pick up lesson 08-05 again with the nuance of automation.

Secrets never go in Git. Not encrypted with a weak password, not "only this test one", not "it is a private repository".

The reason, which you know well by now: in Git, deleting does not remove. A committed secret is in the history forever unless it is rewritten and coordinated with everybody, and even then it has already been exposed to everybody who cloned.

That permissions: id-token: write block deserves explaining, because it is modern practice: instead of storing a long-lived credential in the CI system, the pipeline obtains a short-lived token by proving its identity. If somebody steals that token, it expires within minutes and only works for that repository and that branch.

There is an acceptable pattern, widely used in GitOps, in which secrets do live in the repository but encrypted with a key that is not there:

The encrypted value is in Git; the key to decrypt it lives in a key management service to which only the deployment agent has access. Advantages: the secrets are versioned, reviewed and audited like everything else. Requirement: that the key never enters the repository, and that rotating it is a tested procedure.

As in lesson 08-05, three layers:

Plus the server hook (06-01) and the .gitignore (08-03). And the procedure in case it happens anyway, which always starts with the same thing: revoke the secret first, clean the history afterwards.

Here the investment of lesson 08-01 pays off. Conventional Commits were not just an aesthetic convention: they are structured data that a machine can read.

One feat and one fix with no breaking changes: the next version is 1.4.0.

That git push origin "$VERSION" at the end is what triggers the production deployment pipeline from section 3. The circuit closes: the version comes out of the commit messages, the tag comes out of the version, and the deployment comes out of the tag.

It is the best possible justification for the discipline of module 8. A badly written message is no longer merely ugly: it produces an incorrect version and a changelog that lies.

Something fails. What do you do?

Option A: git revert and deploy again.

Option B: redeploy the previous artefact.

The decisive row is the second: a git revert generates a commit that has never been in production. You are deploying new code to fix an incident. Redeploying the previous artefact means going back to a state you know for certain worked, because it was working ten minutes ago.

And the first row is what decides it in practice: during an incident, the difference between seconds and minutes is the difference between a scare and a post-mortem.

First the service is restored. Then the code is fixed. They are two different activities and mixing them lengthens the incident.

And step 3 is not optional: if you only redeploy the previous version, main still contains the bad change, and the next person's deployment will take it back into production. main has to be left in a healthy state, whether with a revert or with a fix.

Simpler still, because reverting the deployment is reverting a commit in the state repository:

Here it is a git revert, but notice the difference: the deployment commit is reverted, not the code commit. The result is that the state file points back at the previous artefact, which already exists and was already working. It is option B expressed as a commit, with the traceability of option A.

A script like that, tested and with clear permissions, is the difference between a thirty-second rollback and a twenty-minute one spent searching the terminal history at three in the morning. Write it and test it on a Tuesday morning, not during an incident.

• The failure is not urgent: a visual glitch, something affecting few people.
• The previous artefact is not deployable: there was an irreversible data migration in between.
• The bad change is detected before reaching production, on staging.
• You want the history to reflect explicitly that the change was undone.

A final round-up of practices, each with its reason.

If the pipeline is defined in a versioned YAML file, its changes get reviewed, get reverted and have a history. If it is configured by clicking on a website, there is no history, there is no review and nobody knows who changed what.

It is exactly the same principle that governs the whole course: identify by content, not by a moving name. A tag can be moved; a hash cannot.

Running the pipeline twice over the same commit should produce the same result. If the second run fails because "the tag already exists" or "the artefact is already published", the pipeline is not idempotent and any retry turns into a manual intervention.

The message should say what has happened and what to do. An error that only says exit 1 forces people to read the script.

A deployment annotated like that can be investigated in a minute six months later.

Before touching production, verify:

If CI runs npm test and so do you, reproducing a failure is trivial. If CI runs twelve steps written in the YAML that exist in no script, you cannot reproduce anything. Extract the logic into scripts in the repository and have the pipeline merely invoke them.

Protecting main (07-06) is the last barrier. With continuous deployment, a push --force to main can deploy anything. Forbidden, with no exceptions and no "break-glass accounts".

Mistake 1: rebuilding the artefact in every environment. What you test stops being what you deploy. Build once, deploy many times; what changes between environments is the injected configuration.

Mistake 2: using latest as an identifier. It identifies nothing. The full commit hash as the canonical tag, and the readable names as aliases.

Mistake 3: git revert as the first reaction to an incident. It deploys new, untested code to fix an urgent problem. First redeploy the previous version, then fix main.

Mistake 4: forgetting fetch-depth: 0 when the pipeline uses git describe or compares branches. It is the mistake of lesson 10-04: with a shallow clone there are no tags and no merge base. And in large repositories, fetch-depth: 0 + filter: blob:none.

Mistake 5: secrets in the repository "because it is private". A private repository has dozens of clones, replicas, backups and CI systems with access. The rule admits no nuance.

Mistake 6: lightweight tags for production. No author, no date, no message, no signature. And they can be moved with git tag -f, something an annotated, signed tag object makes far harder to disguise.

Mistake 7: changing production by hand. It creates drift and the repository stops being the source of truth. If an urgent change is unavoidable, the corresponding commit is made immediately afterwards, without exception.

Mistake 8: database migrations that are not backwards compatible. They make rollback impossible. It is the operational constraint that most conditions how commits are split.

Tip 1: expose /version in the application. With the commit hash. It answers "what is really in production?" without access to the deployment system.

Tip 2: write the rollback script before you need it. And test it. On a Tuesday morning.

Tip 3: use git describe --dirty to detect non-reproducible builds. The -dirty suffix means that artefact cannot be rebuilt from the repository: reject it.

Tip 4: separate the application repository from the state repository. Different permissions, a separate audit history, and less chance of a code change touching production by accident.

Tip 5: a dashboard comparing what is deployed with main. git rev-list --count $DEPLOYED..origin/main says how many commits are waiting. It is the metric for "how much value is sitting idle".

Tip 6: sign your production tags. That way creating a version requires a private key, not just write permissions on the repository.

The team wants:

• Every integration into main deploys automatically to staging.
• Production is deployed only on creating an annotated, signed tag vX.Y.Z.
• The artefact is built once and reused.
• It must be possible to roll production back in under a minute.

Write the pipeline (or pipelines) in YAML, indicating which Git checks you include at each point and why. Explain the complete flow of a change, from the proposal to production.

It is 03:12. Alert: task-manager is returning error 500 in production. The only thing you know is that the deployed container is:

Write the sequence of commands to:

1. Identify which version it is and what changes it contains.
2. Determine whether the problem came in with the latest deployment.
3. Find the suspect commit.
4. Roll production back.
5. Leave main in a healthy state.

Explain in what order you would do it and why.

Review this pipeline and point out all the problems, ordered by severity, explaining what can go wrong and how you would fix it:

Solution 1

Pipeline 1: integration (already exists, from lesson 07-06). Tests and linter on every proposal, main protected.

Pipeline 2: build and deploy to staging.

Checks included and why:

Pipeline 3: production by tag.

Pipeline 4: fast rollback (the "under a minute" requirement).

It is fast precisely because it builds nothing: the artefact has existed since the day that commit went into main.

The complete flow of a change:

1. Ana creates GT-231-hidden-filter, works, opens the proposal.
2. CI runs tests and linter (07-06). Bruno reviews and approves.
3. It is integrated into main (protected branch, squash).
4. Pipeline 2 builds the artefact :4f8a2e6... once and deploys to staging.
5. The team validates on staging.
6. When it is time to release: ./tools/next-version.sh computes v1.4.0 from the Conventional Commits, the changelog is generated and git tag -a -s v1.4.0 is created.
7. Pushing the tag triggers pipeline 3, which verifies and deploys the artefact already built in step 4.
8. If something fails: pipeline 4 with v1.3.0, in seconds. Afterwards, git revert on main at leisure.

Solution 2

The order matters enormously, and it is counter-intuitive: first the service is restored, then you investigate. But with one caveat: steps 1 to 3 cost seconds and give you the information needed to roll back with judgement.

If the tag was created at 03:05 and the alert fired at 03:12, the problem came in with this deployment. That correlation is what justifies rolling back rather than investigating.

Why here and not later: every minute of investigation is a minute of downtime. The v1.3.0 artefact was working until twenty minutes ago: it is the zero-risk option.

Why NOT to git revert now: it would generate a new commit, which would have to be built (minutes), tested and deployed, and that artefact has never been in production. It is exactly what you do not want during an incident.

With only three commits, bisect is overkill; you would use it on a range of fifty. Here, reading the three diffs is faster.

Why step 9 is compulsory: if all you did was redeploy v1.3.0, main still contains the fault. The next person to release a version will take it back to production without knowing. Rolling back the deployment restores the service; only step 9 fixes the problem.

Solution 3

Eight problems, from most to least serious.

1. CRITICAL — A secret in plain text in the script.

The production database password is in a versioned file, in the history forever, visible to everybody who clones, and probably in the logs of every run of the pipeline. It violates lesson 08-05 in the most direct way possible.

Fix: revoke the password right now (before anything else), store it in the secrets manager, inject it as an environment variable from the CI system and, if the repository is public or has been cloned, clean the history with git filter-repo (08-05).

2. CRITICAL — Deployment to production with no barrier whatsoever.

Any integration into main goes straight to production, with no environment, no approval, no pre-flight checks, no staging. A badly reviewed one-line change reaches users in two minutes.

Fix: split into two pipelines (integration to staging by branch; production by annotated, signed tag), and declare environment: production with mandatory reviewers.

3. SERIOUS — latest as an identifier.

It identifies nothing. Impossible to know what is running, impossible to roll back to a specific version, impossible to reproduce a problem. And an obvious race condition: if two integrations happen back to back, the second may overwrite latest while the first is deploying.

Fix: tag with the full commit hash and use the readable names only as aliases.

4. SERIOUS — It rebuilds on every deployment and there is no build/deploy separation.

There is no staging environment, so what reaches production has never been tested deployed. And since it is built right here, there is no way of guaranteeing that the production artefact is the same one that passed the tests.

Fix: build once with the hash, deploy that same artefact to staging and then to production.

5. SERIOUS — The version comes out of a VERSION file and the tag is lightweight.

Three problems in three lines:

• A lightweight tag (git tag without -a): no author, no date, no message, no signature.
• It fails if the version did not change: git tag over an existing tag errors and breaks the pipeline. It is not idempotent.
• The VERSION file is updated by hand: somebody will forget.

Fix: compute the version from the Conventional Commits (section 8) and create an annotated, signed tag:

6. MEDIUM — actions/checkout@main.

A reference to a moving branch: what the pipeline runs can change without anybody deciding it. It is a supply chain and reproducibility risk.

Fix: pin by hash. And add fetch-depth: 0 if tags or comparisons are going to be used.

7. MEDIUM — No checks and no subsequent verification.

It checks nothing before touching production, and verifies nothing afterwards. The notification says "Deployed" whatever happens, because the curl runs regardless: there is no if: success(), and there is no check that the service responds.

Fix: pre-flight checks (commit on main, clean copy, artefact exists) and a liveness check against /version confirming the deployed hash.

8. MINOR — ssh with docker compose as the deployment mechanism.

No version control of the state, no rollback, no progressive deployment, no logging. If the SSH connection drops halfway, the state is left indeterminate.

Fix: a deployment script versioned in the repository (infra/deploy.sh) that is idempotent and logs what it does; and in the medium term, consider GitOps (section 6), which additionally removes the need for the pipeline to hold production credentials.

Summary of the fix: this pipeline does everything in one job with no barriers, with a secret in plain text and with no reproducible identification of the artefact. The correct rewrite is the one from exercise 1: separate build from deployment, identify by hash, require an annotated and signed tag for production, inject secrets from the manager, and add verification before and after.

Git stops being a developers' tool and becomes the central piece of operations.

• The repository becomes the single source of truth: not just code, but also infrastructure, per-environment configuration, migrations and the definition of the pipelines themselves. The rule: if something can break production, it must be in Git; and if it is in Git, it must not be changed outside Git. With one absolute exception: secrets.
• Continuous integration, delivery and deployment are distinguished by where the human button is: integration guarantees that what goes in works, delivery that what is on main can be deployed, and deployment that it is deployed. Removing the button is a decision about confidence, and it demands reliable tests, rollback in minutes and small changes.
• A deployment is triggered by branch (staging), by an annotated, signed tag (production, closing 05-05) or by manual approval over a commit. The checks that matter are pure Git: git cat-file -t to require an annotated tag, git tag --verify for the signature, and git merge-base --is-ancestor to require that it is on main.
• The artefact is identified by the full commit hash, and it is built once and deployed many times. It is the same idea that underpins the whole of Git: identify by content, not by a name that moves. From that comes complete traceability — from container to ticket in five commands — and the git describe --dirty that detects non-reproducible builds.
• Infrastructure as code gives servers everything Git knows how to do: history, blame, review, revert. And database migrations impose the constraint that most conditions commits: they must be backwards compatible for at least one deployment, because code gets reverted and data does not.
• GitOps reverses the direction: an agent inside the system pulls the declared state and reconciles. It gains on security (the pipeline holds no production credentials), it detects and corrects drift, and it turns the Git history into the audit trail. In exchange, access control over the repository is access control over production, and protected branches stop being a recommendation.
• Secrets are injected, never versioned; and modern practice replaces long-lived credentials with short-lived tokens obtained through federated identity.
• Automatic versioning and changelog cash in the investment of 08-01: Conventional Commits are structured data out of which come the SemVer version, the changelog and — via the tag — the deployment.
• And rolling back in production is almost always redeploying the previous artefact, not git revert: the previous artefact was working ten minutes ago and is ready in seconds, whereas a revert generates new untested code that has to be built and deployed. First the service is restored; then main is left healthy, which is not optional.

The idea running through the whole lesson:

In an organisation with automated deployment, git push stops meaning "I have saved my work" and comes to mean "this will reach users". All the rigour of the course — atomic commits, messages that explain the why, a clean history, annotated tags, protected branches — stops being a professional virtue and becomes an operational requirement.

You now know how to use Git in every context that exists today: alone, in a team, in enormous projects and in automated production. One last question remains, and it is the most honest one that can be asked at the end of a technical course: how much of this will still be true in ten years' time?

Git is not standing still. There are things that already exist and you can use today even though hardly anybody knows about them: a new reference format that replaces refs/ and packed-refs, a git that can work with SHA-256 instead of SHA-1, the partial clones and the sparse index we have just seen, and the consolidation of switch and restore over the old checkout. And there are things that are trend or speculation, which are worth distinguishing clearly from the former.

There is also something that almost certainly is not going to change, and it is precisely what you learnt in module 1: the content-addressable data model, the directed acyclic graph of commits and the distributed nature. That is why what you have learnt does not expire.

Lesson 10-06: The Future of Git closes the course: what is mature and what is a promise, where the tools are pointing, how to carry on learning on your own, and a complete recap of the road travelled.