Production Capstone: Design, Secure, Scale, and Recover a Governed Git Workflow: Security, Governance, and Reliability Validation

1. Governance begins with effective configuration evidence

git config --list --show-origin --show-scope
git config --show-origin --get user.name
git config --show-origin --get user.email
git config --show-origin --get pull.rebase
git config --show-origin --get merge.ff
git config --show-origin --get-all credential.helper
git config --show-origin --get-all safe.directory
git config --show-origin --get gpg.format
git config --show-origin --get commit.gpgSign
git config --show-origin --get tag.gpgSign

System, global, local, worktree, environment, and command-line configuration can all affect behavior. Policy should describe intended effective behavior, not assume a single file is authoritative.

2. Developer baseline

Set explicit author identity, but keep authentication outside commit metadata. Developers may configure editors/pagers/aliases for convenience; shared policy should focus on settings that affect integration, trust, safety, or automation.

git config --global user.name "Learner Example"
git config --global user.email "learner@example.invalid"

3. Automation baseline

Read-only CI should not inherit a personal profile or signing key. A write-capable bot should use repository-local metadata identity plus isolated credentials. Noninteractive jobs must declare exact checkout/fetch requirements and must not depend on an editor prompt.

4. Branch and ref ownership policy

5. Merge/rebase policy

Rebase is appropriate for private unpublished topics because only the author consumes those commit IDs. Shared integration/release refs should be stable. Document whether integration uses merge commits, fast-forward, squash, or another convention; do not let automation silently choose per run.

6. Force-update policy

Default policy is no force update. If an approved rewrite is unavoidable, current Git's most explicit lease form records the exact expected remote value:

git push --force-with-lease=refs/heads/topic/example:EXPECTED_OID \
  origin HEAD:refs/heads/topic/example

7. Credential and least-privilege policy

Build runner: read-only repository access. Release bot: write only the owned release-state ref. Deployment reconciler: source read plus separate target-system permission. Use secure OS/platform helpers or short-lived credentials; never embed tokens in repository URLs or logs.

8. Signing and trust policy

Document whether commits, release tags, or both require signatures; allowed format (OpenPGP, X.509, SSH); trusted signer mapping; key rotation/revocation; and where verification occurs. commit.gpgSign and tag.gpgSign can enable defaults, but they do not provision trust or authorization.

9. safe.directory ownership policy

Git's ownership protection should remain enabled. Fix runner/container ownership where possible; otherwise add only the exact intentionally shared workspace in protected configuration. Wildcard safe.directory=* is not the standard workaround.

10. Secret policy: prevention → rotation → remediation

Prevent secrets through secret managers, synthetic examples, local/CI scanning, and review. If a real credential is committed, revoke/rotate it first. Preserve evidence and inventory refs/copies, then rewrite affected history using a current tool such as git filter-repo in a fresh disposable remediation clone. Git's own filter-branch manual recommends alternatives because of safety/performance pitfalls.

11. Integrity and transfer checks

git fsck --full
git commit-graph verify
git multi-pack-index verify

Run auxiliary checks only when the structures exist. A clean fsck is not malware scanning, signature verification, or authorization policy.

12. Maintenance and retention policy

Current maintenance supports scheduled/incremental work. Prefer measured background tasks for long-lived repositories. During active recovery/forensics, hold destructive expiry/pruning so recovery evidence remains available.

13. Large-repository policy

14. Dependency policy

Submodules are separate repositories. LFS stores large content outside ordinary Git objects. Server-side hooks, branch rules, hosted issues/PRs/releases/packages, CI variables, and deployment state are also external. Every one needs an owner in backup/migration/restore plans.

15. Backup, restore, and migration policy

Periodically create a verified full bundle for the governed refs and restore it into a separate repository. Compare exact ref names/OIDs and run fsck. A mirror can complement the bundle, but neither reproduces hosted metadata or external stores automatically.

16. Server/hosting enforcement boundary

The local capstone cannot enforce protected branches, required reviews/checks, merge queues, environment approvals, organization permissions, hosted scanning, or CI token scopes. Implement those later in GitHub/GitLab/server-specific policy while retaining the portable Git-level invariants taught here.

17. Worked decision table

18. Knowledge check

19. Summary

The governed design now covers configuration, branch/rewrite rules, credentials/signing/trust, secret response, ownership trust, integrity, maintenance/scale, dependencies, backup/restore, and platform enforcement.

Authoritative references

• git-config
• git-push
• history-filtering warning
• git-maintenance
• git-fsck