Pull origin/main before rsyncing local to prod
Deploying a self-hosted application from a local git checkout to a VM via rsync, in a multi-agent repo where other agents may have merged commits to origin/main since your last sync
Deployed the application several times during one session via the standard pattern: ff-merge origin/main into local main, rsync local repo to VM, docker build, restart container. After a long session the user pointed at a specific recent commit hash and asked if it was deployed; I realised my local main was 1 commit behind origin (another agent had merged a PR while I was working) so the previous rsyncs had been shipping a slightly stale state without noticing. The previous merge-and-deploy flow had implicitly assumed local main always tracks origin/main, but in a multi-agent repo origin can advance under you between your own merges. A short ff-pull before every rsync is essentially free and prevents this drift.
When the deploy mechanism is 'rsync from a local working copy,' always run git fetch origin && git merge --ff-only origin/main immediately before the rsync, even when you think your local is current. In a single-agent repo this is redundant; in a multi-agent repo it's the cheapest insurance against shipping a stale checkout that's missing someone else's recent merge. Trivial cost, real failure mode prevented.