GitHub Actions中git ls-remote需fetch的原因及取最新标签最优方案

背景 #

我正在优化GitHub Actions流水线，需要从Git仓库获取最新标签。最初使用的命令如下，虽然有效但因为仓库过大，git fetch耗时过长：

git fetch --prune --unshallow --tags
TAG=$(git describe --tags --abbrev=0) # 获取最新标签

于是我优化为以下命令，在本地完整克隆的仓库中运行正常，但在GitHub Actions环境中报错：

git ls-remote --tags --sort=committerdate | grep -o 'v.*' | sort -r | head -1

报错信息：

fatal: missing object <object-id> for refs/tags/<tag-name>

即使删除远程仓库中的问题标签，错误仍存在。但在执行git ls-remote前添加git fetch --tags --prune步骤后，问题消失。

疑问与解答 #

1. 本应独立于本地仓库工作的git ls-remote，为何在GitHub Actions环境中需先执行git fetch --tags --prune才能正常工作？

git ls-remote本身确实直接查询远程仓库的引用，但在GitHub Actions使用actions/checkout@v4并设置fetch-depth: 1时，会创建浅克隆的本地仓库，默认不会拉取标签。虽然ls-remote不依赖本地对象，但如果本地仓库存在陈旧的标签引用缓存（比如流水线残留或浅克隆导致的不完整引用），Git在处理ls-remote输出时可能会尝试解析本地已有的标签引用，而这些引用对应的对象在浅克隆中不存在，就会抛出"missing object"错误。执行git fetch --tags --prune会清理本地陈旧的标签引用，并拉取远程当前的标签元数据，避免Git解析无效的本地引用。

2. 这是否与缓存、陈旧引用或Git的其他行为有关？

是的，主要和陈旧引用以及浅克隆特性有关：

• 陈旧引用：GitHub Actions工作目录可能残留旧的本地引用（即使actions/checkout默认清理，某些场景下仍可能存在），或者浅克隆本身保留了不完整的标签引用记录，这些记录指向不存在的对象。
• Git行为：执行git ls-remote时，Git可能会同步更新本地refs/remotes/origin/下的引用，若本地已有同名标签引用但对象缺失，就会触发错误。--prune参数会删除本地存在但远程已移除的引用，刚好解决这个问题。

3. 无需拉取所有标签的情况下，获取最新标签的最优方案是什么？

推荐两种无需拉取完整标签对象的方案：

方案1：优化git ls-remote命令，绕过本地引用干扰

直接指定远程仓库地址，避免本地缓存的影响，同时优化排序和匹配逻辑：

git ls-remote --tags --sort=-committerdate https://github.com/<你的用户名>/<仓库名>.git | grep -E 'refs/tags/v[0-9.]+$' | head -n 1 | sed 's/.*refs\/tags\///'

• --sort=-committerdate直接按提交时间倒序，无需额外sort -r
• 用正则refs/tags/v[0-9.]+$精确匹配正式版本标签，避免匹配到带^的轻量标签或注释标签引用
• 最后用sed提取纯标签名

方案2：调整actions/checkout参数，仅拉取标签元数据

修改actions/checkout配置，添加fetch-tags: true拉取标签引用（不会下载标签对应的大对象）：

- uses: actions/checkout@v4
  with:
    fetch-depth: 1
    submodules: true
    fetch-tags: true # 仅拉取标签引用，不下载标签关联的对象

之后直接用以下命令获取最新标签：

TAG=$(git tag --sort=-committerdate | head -1)

内容的提问来源于stack exchange，提问作者Hyeon Ho Park