GitOps方程中的CI那一半允许开发人员快速推出对这些配置文件的调整和改进；当自动化软件代理竭尽全力确保应用程序的实时版本能够反映配置文件中的描述时，CD这一部分会以GitOps语言趋向于声明式模型。
GitOps和Kubernetes正如我们所提到的，GitOps的概念最初是围绕管理Kubernetes应用而出现的。通过我们现在对GitOps的了解，让我们重温一下Weaveworks的GitOps讨论，看看他们是如何描述如何对基于GitOps原则管理的Kubernetes进行更新的。下面是对整个流程的总结：
一个开发者为一个新功能提出Git 拉取请求。
审查和批准代码，然后将其合并到主代码库中。
合并会触发 CI/CD 流水线、自动测试和重建新代码，并将其部署到仓库。
软件代理注意到更新，从仓库中提取新代码，并更新配置仓库中的配置文件（用YAML编写）。
Kubernetes集群中的软件代理根据配置文件，检测到集群已经过时，拉取更改，并部署新功能。
Weaveworks和GitOps显然，这里的第4步和第5步做了很多繁重的工作。将Git仓库中的 "真理来源 "与现实世界中的Kubernetes应用进行神奇同步的软件代理，就是让GitOps成为可能的魔法。正如我们所说，在GitOps术语中，让实时系统更像配置文件中描述的理想系统的过程叫做融合。当实时系统和理想系统不同步时，那就是分歧。理想情况下，融合可以通过自动化流程来实现，但自动化所能做的事情是有限度的，有时人工干预是必要的。
我们在这里用通用术语描述了这个过程，但事实上，如果你真的去看Weaveworks的页面，我们提到的 “软件代理” 是该公司Weave Cloud平台的一部分。“GitOps” 这个词是由Weaveworks的CEO Alexis Richardson创造的，它的部分作用是让Weaveworks平台对已经沉浸在DevOps和CI/CD世界的开发者有吸引力。
但Weaveworks从未宣称自己垄断了GitOps，GitOps更多的是一种理念和一套最佳实践，而不是某种具体的产品。 正如提供CI/CD解决方案的公司CloudBees的博客所指出的那样，GitOps代表了一种开放的、厂商中立的模式，它是针对亚马逊、谷歌和微软等大型云厂商推出的管理型专有Kubernetes解决方案而开发的。CloudBees提供了自己的GitOps解决方案，这个领域的另一些玩家也是如此。
GitOps和DevOpsAtlassian是一家为敏捷开发者制造了许多工具的公司，它有一篇关于GitOps的历史和目的的深度博文（https://www.atlassian.com/git/tutorials/gitops ），值得你花时间去了解。在他们看来，GitOps代表了作为devops的理念的逻辑延伸。具体来说，GitOps是对基础架构即代码（IaC）这一概念的阐述，而基础架构本身就是DevOps环境下产生的一种思想。在Atlassian看来，GitOps弥补了现有DevOps技术与分布式、云托管应用的特殊需求之间的关键差距，现有DevOps技术是为了解决系统管理问题而发展起来的。各个云厂商提供的自动融合是GitOps的特别之处。
虽然GitOps今天仍然专注于Kubernetes，但我们希望我们已经明确了它如何适用于更广泛的分布式、基于云的应用世界。开源安全厂商WhiteSource的一篇博文概述了GitOps的优势：
可观察性：GitOps系统为复杂的应用提供了监控、日志、跟踪和可视化功能，因此开发人员可以看到什么地方出现了故障，在哪里出现了故障。
版本控制和变更管理：很明显，这是使用Git这样的版本控制系统的一个关键优势。有缺陷的更新可以轻松回滚。
易于采用：GitOps建立在许多开发人员已经掌握的开发技能之上。
提高生产力：GitOps 可以像开发项目和 CI/CD 那样提高工作效率。
审计：有了Git，每一个操作都可以追踪到一个特定的提交，这样就可以很容易地追踪到错误的原因。
即使你不使用Kubernetes，GitOps也很有可能迟早会成为你工作流程的一部分。