使用Git LFS的Git引用仓库持续维护及命令选择咨询

针对你在Jenkins上维护Git引用仓库的场景，结合你使用的Git 2.15.1.windows.2和Git LFS 2.3.4版本，我来梳理下不同命令的适用情况，帮你解决维护任务工作量过大的问题：

核心前提：初始填充 vs 日常维护的区别 #

首先要明确：git lfs fetch --all只适合初始填充阶段使用——因为它会拉取远程仓库所有历史LFS对象，这也是你觉得工作量巨大的原因。完成初始填充后，日常维护完全不需要全量拉取，只需要同步新增或近期的LFS对象即可。

不同命令的具体分析 #

• git lfs fetch --all：仅用于首次填充LFS目录，执行一次就够，绝对不要放到日常维护任务里，否则每次都会遍历拉取所有历史大文件，资源消耗极高。
• git lfs fetch（无参数）：在Git LFS 2.3.4版本中，这个命令只会拉取当前检出分支关联的远程分支里的LFS对象，以及本地已有的分支、标签对应的LFS对象。如果你的引用仓库是用于多分支同步的，这个命令可能会漏掉其他分支新增的LFS对象，不太适合作为通用维护命令。
• git lfs fetch --recent：这是最适合日常维护的选项！它默认会拉取最近7天内所有提交里的LFS对象，同时也会同步所有远程分支的最新提交中的LFS对象。既能保证核心的近期对象同步，又不会触发全量拉取，工作量可控。如果7天的周期不符合你的需求，还可以自定义天数，比如git lfs fetch --recent=30拉取最近30天的对象。

推荐的维护任务配置 #

1. 初始填充（仅执行一次）：

   git lfs fetch --all
   

2. 日常维护任务（定期执行）：
   建议和git fetch --all配合，先同步Git引用，再拉取对应的LFS对象，命令顺序如下：

   git fetch --all
   git lfs fetch --recent
   

额外验证建议 #

你可以先在测试环境或者临时克隆的引用仓库里测试git lfs fetch --recent的输出，确认它只拉取了预期的近期对象，工作量在可接受范围内后，再替换到Jenkins的维护任务中。

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