Production Capstone: Design, Secure, Scale, and Recover a Governed Git Workflow: Implementation and Automation Build-Out

1. Create the disposable Atlas topology

All work stays below one lab directory. The bare repository acts as the server; contributor, integrator, release bot, and runner are isolated clones.

mkdir git-governance-capstone
cd git-governance-capstone
git init --bare -b trunk central.git
git clone central.git source
git -C source config user.name "Learner Example"
git -C source config user.email "learner@example.invalid"

2. Seed source, desired state, tests, and operations metadata

mkdir -p source/app source/environments/lab source/docs
printf "message=atlas\n" > source/app/app.conf
printf "replicas=2\nversion=1\n" > source/environments/lab/service.env
printf "owner=platform\nrto_minutes=30\n" > source/docs/operations.conf
cat > source/validate.sh <<'EOF2'
#!/bin/sh
replicas=$(sed -n 's/^replicas=//p' environments/lab/service.env)
version=$(sed -n 's/^version=//p' environments/lab/service.env)
test -n "$replicas" && test "$replicas" -ge 1 && test -n "$version"
EOF2
git -C source add .
git -C source commit -m "seed Atlas service and operations model"
git -C source push -u origin trunk

3. Create contributor and integrator clones

SERVER_URL="file://$(pwd)/central.git"
git clone "$SERVER_URL" contributor
git clone "$SERVER_URL" integrator
git -C contributor config user.name "Atlas Contributor"
git -C contributor config user.email "contributor@example.invalid"
git -C integrator config user.name "Atlas Integrator"
git -C integrator config user.email "integrator@example.invalid"

These names become commit metadata only. A production server would authenticate and authorize independently.

4. Contributor creates and publishes a reviewable topic

git -C contributor switch -c topic/health
printf "health=true\n" > contributor/app/health.conf
git -C contributor add app/health.conf
git -C contributor commit -m "add health configuration"
TOPIC_OID=$(git -C contributor rev-parse HEAD)
git -C contributor push -u origin topic/health

5. Integrator reviews the exact proposed tip

git -C integrator fetch origin
git -C integrator log --graph --oneline --decorate refs/remotes/origin/trunk..refs/remotes/origin/topic/health
git -C integrator diff --stat refs/remotes/origin/trunk...refs/remotes/origin/topic/health
git -C integrator switch --detach refs/remotes/origin/topic/health
test "$(git -C integrator rev-parse HEAD)" = "$TOPIC_OID"
sh -c 'cd integrator && sh validate.sh'

This simulates Git-level review evidence, not a hosted pull request.

6. Integrate through a normal reviewed merge

git -C integrator switch trunk
git -C integrator merge --no-ff refs/remotes/origin/topic/health -m "merge reviewed health topic"
INTEGRATED_OID=$(git -C integrator rev-parse HEAD)
git -C integrator push --dry-run --porcelain origin trunk
git -C integrator push origin trunk

A normal push protects unseen non-fast-forward updates.

7. Create and publish the release name

sh -c 'cd integrator && sh validate.sh'
git -C integrator tag -a v1.0 -m "Atlas v1.0" "$INTEGRATED_OID"
git -C integrator rev-parse v1.0^{commit}
git -C integrator push --dry-run --porcelain origin refs/tags/v1.0
git -C integrator push origin refs/tags/v1.0

8. Optional signing/verification with a temporary OpenPGP key

If gpg exists, use an isolated temporary keyring. Skip this section if the backend is unavailable.

if command -v gpg >/dev/null 2>&1; then
  mkdir -m 700 .gnupg-capstone
  export GNUPGHOME="$(pwd)/.gnupg-capstone"
  gpg --batch --passphrase '' --quick-gen-key "Atlas Release Lab <atlas-release@example.invalid>" rsa2048 sign 1d
  SIGNING_KEY=$(gpg --batch --with-colons --list-secret-keys atlas-release@example.invalid | awk -F: '$1=="sec" {print $5; exit}')
  git -C integrator config user.signingKey "$SIGNING_KEY"
  git -C integrator tag -s v1.0-signed -m "Atlas v1.0 signed lab" "$INTEGRATED_OID"
  git -C integrator verify-tag v1.0-signed
fi

Production signing needs protected key storage and explicit trust policy; this key is disposable.

9. Create a shallow CI-like runner, then pin exact source

git clone --depth=1 --no-tags --branch trunk "$SERVER_URL" runner
REQUESTED_OID=$(git -C central.git rev-parse refs/heads/trunk)
git -C runner switch --detach "$REQUESTED_OID"
git -C runner rev-parse --verify HEAD^{commit}
git -C runner status --porcelain=v2 --branch
git -C runner rev-parse --is-shallow-repository
sh -c 'cd runner && sh validate.sh'

10. Record provenance and build from exact HEAD

COMMIT=$(git -C runner rev-parse --verify HEAD^{commit})
TREE=$(git -C runner rev-parse --verify HEAD^{tree})
SHORT=$(git -C runner rev-parse --short HEAD)
CLEAN=$(test -z "$(git -C runner status --porcelain=v1)" && echo true || echo false)
printf "commit=%s\ntree=%s\nclean=%s\n" "$COMMIT" "$TREE" "$CLEAN" > provenance.txt
git -C runner archive --format=tar -o "atlas-$SHORT.tar" HEAD

11. Create an automation-owned release-state branch

git -C integrator switch -c release-state trunk
printf "source_commit=%s\nstatus=candidate\n" "$INTEGRATED_OID" > integrator/release.env
git -C integrator add release.env
git -C integrator commit -m "initialize release state"
git -C integrator push -u origin release-state
git -C integrator switch trunk

12. Release bot performs a guarded normal update

git clone "$SERVER_URL" release-bot
git -C release-bot config user.name "Atlas Release Automation"
git -C release-bot config user.email "release-bot@example.invalid"
git -C release-bot switch release-state
printf "source_commit=%s\nstatus=released\n" "$INTEGRATED_OID" > release-bot/release.env
git -C release-bot add release.env
git -C release-bot commit -m "mark Atlas v1.0 released"
git -C release-bot fetch origin release-state
BASE=$(git -C release-bot rev-parse refs/remotes/origin/release-state)
git -C release-bot merge-base --is-ancestor "$BASE" HEAD
git -C release-bot push --dry-run --porcelain origin HEAD:refs/heads/release-state
git -C release-bot push origin HEAD:refs/heads/release-state

No force option is needed because the design is monotonic.

13. Integrity and safe performance validation

git -C central.git fsck --full
git -C integrator fsck --full
git -C integrator count-objects -vH
git -C integrator commit-graph write --reachable --changed-paths
git -C integrator commit-graph verify
git -C integrator maintenance run --task=commit-graph
test "$(git -C integrator rev-parse refs/heads/trunk)" = "$INTEGRATED_OID"

No prune-now or aggressive cleanup is used.

14. Create and verify an offline recovery bundle

git -C central.git bundle create full-recovery.bundle --all
git -C central.git bundle list-heads full-recovery.bundle
git init --bare -b trunk bundle-verifier.git
git -C bundle-verifier.git bundle verify ../central.git/full-recovery.bundle

15. Prove offline restore completeness for Git refs

git clone --mirror central.git/full-recovery.bundle restored-from-bundle.git
git -C central.git for-each-ref --sort=refname --format='%(refname) %(objectname)' > central-refs.txt
git -C restored-from-bundle.git for-each-ref --sort=refname --format='%(refname) %(objectname)' > restored-refs.txt
git diff --no-index -- central-refs.txt restored-refs.txt
git -C restored-from-bundle.git fsck --full

16. Create a mirror recovery copy

git clone --mirror central.git recovery-mirror.git
git -C recovery-mirror.git remote update --prune
git -C recovery-mirror.git fsck --full

This is a local copy; no mirror push is required.

17. Secret-safe credential boundary

The local remote needs no token. Production bots should use a secure helper or platform secret injection, never token-bearing remote URLs. Build-only automation should remain read-only.

18. Challenge

1. A topic moved after review. What must be reviewed again?
2. A normal bot push is rejected. What must happen before any rewrite?
3. A bundle restores Git refs but the project uses LFS/submodules. What remains?
4. CI can build exact HEAD but lacks a release tag. What should it fetch if version derivation requires that context?

19. Knowledge check

20. Summary

You implemented reviewed integration, release naming/signing path, exact detached CI provenance, a dedicated bot ref, integrity checks, safe maintenance, and verified bundle/mirror recovery.

Authoritative references

• git-push
• git-tag
• signature formats
• commit-graph
• git-bundle