jitpack 无法拉取 github 仓库的新发布版本（如 v0.5），却能正常识别旧版本（如 v0.2），根本原因常是 git 仓库历史过大（>500mb），触发 jitpack 的浅克隆限制或超时机制。
JitPack 在构建时会对 GitHub 仓库执行 git clone --depth=1（浅克隆）以提升性能，但当仓库存在大量历史提交、大文件或冗余二进制资产（如旧构建产物、日志、IDE 配置等）时，即使指定 tag，JitPack 后端仍可能因无法高效定位 commit 或下载超时而失败——尤其在新 tag 基于较深历史分支创建时。而旧版本（如 v0.2）可能恰好位于浅层提交附近，因此“侥幸”通过。
你遇到的 Could not find com.github.Recessive:repo:v0.5 并非 Gradle 缓存问题（手动访问 https://www./link/5429ee7f1bb3ae94e7042acad2375136/com/github/Recessive/repo/v0.5/build.log 可确认构建是否真正触发），而是 JitPack 根本未能成功检出该 tag 对应的代码，因而未生成有效 Maven artifact。
✅ 推荐解决方案：创建无历史的孤儿分支（orphan branch）
# 1. 创建不继承任何历史的空分支 git checkout --orphan fresh-build-branch # 2. 清理暂存区（保留当前工作区文件） git rm -rf . # 3. 重新添加全部文件（保持内容不变，但脱离历史） git add . git commit -m "Initial commit for JitPack compatibility" # 4. 推送至远程（无需强制） git push origin fresh-build-branch
随后在 build.gradle 中引用该分支的快照版本：
dependencies {
compileOnly 'com.github.Recessive:repo:fresh-build-branch-SNAPSHOT'
}
⚠️ 注意：-SNAPSHOT 后缀必须与分支名严格一致（区分大小写），且需确保该分支下有 build.gradle / pom.xml 等构建配置文件。JitPack 会自动构建该分支最新 commit，并生成可解析的坐标。
? 额外建议（预防性优化）：
- 使用 git filter-repo 彻底清理历史中的大文件（比 BFG 更现代可靠）；
- 在 .gitattributes 中配置 *.jar filter=lfs diff=lfs merge=lfs -text，配合 Git LFS 管理二进制资产；
- 避免在主分支频繁合并巨型 PR；为发布构建单独维护轻量 release 分支；
- 检查 JitPack 控制台（https://www./link/5429ee7f1bb3ae94e7042acad2375136 → Your Repos）中对应 tag 的构建日志，重点查看 Cloning into '/home/jitpack/build'... 后是否出现 fatal: unable to access ... 或 timeout。
? 总结：JitPack 的“静默失败”源于其对仓库健康度的强依赖。与其反复试错版本号，不如主动精简 Git 历史——一个干净的孤儿分支，往往比十次 git push --force 更可靠。
