我如何使用 Git for-each-ref 命令进行 DevOps

对于当今大多数开发人员来说，使用 Git 就像呼吸一样，没有它就无法生存。 除了版本控制之外，Git 的使用近年来甚至扩展到了 GitOps 领域，即通过 Git 管理和版本控制配置。 很多用户没有意识到或者考虑的是，Git 不仅跟踪每次提交的文件更改，还跟踪围绕提交和分支的大量元数据。 您的 DevOps 可以利用这些数据，或者使用软件开发最佳实践（例如使用 CI/CD）来自动化 IT 运维。

就我而言，我使用一个自动化流程（DevOps），每次我将镜像提升到 Kubernetes 中的下游 CI/CD 环境（命名空间）时，都会创建一个新分支（这里是我 Opensource.com 文章 的一个无耻的宣传，描述了该过程）。 这使我可以独立于其他环境修改下游 CI/CD 环境中特定部署的部署描述符，并使我能够对这些更改进行版本控制（GitOps）。

我将讨论一个典型的场景，即在 QA 中发现了一个破坏性错误，没有人确定是哪个构建引入的。 我不能也不想依靠镜像元数据来查找 Git 中保存正确部署描述符的分支，原因有很多，尤其是考虑到我可能需要搜索一个本地仓库或多个远程镜像。 那么，如何轻松地利用 Git 仓库中的信息来找到我正在寻找的东西？

使用 for-each-ref 命令

这个场景是 for-each-ref 命令真正有用武之地的地方。 它允许我搜索所有 Git 仓库的分支，通过我使用的命名约定进行过滤（强制在创建分支时使用命名约定是一个好理由），并按降序返回最近修改的分支。 例如

$ git clone git@github.com:elcicd/Test-CICD1.git
$ cd Test-CICD1
$ git for-each-ref --format='%(refname:short) (%(committerdate))' \
                   --sort='-committerdate' \
                   'refs/remotes/**/deployment-qa-*'
origin/deployment-qa-c6e94a5 (Wed May 12 19:40:46 2021 -0500)
origin/deployment-qa-b70b438 (Fri Apr 23 15:42:30 2021 -0500)
origin/deployment-qa-347fc1d (Thu Apr 15 17:11:25 2021 -0500)
origin/deployment-qa-c1df9dd (Wed Apr 7 11:10:32 2021 -0500)
origin/deployment-qa-260f8f1 (Tue Apr 6 15:50:05 2021 -0500)

上面的命令克隆了一个我经常用来测试 Kubernetes 部署的仓库。 然后，我使用 git for-each-ref 按上次提交的日期搜索分支，将搜索范围限制在与 QA 环境的部署分支命名约定匹配的分支，并返回最近的五个分支。 这些大致（即不一定，但足够接近）对应于我要重新部署的组件/微服务的最后五个版本。

deployment-qa-* 基于以下命名约定

<描述性前缀>-<部署环境>-<开发分支提交哈希>

运行 CI/CD 重新部署管道时，开发人员或 QA 人员可以使用返回的信息来决定在 Kubernetes 命名空间中回滚/前进到哪个版本，从而最终返回到已知良好的状态。 在人为设计的场景中，此过程缩小了何时以及什么引入了破坏性错误。

虽然上面的命名约定和场景特别适合需求和自动化 CI/CD 流程，但还有其他更通用的方法来使用 for-each-ref。 许多组织都有类似于以下内容的分支命名约定

<版本>-<功能或错误>-<功能或错误 ID>

ID 值是指在项目管理系统（如 Rally 或 Jira）中描述功能或错误的 ID； 例如

v1.23-feature-12345

取决于开发过程和分支命名约定策略，此 ID 允许用户轻松快速地了解仓库和项目的更广泛的开发历史记录（使用 refs/remotes/**/v.123-feature-*）。 此过程也适用于标签，因此几乎可以轻松地列出最新的预生产、生产或其他特定版本（并非所有标签都默认拉取）。

总结

这些只是使用 for-each-ref 的特定和狭隘的示例。 从作者到提交消息，官方文档 提供了对可以搜索、过滤和报告的许多细节的深入了解。