Production Capstone: Design, Secure, Scale, and Recover a Governed Git Workflow: Requirements, Constraints, and Target Architecture

1. The capstone problem: operate Git as a governed change system

Individual commands are not an operating model. A production team needs explicit answers for who may update which refs, how proposed work is reviewed, how releases are named, how automation proves exact source provenance, how secrets and signing keys are kept out of source, how lost work is recovered, how performance is maintained, and how a failed server is restored.

This capstone integrates the previous 25 chapters into one local, no-account simulation. Git mechanics come first; hosted controls such as protected branches, required checks, permissions, merge queues, and CI token scopes remain server/platform responsibilities.

2. Read-only evidence before any operational change

git --version
git status --porcelain=v2 --branch
git rev-parse --verify HEAD^{commit}
git show-ref
git for-each-ref --sort=refname --format='%(refname) %(objectname)'
git reflog -10 --all
git remote -v
git config --list --show-origin --show-scope
git count-objects -vH
git fsck --full

These commands establish worktree/index state, exact commit identity, refs, recent local ref motion, remote destinations, effective configuration, storage shape, and object/connectivity integrity. They do not prove authorization, signer identity, credential secrecy, or successful deployment.

3. Atlas Service requirements and roles

In the mandatory lab these are separate local clones. In production the server must enforce the intended permissions.

4. Target topology

flowchart TD
C[Contributor clone] -->|topic push| S[(Bare central server)]
I[Integrator clone] -->|reviewed integration| S
B[Release bot] -->|release-state ref| S
S -->|exact commit| R[Detached CI runner]
S -->|desired commit| G[Reconciler]
G --> A[Applied-state marker]
S --> U[Verified full bundle]
S --> M[Recovery mirror]

The arrows represent controlled state transitions. CI and reconciliation consume immutable commits; automation writes only its dedicated ref; backup copies are independently verified.

5. Collaboration and integration policy

Contributors may rewrite unpublished private topic work. Once a ref is shared for review, the reviewed tip must be identified by immutable OID. The integrator compares the exact proposal against the current target, runs validation, and advances the shared integration ref without overwriting unseen work. A hosted pull request is an optional policy/UI layer around these Git mechanics.

6. Release policy

A release tag is a human-facing name for an immutable object. Published release tag names are treated as immutable. Release automation writes metadata to a dedicated branch/ref using ordinary fast-forward history. If a published tag is wrong, the policy prefers a new corrected version instead of silently retargeting the old name.

7. Recovery objectives

• The recovery artifact must contain every intended ref in the final snapshot.
• A replacement bare repository must be reconstructable without the original server.
• Source and restored refname + objectname snapshots must match for the governed namespace.
• Incident response must not expire reflogs or prune unreachable objects while evidence is needed.

8. Trust boundaries

9. Automation identity, authentication, signing, and authorization are separate

user.name and user.email are commit metadata. SSH/HTTPS credentials authenticate to a server. Cryptographic signatures attest a payload under a configured key. Server rules decide whether that identity may update a ref. Do not collapse these controls into one notion of “trusted bot.”

10. CI provenance is branch-independent

COMMIT=$(git rev-parse --verify HEAD^{commit})
TREE=$(git rev-parse --verify HEAD^{tree})
CLEAN=$(test -z "$(git status --porcelain=v1)" && echo true || echo false)
printf 'commit=%s\ntree=%s\nclean=%s\n' "$COMMIT" "$TREE" "$CLEAN"

The exact commit OID is durable provenance; branch/event names are contextual labels. Do not assume fixed 40-character SHA-1 IDs.

11. GitOps separates desired from applied state

desired_commit = source ref resolved to an immutable commit
candidate       = validated artifact/config being applied
applied_commit  = last commit applied successfully
observed_state  = what the target system currently reports

Git stores desired state; Git itself does not prove that deployment succeeded.

12. Scale choices target measured bottlenecks

The capstone uses a modest repository, so it demonstrates measurement and safe auxiliary maintenance instead of claiming a synthetic speedup.

13. Retention, auditability, and operational ownership

Reflogs, unreachable objects, bundles, mirrors, and old server copies aid recovery but can also retain sensitive history. Assign owners for retention, signing trust, credential rotation, secret scanning, maintenance, backup verification, restore drills, and hosted policy. For integrations/releases, capture source OID, target ref before/after, validation result, and signature state where required.

14. Measurable acceptance criteria

15. Runbooks and failure injection

A runbook records preconditions, evidence commands, mutation steps, expected outcomes, rollback criteria, and verification. Failure injection is useful only when it is isolated and recoverable; the capstone never asks learners to damage valuable repositories.

16. DevOps connection

A governed repository is part of the software supply chain. Git provides local/distributed mechanics; servers, CI, deployment systems, and organization policy complete the control plane. The goal is an auditable system another operator can understand and recover.

17. Knowledge check

18. Summary

The target architecture is a governed set of roles, refs, trust boundaries, automation paths, scale choices, recovery artifacts, runbooks, and measurable acceptance evidence.

Authoritative references

• Git documentation
• git-push
• git-fsck
• signature formats
• git-maintenance