在过去十年的编程中，出现了一些革命性的转变。其中之一是源于围绕DevOps的实践，它将开发和运维团队整合到一个共享的工作流程中，此外还有持续集成和持续交付（CI/CD），通过CI/CD，Devops团队可以向代码库提供持续的更新。另一个变革来自于从单体代码库到基于云的微服务的迁移，这些微服务运行在由Kubernetes等编排平台管理的容器中。
即使有Kubernetes这样的平台来编排协调，在集群系统或云端运行的基于容器的应用程序依旧可能是复杂的、难以调配和管理的。GitOps是一套新兴的实践，旨在通过应用Devops和CI/CD世界的技术来简化这一管理任务。
GitOps的关键是基础设施即代码（IaC）的理念，它采用与DevOps用于提供应用程序一样的方法来提供基础设施。所以，不仅是应用，还有底层的主机和网络都被描述在文件中，这些文件可以像版本控制系统中的其他代码一样，然后由自动化流程来将现实世界的应用与这些文件中描述的应用进行融合。
用GitOps的说法，版本控制系统中的代码是关于应用在生产中应该是什么样子的唯一真相来源（single source of truth）。
定义GitOpsWeaveworks是在GitOps概念普及方面贡献最大的公司。稍后我们会详细介绍Weaveworks在其中扮演的角色，但首先，我们先来看看该公司对GitOps的定义，它有两个方面：
Kubernetes和其他云原生技术的运维模式，为统一部署、管理和监控容器化集群和应用提供了一套最佳实践。
GitOps是一条通往管理应用的开发者体验之路；在这里，端到端的CI/CD流水线和Git workflow可以同时应用于运维和开发。
换句话说，GitOps是一套特定的实践，旨在管理Kubernetes和类似的平台。随着越来越多的开发团队采用DevOps实践，并将代码迁移到云端，GitOps也将会适合更广泛的应用。但要了解GitOps的秘诀和它所能解决的问题，我们需要谈谈它的组成部分。
Git定义在GitOps中Git指的是由Linus Torvalds在2005年开发的极为流行的分布式版本控制系统。Git是一个工具，它允许开发者团队在一个应用程序代码库上共同工作，存储各种代码分支，在将它们合并到生产代码之前，他们可以对这些代码进行修补。Git 的一个关键概念是拉取请求，即开发人员正式要求将他们正在编写的一些代码整合到代码库的另一个分支中。
Git 拉取请求为团队成员提供了一个协作和讨论的机会，然后再就是否应该将新代码添加到应用程序中达成共识。Git 还会存储旧版本的代码，如果出了问题，可以很容易地回滚到上一个好的版本，并可以让你快速查看两次修改之间的变化。Git 最为人所知的部分可能是作为GitHub 这一云端托管版本控制系统的底层，但 Git 本身也是一个开源软件，可以部署在任何地方，无论是公司内部的服务器还是你的PC。
需要注意的是，虽然我们通常认为Git是一个计算机编程工具，但实际上取决于你如何使用它。Git 很乐意将任何文本文件作为你的 “代码库”，例如，它可以被作者用来记录合作作品的编辑情况。这一点很重要，因为GitOps的核心代码库大多由声明式配置文件而非可执行代码组成。
在我们继续之前，最后要强调一件事——尽管名字中就有 “Git”，但GitOps实际上并不必要使用Git。 已经投入使用其他版本控制软件（如Subversion）的团队也可以实现GitOps。但在Devops领域，Git被广泛用于实现CI/CD，所以大多数GitOps项目最终都会使用Git。
什么是CI/CD流程？关于CI/CD的完整解释其实不在本文讨论的范围内，但是因为CI/CD是 GitOps 工作的核心，因此我们需要对其进行简单的介绍。CI/CD中的一半持续集成是由版本控制仓库（如Git）实现的。开发者可以对代码库进行持续的小改进，而不是每隔几个月或几年就推出巨大的、单一的新版本。持续部署这一块是通过被称为流水线（pipeline）的自动化系统来实现的，这些流水线可以构建、测试和部署新的代码到生产中。
同样，我们在这里一直在谈论代码，这通常会让人联想到用C语言、Java或JavaScript等编程语言编写的可执行代码。但在GitOps中，我们所管理的 “代码” 主要是由配置文件组成的。这不是一个小细节，而是GitOps工作的核心。正如我们所说，这些配置文件是描述我们的系统应该是什么样子的 “唯一真理来源（single source of truth）”。它们是声明式的，而不是指导性的。这意味着，配置文件不会说 “启动十台服务器”，而会简单地说 “这个系统包括十台服务器”。