GitLab仓库使用Artifactory LFS存储时推送被预接收钩子拦截问题

问题背景 #

公司GitLab仓库大小上限为5G（包含Git LFS数据），因此尝试使用Artifactory作为Git LFS存储。Artifactory可正常接收LFS数据，但GitLab的pre-receive钩子因未检测到LFS对象而拒绝推送。已按官方指南配置.lfsconfig、关闭仓库LFS选项，但问题仍存在，且无GitLab服务器管理员权限。

解决方案 #

方案1：让GitLab不识别LFS指针为LFS对象（无管理员权限可行） #

GitLab的pre-receive钩子检查LFS对象的前提是识别仓库中的文件为官方LFS指针格式。可通过以下方式规避：

• 本地保留LFS配置：继续使用.gitattributes（标记*.zip filter=lfs diff=lfs merge=lfs -text）和.lfsconfig，确保本地LFS正常工作，将大文件推送到Artifactory。
• 避免提交LFS标记到GitLab：在仓库根目录的.gitignore中添加.gitattributes条目，阻止该文件被推送到GitLab。
• 协作说明：若需共享仓库，将.gitattributes和.lfsconfig的配置单独文档化，告知协作者在本地自行创建这两个文件。

此方法下，GitLab会将LFS指针视为普通文本文件，不会触发LFS对象检查，从而允许推送。

方案2：彻底重置GitLab仓库的LFS状态 #

若关闭仓库LFS选项后仍无效，尝试重置远程仓库状态：

1. 登录GitLab仓库设置页面，确认LFS选项中"Enable LFS"已关闭并保存。
2. 本地执行命令清空远程分支（注意：此操作会删除远程仓库现有内容，需谨慎）：

   git push --force origin :main
   

3. 重新推送本地分支：

   git push origin main
   

此操作可让GitLab重新识别仓库的LFS禁用状态，跳过LFS对象检查。

方案3：使用自定义Git过滤器替代官方LFS（进阶） #

若上述方案不适用，可自行实现Git的smudge/clean过滤器，将大文件存储到Artifactory，同时让GitLab仅保留自定义格式的指针：

1. 在本地.git/config中配置自定义过滤器：

   [filter "custom-lfs"]
     clean = "curl -X PUT -T - https://artifactory-server/artifactory/custom-lfs/$(sha256sum | cut -d' ' -f1)"
     smudge = "curl https://artifactory-server/artifactory/custom-lfs/$(cat)"
   

2. 修改本地.gitattributes使用自定义过滤器：

   *.zip filter=custom-lfs diff=custom-lfs merge=custom-lfs -text
   

3. 将.gitattributes提交到GitLab（此时指针为自定义格式，GitLab不会识别为LFS对象）。

此方法需自行实现文件上传下载逻辑，适合具备Git底层知识的用户。

内容的提问来源于stack exchange，提问作者devopsdinosaur