> Because git is intended for source code and not as a way to make stateful changes to servers, there are no features for that. If you push a commit that didn't

> Because git is intended for source code and not as a way to make stateful changes to servers, there are no features for that. If you push a commit that didn't do what you mean, it will just blindly do it. git doesn't do anything (except keep versioned source of declarative state). Instead, have a look at your state engine, and make it as safe as you care to. > because infrastructure isn't a stateless function of your git repository So we agree, there's your problem. Not git, but the state engine function. While you don't need K8s, for GitOps to work you do need a structured approach for operating your infrastructure. These concepts can help: https://operatorframework.io/about/ https://operatorframework.io/about/ “It is relatively easy to manage and scale web apps, mobile backends, and API services right out of the box. Why? Because these applications are generally stateless, so scripts can scale and recover infrastructure from failures without additional knowledge.” “A larger challenge is managing stateful applications, like databases, caches, and monitoring systems. These systems require application domain knowledge to correctly scale, upgrade, and reconfigure while protecting against data loss or unavailability. We want this application-specific operational knowledge encoded into software … to run and manage the application correctly.” Start by looking at the Operator Capability Level diagram here: https://sdk.operatorframework.io/docs/overview/ https://sdk.operatorframework.io/docs/overview/ You can iterate your ability to operate from desired state through those stages, with focus on the ones that hurt the most (by risk or by repetition).