An Argo CD Application sets spec.source.targetRevision. What are the practical differences between pointing it at a branch, a tag, and a full commit SHA?

## What the field actually resolves to `spec.source.targetRevision` is not a fixed pointer to content; it is a *query* that Argo CD re-resolves against the repository on every refresh — roughly every three minutes by default, and immediately when a repository webhook arrives. The value you write determines how often the answer to that query can change underneath you. ## Branch (including HEAD) ```yaml source: repoURL: https://github.com/acme/manifests.git path: apps/checkout/overlays/dev targetRevision: main ``` A branch name means "whatever the tip of that branch is right now". Combined with `syncPolicy.automated`, merging to `main` *is* the deploy. `HEAD` is the same idea, resolved to the repository's default branch. The strength is immediacy and zero ceremony. The weakness is that the deployed content is decided by whoever merges next, and the Application manifest gives no evidence of what is running. Two clusters pointing at the same branch can be running different commits simply because they refreshed at different moments. And a rollback means pushing a revert commit — you cannot roll back by editing the Application, because the Application does not name a version. ## Tag A tag such as `v1.8.3` gives the Application a human-meaningful, normally stable name. It is the natural fit for promotion: cut a release, tag it, point the production Application at the tag. Argo CD's history and the manifest both now say something intelligible about what is deployed. The caveat candidates miss is that a Git tag is a mutable reference. `git tag -f` plus a force-push relocates it, and nothing in Argo CD notices anything other than "the revision resolved to a different commit". An annotated, signed and host-protected tag is much stronger than a lightweight one, but the immutability lives in your repository host's protection rules, not in Git and not in Argo CD. ## Full commit SHA ```yaml source: targetRevision: 9f2c1de5a3b64c7ef4a02f8b1cd7e6a5b0d3f214 ``` A full 40-character SHA is content-addressed: that string can only ever mean that tree. The Application is now a precise, auditable statement of what production runs, and a rollback is a one-line edit back to the previous SHA. This is the same reasoning as pinning a container image by digest instead of by tag. The cost is that something must now update the SHA. In practice that something is a promotion pipeline or an image-update automation opening a pull request against the environment's Application manifest — which is the point: the promotion becomes a reviewable change rather than an invisible consequence of a merge somewhere else. Note that Argo CD also accepts short SHAs and, for Git sources, certain other revision expressions; a full SHA is what you want when the goal is an unambiguous audit trail. ## Helm repositories are the same problem in different clothes When `repoURL` is a Helm chart repository or an OCI registry and you set `chart:` rather than `path:`, `targetRevision` is the *chart version*, and it accepts semver ranges. `targetRevision: 1.2.*` looks tidy and behaves exactly like a branch: a new upstream patch release deploys itself. For anything you care about, pin the exact chart version. ## Choosing per environment The common shape is a gradient rather than one rule: - **dev / preview** — track a branch. Fast feedback matters more than knowing precisely what is running. - **staging** — track a release branch or a tag, so what you test is what you will ship. - **production** — pin a tag or a SHA, updated by an explicit, reviewed change. The deeper principle is that promotion should be a *change to a pinned reference*, not the passage of time. If every environment tracks `main`, you do not have environments; you have one environment with lag. ## The diagnostic angle When an Application deployed something nobody expected, the first question is what `targetRevision` resolves to and when it last changed. `argocd app get` shows the resolved revision, and the app's sync history records which revisions were synced, so you can tell "the branch moved" from "someone changed the Application".