Git克隆GitLab指定分支卡在Checking out files 37%进度如何解决

第一步：定位卡点阶段 #

首先执行无工作区检出的克隆命令，排除网络、服务端问题：
git clone --no-checkout -b <你的目标分支名> <GitLab仓库地址>

• 如果这一步能顺利完成，说明仓库对象拉取全程正常，卡点出在本地工作区文件写入环节，和GitLab服务端、网络链路无关。主分支克隆无异常、仅目标分支固定卡37%的表现，基本可以确定是目标分支独有的某个文件触发了本地写入阻塞，该文件刚好位于检出进度的37%节点位置。
• 如果这一步也卡住，直接联系GitLab管理员检查服务端磁盘、仓库权限配置即可。

第二步：定位具体触发问题的文件 #

进入上一步拉取完成的本地仓库目录，开启Git调试日志后执行检出，定位最后卡住时正在处理的文件：

• Linux/macOS终端执行：
  GIT_TRACE=1 git checkout <你的目标分支名>
• Windows PowerShell执行：

  $env:GIT_TRACE=1
  git checkout <你的目标分支名>
  

命令执行停止后，最后一条日志输出的文件路径，就是导致卡顿的直接诱因。

常见问题及对应解决方法 #

• 问题1：目标分支存在超大单文件/Git LFS未正确配置
  这是此类固定进度卡顿的最高发原因：如果目标分支提交了几百MB到数GB级别的二进制文件、数据集、压缩包，且没有走Git LFS存储，Git在写入这类大文件时如果碰到磁盘IO不足、安全软件扫描占用文件，就会长期处于假死状态。
  解决方式：

  1. 先执行git lfs install完成Git LFS全局初始化，再尝试重新检出
  2. 如果该大文件是业务不需要的冗余文件，联系仓库管理员在目标分支清理对应大文件后重试
  3. 临时需要拉取分支代码的话，可以用稀疏检出跳过对应大文件/目录：

     git sparse-checkout init --cone
     git sparse-checkout set /* !<问题大文件/所在目录的路径>
     git checkout <你的目标分支名>
     

• 问题2：Windows系统长路径限制拦截
  Windows默认对路径长度超过260字符的文件有访问限制，Git写入这类路径的文件时会被系统拦截反复重试，表现为进度卡住。
  解决方式：

  1. 以管理员身份打开PowerShell，执行命令开启系统长路径支持：
     New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
  2. 执行Git全局配置放开长路径限制：
     git config --global core.longpaths true
  3. 重启终端后重新执行克隆、检出操作。

• 问题3：安全软件锁文件拦截
  部分杀毒软件、企业终端管控软件会对Git写入工作区的文件做实时扫描，碰到可执行文件、脚本类文件时会锁定文件做深度检测，导致Git一直拿不到文件写入权限卡住。
  解决方式：临时关闭安全软件的实时扫描功能，或者将Git程序、本地仓库目录加入安全软件白名单后重试。

• 问题4：分支存在损坏的二进制对象
  如果之前有人推送分支时出现过本地仓库损坏、推送中断的情况，可能将损坏的二进制对象提交到了远端，Git解析这类损坏对象时会无限等待。
  解决方式：联系GitLab管理员在服务端对应仓库执行git fsck --full做完整性校验，定位到损坏对象后，让对应提交的提交者重新上传正确文件覆盖错误提交即可。

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