Kubernetes允许我们单纯地使用声明性的配置文件来管理我们的应用部署和其他基础设施组件（例如，我们现在都是YAML开发者）。这使我们能够把所有这些文件放到Git仓库中，然后把它挂到流水线上（Jenkins、GitLab等），流水线会把这些变化应用到集群上，然后就有了GitOps。如果你还不了解GitOps是什么，可以查看我们之前发布过的文章： GitOps初阶指南：将DevOps扩展至K8S
为了使工作正常进行，我们必须确保改变集群的唯一方法是在Git仓库上提交。GitOps并不是专门针对Kubernetes的，同样的原理也可以应用于任何其他声明式配置管理的环境。
可以说，很多企业已经开始采用GitOps了，但现在是业界开始充分认识到其潜力的时候。所以，让我们深入了解一下它如此出色的原因吧！
1、存储环境变更历史记录
只有通过更新相应Git仓库中的配置，才能改变应用环境。这将创建一个完整的状态变化的历史记录，包括谁做了更改和为什么更改的记录。你可以通过正在使用的Git用户界面来读取历史记录。
2、轻松回滚到之前的状态
一旦我们所有的变更都被存储为Git历史记录，就可以很容易地将一个环境回滚到之前的任何状态。通过还原一些commit，我们可以回到以前的工作状态。
3、保障部署安全
一旦对集群的所有更改都通过GitOps repo，用户和持续集成(CI)流程就不需要再访问集群了。这大大降低了攻击面，尤其是还可以减少对Kubernetes api的网络访问。
部署过程无论如何实现，都可以在集群内部运行，并从Git中拉取配置。其对API的访问使用基于角色的访问控制（RBAC）进行限制。这极大地提高了集群的安全性，防止任何恶意的远程更改在API服务器上。
4、轻量化审批程序
在修改生产环境时，开发人员总是不受信任。因此在许多公司中都建立了四眼审批流程（four-eyes approval processes），不论是出于什么原因建立的审批流程，GitOps都提供了一个简单的方法来实现它们。
具体实现方式取决于你使用的Git服务器，但重点是给开发人员在Git repo上创建拉取请求的权利，同时给另一组人审查和合并的权利。大多数Git服务器都有一个很好的UI来检查修改和批准拉取请求——所以这个解决方案不仅便宜，而且对用户也相当友好。
5、模块化架构
GitOps有3个部分：Git repo、部署流程以及一个在Git repo中自动更新版本的过程。这三者可以相互独立演化或替换。
一边是一个组件在Git repo写入，另一边是一个组件在读取。Git repo的结构成为这些组件之间的桥梁。由于这是一个相当松散的耦合，两边可以用不同的方式甚至不同的技术栈来实现。
6、独立于工具的架构
第5点中提到的模块化可以看出GitOps架构是一个可以灵活组装最佳工具的架构。当然，任何流行的Git服务器都可以完成Git部分的工作，FluxCD或ArgoCD可以负责将repo同步到集群。JenkinsX是一个处理这个过程所有部分的工具，包括创建Git repos，并在构建新的Docker镜像时用新版本更新它们。
7、复用现有知识
将 Git 置于部署流程的核心，可以充分利用大多数开发人员和运维人员已经掌握的 Git 知识。不需要新的工具来浏览部署历史或实施审批流程。所有的流程都是用大家都熟悉的工具来完成的。
8、比较不同的环境
当你有一个从开发到用户接受度测试（UAT）再到生产的环境链时，跟踪这些环境之间的差异是一件很麻烦的事情。多亏了存储在Git repos中的声明式配置，它使得处理环境间差异就像比较一组YAML文件一样简单。
我们有非常棒的工具来做这件事，所以这将不再是一个问题。更重要的是，从头开始创建一个新的环境，就像复制和粘贴这些文件到一个新的repo中一样简单。
9、开箱即用的备份
由于你的环境状态存储在Git中，如果Kubernetes上的etcd发生了什么事情，你也永远不会丢失数据。因为它是你集群状态的自然备份。
10、像应用程序代码一样测试你的更改
你可以用测试应用程序代码的方式来测试环境中可能出现的破坏性变化。将更改放在一个分支上，然后在其上运行 CI 流水线。你的 CI 工具将能够运行测试，并根据测试结果将 Git 中的 pull-request 状态设置为绿色或红色。一旦所有的东西都经过测试和审查，你就可以合并到master。
这听起来非常简单，但自动化测试是基础设施管理中经常被忽视的任务。虽然GitOps并没有让它变得更容易，但至少它为你提供了与你在其他地方使用的相同的熟悉工作流程。
11、高可用部署基础设施
部署基础设施保持一致很重要。Git repo服务器通常已经以复制、高可用的方式进行了设置。源代码是所有开发人员在大多数时间都需要访问的东西，所以使用Git作为部署的源码并不会给Git本身增加额外的负担。
原文 http://dockone.io/article/10738
git入门操作,git命令的基本使用
Git是一个免费的、开放源码的分布式版本控制系统，它能以快速和效率处理从各种各样的项目。（一句话概括，就是分布式版本控制工具）
通过git命令，上传本地文件到git服务器
把本地代码上传到git的方法:步骤一：首先进入需要上传的项目文件夹，通过命令git init初始化,步骤二：将本地文件添加到版本库中，使用命令 git add . 将文件提交到本地的暂存区,步骤三：使用命令git commit将文件提交到本地仓库...
Git忽略规则文件.gitignore_关于.gitignore配置
.gitignore 文件的作用就是告诉git, push的时候忽略指定的文件夹或者文件，例如：vue-cli脚手架创建的项目，push到github上时，不会上传node依赖文件夹，这是因为vue-cli脚手架创建的时候，自动为我们创建了 .gitignroe文件，并且为我们写好了规则。
git从远程仓库克隆dev分支到本地的实现
这篇文章主要介绍git从远程仓库拉取dev分支到本地的实现【gitLab】：初始化一个本地仓库、与远程仓库建立连接 、查看本地是否具有dev分支、在本地创建分支dev并切换到该分支 、dev分支上的内容都拉取到本地
git强制覆盖master分支
在开发中，通常会保持两个分支master分支和develop分支，但是如果因为develop上面迭代太多而没有及时维护master，最后想丢弃master而直接将测试确认过的develop强推到master，该怎么操作呢？因此，做如下总结分享，希望对遇到同样问题的人用帮助。
Git 中 Reset、Revert、Checkout的区别
git reset 、 git checkout 和 git revert 是Git中常用命令。经常傻傻分不清他们之间的区别。最近工作不忙，抽出时间参考了其他文档，对其总结了下。传给 git reset 和 git checkout 的参数决定了它们的作用域。
git workflow
Git与SVN的比较,Gitflow为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。新的功能分支应该从develop分支迁出一个feature分支，新功能开发完成之后再合并回develop分支，常用命令：
项目中常用的git指令
1.新建一个本地分支并切换到新建的那个分支：2.从一个分支切换到另一个分支：3.将代码恢复到最近的一次commit 时候的状态：4.将代码从最近的一次commit的状态恢复到最新的进度：
总结Git 不同情况下撤销和如何回滚
在未进行git push前的所有操作，都是在“本地仓库”中执行的。我们暂且将“本地仓库”的代码还原操作叫做“撤销”,进行git push，即已推送到“远程仓库”中。我们将已被提交到“远程仓库”的代码还原操作叫做“回滚”！注意：对远程仓库做回滚操作是有风险的，需提前做好备份和通知其他团队成员！
.gitignore的使用手册
避免将不必要的文件添加到版本管理系统中，比如前端的node_modules目录，该目录包含大量文件，如果将其添加到版本管理系统中，会使仓库变的庞大，不利于仓库的管理。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!