对于今天的大多数开发者来说，使用Git就像呼吸一样，没有它你就无法生存。伴随着版本控制，Git的使用近年来甚至扩展到了GitOps领域，或者说通过Git管理和版本配置。很多用户没有意识到或没有想到的是，Git不仅跟踪每次提交的文件变化，而且还跟踪提交和分支的大量元数据。你的DevOps可以利用这些数据，或者利用软件开发的最佳实践来实现IT操作的自动化，比如说CI/CD。
关于Git的更多信息
在我的案例中，我使用了一个自动化流程（DevOps），每次我将一个镜像推广到Kubernetes的下游CI/CD环境（命名空间）时，都会创建一个新的分支（这里是我在Opensource.com上描述该流程的文章的无耻插件）。这使我能够在独立于其他环境的下游CI/CD环境中修改特定部署的部署描述符，并使我能够对这些变化进行版本管理（GitOps）。
我将讨论一个典型的场景，即在QA中发现了一个破坏性的bug，而没有人确定是哪个构建引入了这个bug。我不能也不想依靠镜像元数据在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-* 是基于命名规则的。
<descriptive-prefix>-<deployment-env>-<dev-branch-commit-hash>
开发人员或QA人员在运行CI/CD重新部署管道时可以使用返回的信息，以决定在Kubernetes命名空间中回滚/前进到哪个版本，从而最终返回到已知的良好状态。这个过程缩小了在假想场景中引入破坏性错误的时间和内容。
虽然上面的命名惯例和场景是针对需求和自动化CI/CD流程的，但还有其他更普遍有用的方法来使用for-each-ref 。许多组织有类似于以下的分支命名惯例。
<version>-<feature-or-bug>-<feature-or-bug-id>
ID值指的是在Rally或Jira等项目管理系统中描述该功能或错误的ID；例如。
v1.23-feature-12345
根据开发过程和分支命名惯例的政策，这个ID允许用户轻松快速地获得一些额外的可视性，以了解版本库和项目的更大开发历史（使用refs/remotes/**/v.123-feature-* ）。这个过程也适用于标签，所以列出最新的pre-prod、prod或其他特定的版本几乎可以轻松完成（并非所有标签都是默认提取的）。
总结
这些只是使用for-each-ref 的特殊和狭隘的例子。 从作者到提交信息，官方文档提供了可以搜索、过滤和报告的许多细节的洞察力。
