Git 与版本协作 / LESSON 35
Git LFS:大文件指针,不是魔法压缩
按文件类型与修改方式选择,不把所有素材一股脑加入。
CONCEPT MAP先看一眼知识之间的联系
01为什么普通 Git 不总适合大二进制
文本代码容易比较行差异;分层图像、长音频等大二进制频繁变化时,历史会变重。LFS 在 Git 历史中使用小指针,实际内容由 LFS 存储管理。读取仓库的协作者需要拿到真实对象,不是只有指针就能看到图片。是否使用远端、容量配额和费用需另行核实。
02它不能替你完成什么
LFS 不会自动压小 .kra,不会免除本地缓存,不会修复同时编辑同一场景的冲突,也不保证已存在历史自动迁移。你已经安装 Git LFS,只代表工具可用;本项目的规则、跟踪文件与远端仍未建立。
03独立练习仓库的规则实验
# 会修改当前练习仓库的 hooks / 配置和 .gitattributes。
# 仅在你确认过的练习仓库执行。
git lfs install --local
git lfs track "*.kra"
git diff -- .gitattributes
git add .gitattributes
# 添加一个自己创建的练习 .kra 后,再检查:
git lfs ls-files规则应提交到历史,让协作者知道哪些文件用 LFS。已提交的大文件不会因为新写了跟踪规则就神奇改变旧历史。迁移旧提交是更大的操作,本课不执行。
04如何作出适度选择
| 内容 | 建议判断方式 |
|---|---|
| .gd / .tscn / .tres 文本 | 通常保留文本差异能力 |
| 频繁修改的大 .kra | 可以评估 LFS 与单写者流程 |
| 小型已定 PNG | 先看实际大小和变更频率,不机械套规则 |
| 临时生图候选与导出包 | 先决定是否值得入库,而不是默认都 LFS |
| 二进制历史迁移 | 先备份、评估协作影响并获得批准 |
最终规则要由实际文件体积、修改习惯和远端成本决定;不把“所有 PNG 必须 LFS”当作项目已确认规范。
动手后,再勾选
不是“我看懂了”,而是你在独立练习里做出并检查过。
CHECK YOUR UNDERSTANDING
换一个情景,你会怎么判断?
LFS 跟踪规则写好后,过去的大文件提交会怎样?
历史迁移是独立操作,不能从新增跟踪规则推断已经完成。
用自己的话,留一条笔记
可以写“我之前以为……,现在发现……”,或者记录还没解决的问题。
仅保存在此浏览器0 / 20000
↗回到资料核对
本课是解释与练习,不替代对应版本的官方手册。网页实验不运行 Godot;未标明实机验证的代码,仍需在独立工程中检查。
把这课收进你的理解里。
标记已读不会自动勾选实作,也不代表游戏功能已经完成。