Git Extensions Resolving deltas: 100%卡住问题

本文介绍了解决使用GitExtensions克隆项目时遇到的卡顿问题,特别是当进度达到100%后仍无法完成的情况。问题源于PUTTY0.63.0.0版本在SSH通讯上的改动,文中提供了具体的解决方案。

最近下载安装最新的Git以后,配置好Git,用Git Extensions克隆项目的时候,会出现克隆中,然后进度条到100%,目录已经生成,但是,就是一直不成功,左上角显示Resolving deltas: 100%情况。这时候开始怀疑git配置问题。但是检查发现git配置没有任何问题。

这是图片描述

后来,在网上查了下资料,然后发现。PUTTY 0.63.0.0版本在SSH通讯上面有点小改动,通讯上面加上了winadj的交互,而winadj干嘛用的呢,这个是用来测量服务器的往返时间,来调整它的流量控制。克隆的时候,最后会等待winadj的响应,但是请求一直等不到应答,然后就会一直等待下去,给人感觉就是卡主了。

这里写图片描述

那么既然如此,问题就好解决了,只需要找个0.63.0.0以下版本的plink.exe替换,或者修改plink.exe指定路径就好了

这里写图片描述

其实,如果出现这种情况,多等一会也就没问题,这个不会影响克隆的内容,等超时时间过了,就会自动断开连接,然后克隆完成。

Total 1937 (delta 518), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 0% (0/518) remote: Resolving deltas: 1% (7/518) remote: Resolving deltas: 2% (11/518) remote: Resolving deltas: 3% (16/518) remote: Resolving deltas: 4% (21/518) remote: Resolving deltas: 5% (26/518) remote: Resolving deltas: 6% (34/518) remote: Resolving deltas: 7% (38/518) remote: Resolving deltas: 8% (42/518) remote: Resolving deltas: 9% (47/518) remote: Resolving deltas: 10% (52/518) remote: Resolving deltas: 11% (58/518) remote: Resolving deltas: 12% (66/518) remote: Resolving deltas: 13% (68/518) remote: Resolving deltas: 14% (73/518) remote: Resolving deltas: 15% (78/518) remote: Resolving deltas: 16% (83/518) remote: Resolving deltas: 17% (89/518) remote: Resolving deltas: 18% (95/518) remote: Resolving deltas: 19% (99/518) remote: Resolving deltas: 20% (104/518) remote: Resolving deltas: 21% (110/518) remote: Resolving deltas: 22% (117/518) remote: Resolving deltas: 23% (122/518) remote: Resolving deltas: 24% (125/518) remote: Resolving deltas: 25% (130/518) remote: Resolving deltas: 26% (135/518) remote: Resolving deltas: 27% (144/518) remote: Resolving deltas: 28% (146/518) remote: Resolving deltas: 29% (151/518) remote: Resolving deltas: 30% (156/518) remote: Resolving deltas: 31% (162/518) remote: Resolving deltas: 32% (166/518) remote: Resolving deltas: 33% (171/518) remote: Resolving deltas: 34% (177/518) remote: Resolving deltas: 35% (182/518) remote: Resolving deltas: 36% (187/518) remote: Resolving deltas: 37% (193/518) remote: Resolving deltas: 38% (197/518) remote: Resolving deltas: 39% (203/518) remote: Resolving deltas: 40% (209/518) remote: Resolving deltas: 41% (213/518) remote: Resolving deltas: 42% (219/518) remote: Resolving deltas: 43% (223/518) remote: Resolving deltas: 44% (230/518) remote: Resolving deltas: 46% (240/518) remote: Resolving deltas: 47% (244/518) remote: Resolving deltas: 48% (249/518) remote: Resolving deltas: 49% (254/518) remote: Resolving deltas: 50% (260/518) remote: Resolving deltas: 51% (265/518) remote: Resolving deltas: 52% (270/518) remote: Resolving deltas: 53% (275/518) remote: Resolving deltas: 54% (280/518) remote: Resolving deltas: 55% (286/518) remote: Resolving deltas: 56% (292/518) remote: Resolving deltas: 57% (296/518) remote: Resolving deltas: 58% (301/518) remote: Resolving deltas: 59% (306/518) remote: Resolving deltas: 60% (311/518) remote: Resolving deltas: 61% (316/518) remote: Resolving deltas: 62% (323/518) remote: Resolving deltas: 63% (327/518) remote: Resolving deltas: 64% (332/518) remote: Resolving deltas: 65% (337/518) remote: Resolving deltas: 66% (343/518) remote: Resolving deltas: 67% (348/518) remote: Resolving deltas: 68% (353/518) remote: Resolving deltas: 69% (358/518) remote: Resolving deltas: 70% (363/518) remote: Resolving deltas: 71% (369/518) remote: Resolving deltas: 72% (373/518) remote: Resolving deltas: 73% (379/518) remote: Resolving deltas: 74% (384/518) remote: Resolving deltas: 75% (389/518) remote: Resolving deltas: 76% (394/518) remote: Resolving deltas: 77% (399/518) remote: Resolving deltas: 78% (406/518) remote: Resolving deltas: 79% (410/518) remote: Resolving deltas: 80% (415/518) remote: Resolving deltas: 81% (420/518) remote: Resolving deltas: 82% (425/518) remote: Resolving deltas: 83% (430/518) remote: Resolving deltas: 84% (437/518) remote: Resolving deltas: 85% (441/518) remote: Resolving deltas: 86% (447/518) remote: Resolving deltas: 87% (451/518) remote: Resolving deltas: 88% (456/518) remote: Resolving deltas: 89% (462/518) remote: Resolving deltas: 90% (467/518) remote: Resolving deltas: 91% (473/518) remote: Resolving deltas: 92% (477/518) remote: Resolving deltas: 93% (482/518) remote: Resolving deltas: 94% (487/518) remote: Resolving deltas: 95% (494/518) remote: Resolving deltas: 96% (498/518) remote: Resolving deltas: 97% (504/518) remote: Resolving deltas: 98% (508/518) remote: Resolving deltas: 99% (513/518) remote: Resolving deltas: 100% (518/518) remote: Resolving deltas: 100% (518/518), done. remote: Powered by GITEE.COM [1.1.23] remote: Set trace flag 174796a0 remote: Find the desired index: 6a4ecb8927a532d2774b4675296815a3fb440fdb, size: 141.262MB, exceeds quota 100MB remote: Please remove the file[s] from history and try again error: failed to push some refs to 'https://gitee.com/Mr___cheng/yijiagou-backend.git' To https://gitee.com/Mr___cheng/yijiagou-backend.git ! refs/heads/master:refs/heads/master [remote rejected] (pre-receive hook declined) Done
最新发布
12-14
<think>我们正在解决Git推送时因文件大小超过平台限制(如100MB)导致的`remote rejected (pre-receive hook declined)`错误。根据引用内容,问题根源是远程仓库(如Gitee或GitHub)对单个文件大小或仓库总容量有限制: - **单个文件限制**:通常为100MB(GitHub/Gitee默认)[^1][^3][^4] - **仓库总容量限制**:如Gitee免费版限制1GB[^2] 以下是分步解决方案,按操作复杂度排序: --- ### 方法1:删除大文件并重写提交历史(适用于少量大文件) 若大文件是**最近提交**且**未推送**: 1. 移除大文件缓存(保留本地文件): ```bash git rm --cached 大文件路径 # 例如:git rm --cached data/large_file.zip ``` 2. 修正最近一次提交: ```bash git commit --amend -C HEAD # -C表示复用上一次提交信息 ``` 3. 强制推送(谨慎操作): ```bash git push --force origin 分支名 # 例如:git push --force origin master ``` > **警告**:强制推送会覆盖远程历史,仅限个人分支使用[^5]。 若大文件在**历史提交**中: 1. 使用BFG工具或`git filter-branch`清理历史: ```bash # 推荐BFG(更快更安全): java -jar bfg.jar --delete-files 大文件名 仓库路径 # 或使用git filter-branch: git filter-branch --force --index-filter \ "git rm --cached --ignore-unmatch 大文件路径" \ --prune-empty --tag-name-filter cat -- --all ``` 2. 强制推送清理后的历史: ```bash git push --force --all ``` --- ### 方法2:使用Git LFS管理大文件(长期推荐) 适用于需保留大文件的场景(如图片、数据集): 1. 安装Git LFS: - **Windows/macOS**:从[Git LFS官网](https://git-lfs.com/)下载安装 - **Linux**:`sudo apt-get install git-lfs` 2. 初始化LFS并跟踪大文件: ```bash git lfs install # 初始化 git lfs track "*.zip" "*.pth" # 按扩展名跟踪,例如.zip/.pth ``` 3. 重新添加文件并提交: ```bash git add .gitattributes # 必须提交跟踪规则 git add 大文件路径 git commit -m "使用LFS管理大文件" ``` 4. 正常推送: ```bash git push origin 分支名 ``` > **注意**:GitHub/Gitee均支持LFS,但可能有存储配额限制(需检查账户设置)[^3]。 --- ### 方法3:清理仓库总体积(适用于仓库总容量超限) 当错误提示`repository size exceeds limit`时(如Gitee的1GB限制)[^2]: 1. 识别大文件: ```bash # 查看历史大文件 git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')" ``` 2. 按方法1清理这些文件的历史记录 3. 执行仓库压缩(减少.git体积): ```bash git reflog expire --expire=now --all git gc --prune=now --aggressive ``` 4. 联系平台申请清理缓存: - **Gitee**:访问报错中的`Repository GC`链接 - **GitHub**:需删除仓库重建(无直接GC接口) --- ### 方法4:分拆仓库(适用于超大项目) 若仓库持续增长,考虑拆分为子模块: 1. 创建新仓库存放大文件目录 2. 原仓库中添加子模块: ```bash git submodule add https://新仓库URL 子模块路径 ``` 3. 提交并推送子模块变更 --- ### 总结步骤选择 | 场景 | 解决方案 | |------|----------| | 误提交临时大文件 | 方法1(删除文件并重写历史) | | 需保留大文件 | 方法2(使用Git LFS) | | 仓库总体积超限 | 方法3(清理历史+GC) | | 项目持续膨胀 | 方法4(拆分子模块) | > **关键预防措施**: > 1. 添加`.gitignore`过滤无需版本控制的文件(如数据集、编译产物) > 2. 使用`git add -p`交互添加,避免意外包含大文件 > 3. 本地设置提交前钩子检查文件大小: > ```bash > # 在.git/hooks/pre-commit中添加 > MAX_SIZE=100000000 # 100MB > for file in $(git diff --cached --name-only); do > size=$(wc -c < "$file") > if [ $size -gt $MAX_SIZE ]; then > echo "错误: $file 超过$((MAX_SIZE/1000000))MB" > exit 1 > fi > done > ``` §§相关问题§§ 1. 如何检查Git仓库中的大文件? 2. Git LFS的工作原理和存储配额如何管理? 3. 强制推送(`git push --force`)的风险及如何安全使用? 4. 不同Git平台(GitHub/Gitee/GitLab)的文件大小限制对比? </think> ### 解决Git推送报错:`remote rejected (pre-receive hook declined)`(文件大小超限) 该错误通常是由于推送内容超出远程仓库的文件大小限制(如单个文件 > 100MB 或仓库总容量 > 1GB)。以下是分步解决方案: --- ### 一、紧急处理:移除已提交的大文件 #### 情况1:大文件在**最新提交**中(尚未推送) ```bash # 1. 从Git缓存中移除大文件(保留本地文件) git rm --cached <大文件路径> # 例如:git rm --cached data/large_dataset.zip # 2. 修正最新提交 git commit --amend -C HEAD # 3. 重新推送 git push origin <分支名> ``` #### 情况2:大文件在**历史提交**中 ```bash # 1. 使用BFG工具清理历史记录(推荐) java -jar bfg.jar --delete-files <文件名> 仓库路径 # 或手动清理(耗时较长): git filter-branch --force --index-filter \ "git rm --cached --ignore-unmatch <大文件路径>" \ --prune-empty --tag-name-filter cat -- --all # 2. 强制推送清理后的仓库 git push --force --all ``` > **注意**:强制推送会覆盖远程历史,需提前备份重要数据。 --- ### 二、长期方案:使用Git LFS管理大文件 适用于需要保留大文件的场景(如数据集、模型文件): ```bash # 1. 安装Git LFS # Windows/macOS: 从 https://git-lfs.com/ 下载安装 # Linux: sudo apt install git-lfs # 2. 初始化并跟踪大文件类型 git lfs install git lfs track "*.zip" "*.tar.gz" "*.pth" # 按需添加扩展名 # 3. 重新添加文件并提交 git add .gitattributes # 必须提交LFS配置文件 git add <大文件路径> git commit -m "使用LFS管理大文件" # 4. 正常推送 git push origin <分支名> ``` > **原理**:LFS将大文件存储在独立服务器,仓库中仅保留指针文件。 --- ### 三、仓库总容量超限解决方案 当错误提示`repository size exceeds limit`(如Gitee限制1GB)[^2]: 1. **识别大文件**: ```bash # 查看历史大文件 git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')" ``` 2. **清理大文件**(使用第一部分的方法) 3. **压缩仓库**: ```bash git reflog expire --expire=now --all git gc --prune=now --aggressive ``` 4. **联系平台清理缓存**: - Gitee:访问错误信息中的 `Repository GC` 链接[^2] - GitHub:需删除仓库后重建(无在线GC) --- ### 四、预防措施 1. **添加`.gitignore`文件**: ```gitignore # 忽略常见大文件类型 *.zip *.tar.gz *.pth *.h5 /data/ # 忽略整个数据目录 ``` 2. **设置本地预检钩子**: ```bash # 在.git/hooks/pre-commit中添加 MAX_SIZE=100000000 # 100MB for file in $(git diff --cached --name-only); do size=$(wc -c < "$file") if [ $size -gt $MAX_SIZE ]; then echo "错误: $file 超过$((MAX_SIZE/1000000))MB" exit 1 fi done ``` > **各平台限制参考**: > | 平台 | 单文件限制 | 仓库总限制 | > |-------|------------|------------| > | GitHub| 100 MB | 推荐 < 1GB | > | Gitee | 100 MB | 免费1GB | > | GitLab| 10 GB | 10 GB |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值