Git LFS 管理 Unity 大文件

Git 推送 Unity项目到服务器端仓库的时候，出现如下关键提示，表明推送内容太大，无法正常推送。

error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

fatal: the remote end hung up unexpectedly Everything up-to-date

解决方案

安装 Git LFS服务，基于Git LFS服务推送；

在 Git Bash 窗口安装 LFS 服务；
（如果有）撤销上一次的本地提交；
编辑 LFS 的配置文件（即LFS追踪哪些类型的文件）；
单独添加 LFS 的配置文件并推送；
重新添加项目文件，进行推送；

bash 复制代码

# Windows（如果用Git Bash）
git lfs install

# 验证安装
git lfs version

# 若提示 git: 'lfs' is not a git command，需先下载安装 Git LFS：
# https://git-lfs.com/

# （如果有需要）撤销上一次的提交
git reset --soft HEAD~1  # 撤销最后一次提交（保留文件修改）

# 追踪Unity常见大文件类型（根据你的项目补充）
# 注意在仓库根目录下打开Git Bash进行如下指令
git lfs track "*.psd"
git lfs track "*.png"
git lfs track "*.jpg"
git lfs track "*.fbx"
git lfs track "*.asset"
git lfs track "*.unitypackage"
git lfs track "*.dll"
git lfs track "*.exe"

# 把.gitattributes文件加入版本控制（LFS的配置文件）
git add .gitattributes
git commit -m "配置Git LFS追踪Unity大文件"

# 推送

git add .  # 重新暂存（LFS会识别并处理大文件）
git commit -m "使用LFS推送Unity项目资源"

（不使用LFS）分块推送；（不适用于单个超大文件）

bash 复制代码

# 1. 撤销当前未推送的大提交（保留文件，仅撤销提交记录）
git reset --soft HEAD~1

# 2. 分批暂存+提交（比如先推代码文件，再推资源文件）
# 第一步：只暂存代码/配置文件（小体积）
git add *.cs *.meta .gitignore .gitattributes
git commit -m "推送Unity代码和配置文件"
git push origin master:main  # 先推小体积内容

# 第二步：暂存部分资源文件（分多次）
git add Assets/Scripts/ Assets/Scenes/  # 只加部分资源
git commit -m "推送部分Unity资源（批次1）"
git push origin master:main

# 重复第二步，分批推送剩余资源，直到全部推完

其他

为什么修改 http.postBuffer 会无效？

git config http.postBuffer 是 Git 客户端侧的缓冲区配置 ，作用是：Git 在向远程推送数据时，会先把待推送的数据包缓存到本地内存 / 磁盘，攒到 postBuffer 设定的大小后，再一次性发送给服务端。

它的设计目的：解决「客户端频繁发送过小数据包，导致网络传输效率低、超时断开」的问题（比如网络极慢时，发一堆小包容易断）；

它的核心局限：只能调整客户端 "怎么发"，无法改变服务端 "能收多少"。

而这里提到的问题根源是：服务端的「硬性大小限制」（HTTP 413）

推送的数据包是XGiB大小的存在，而远程 Gitea 服务器（或前端的 Nginx/Apache）会设置 client_max_body_size 这类参数（比如默认 1GB/100MB），这个参数是服务端的 "红线"：

只要单次 HTTP 请求的数据包大小超过这个值，服务端会直接返回 HTTP 413（请求实体过大），并断开连接 ------ 这是服务端的主动拒绝，和客户端怎么发、缓冲区多大无关；

修改 http.postBuffer 只是把客户端的 "发送缓冲区" 调大了，但发送的仍是一个 XGB 的超大数据包，依然会触发服务端的大小限制，所以毫无作用。