Git & Version Control: CGOA practice questions

Git and version control matter in GitOps because the repository is the state store, and the OpenGitOps glossary asks a state store for three things: immutable versions of the desired state, access control, and auditing of changes. Most Git practices in this topic are ways of meeting those requirements.

History is the audit trail. Every commit records an author, a time and the exact change, so questions such as what changed before an incident and who approved it are answered from the log. Because commits are versioned rather than overwritten, rolling back is a matter of reverting to an earlier version and letting the agent reconcile.

Access control is enforced at the repository, and repository layout is part of it: Flux's guide on repository structure describes a dedicated production repository as a way to limit the scope of changes and who may make them.

Repository structure has several accepted shapes, and the Flux guide names four. A monorepo stores all Kubernetes manifests in one Git repository, with environments as directories on the same branch such as main. A repository per environment isolates production. A repository per team lets a platform team own shared infrastructure while application teams own their configuration. A repository per application keeps the source code and its deployment manifests together, with the fleet configuration pointing at them. The same guide favors trunk-based development, where branches besides main are short-lived; long-lived per-environment branches are a possible design, but not the one the Flux examples use.

Signed commits add provenance. Flux's GitRepository has an optional verify field that checks OpenPGP or SSH signatures against a Secret holding the public keys of trusted authors. Mode HEAD verifies the commit at the checked-out reference, Tag verifies the tag object, and TagAndHEAD verifies both. If verification fails, the source is not marked verified and the controller keeps retrying with exponential backoff instead of producing an artifact.

Pinning references keeps history meaningful. A GitRepository can track a branch, a tag, a semver range or a specific commit, and a commit takes precedence over the other fields. Argo CD's best practices warn that pointing at HEAD of a remote base is not a stable target and recommend a tag or commit SHA.

Secrets are the exception to storing everything in Git. Kubernetes warns that checking a Secret manifest into a repository makes the value available to everyone who can read it, and that base64 is not encryption. Keep secrets out of the repository, or store only an encrypted form such as a SealedSecret.