git merge --allow-unrelated-histories卡顿无响应问题排查及预防咨询

• LFS对象的同步与校验开销：仓库包含Git LFS对象时，合并操作需要校验大量大文件的哈希值、确认本地对象完整性；若LFS对象未提前拉取到本地，Git会尝试后台拉取，加上Windows系统IO性能限制，极易导致长时间无响应。
• 无关历史的合并计算量过大：从SVN迁移的仓库历史结构与纯Git仓库存在差异，结合git-filter-repo --to-subdirectory-filter的路径重写操作，Git在处理--allow-unrelated-histories合并时，需要遍历并对比两个仓库的全部历史提交、重映射文件路径，计算量呈指数级增长。
• 系统资源不足：合并过程需要大量CPU和内存资源，若Windows环境下有其他高负载进程运行，Git进程会因资源抢占陷入假死状态。
• 未完成的仓库清理：git-filter-repo操作后未清理仓库冗余对象，导致仓库体积膨胀，进一步增加合并时的磁盘IO和计算负担。

• 提前同步LFS对象：在执行合并前，切换到projectA仓库目录，执行git lfs pull确保所有LFS对象已下载到本地，避免合并时因拉取远端对象卡住。
• 优化仓库状态：
  • 在projectA目录执行git gc --aggressive --prune=now，压缩仓库、清理冗余提交和对象，减少合并时的计算量。
  • 改用git subtree add替代普通合并：在projectB目录执行git subtree add --prefix=projectA projectA master，该命令针对子目录合并做了优化，处理LFS对象和重写历史的仓库更高效。
• 临时调整LFS配置：合并前执行git config lfs.skipverify true跳过LFS对象哈希校验，完成合并后再执行git config lfs.skipverify false恢复校验，可大幅降低合并耗时。
• 保障系统资源：关闭Windows后台不必要的高负载进程，确保Git进程能获取足够的CPU和内存资源；若仓库规模极大，可考虑在性能更强的机器上执行合并操作。
• 简化合并逻辑：若projectB为空仓库，无需执行合并操作，直接将projectA的分支作为projectB的基础分支：

  cd C:\GitHub\projectB
  git remote add projectA C:\Work\GitHub\projectA
  git fetch projectA master
  git checkout -b master projectA/master
  git remote remove projectA
  

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