版本控制对大文件的支持情况
很多人在使用版本控制系统时都会遇到一个问题：能不能把大文件也纳入管理？比如项目里有个几百兆的数据库备份，或者设计师提交的原始PSD文件动辄上G，这些文件能不能直接扔进Git仓库？答案是——可以，但不推荐。
传统的Git设计初衷是处理文本代码，每次提交都会完整记录文件快照。当你提交一个1GB的视频文件，这个体积就会永久留在历史记录里。哪怕下次只改了一帧，Git依然会存下另一个完整的副本。久而久之，克隆仓库的速度会越来越慢，甚至可能卡在下载环节。
常见问题场景
比如团队协作开发一个移动端应用，UI同事习惯把所有高保真素材打包上传到主分支。刚开始还好，三个月后有人新入职，执行git clone命令，等了十分钟还没下完，一查发现历史记录里藏着几十个被删除但未清理的大文件。这时候只能用工具重写历史，操作复杂还容易出错。
Git LFS：专为大文件设计的方案
为了解决这个问题，GitHub推出了Git LFS（Large File Storage）。它的工作原理是用指针代替真实文件。实际内容存在单独的服务器上，版本库中只保留一个轻量引用。
启用方式也很简单：
git lfs install
git lfs track "*.psd"
git add .gitattributes上面这段命令会让所有PSD文件走LFS通道。之后每次提交，Git只会保存一个小指针，真正的文件由LFS后台同步。这样既保留了版本管理功能，又不会拖垮仓库性能。
其他替代方案
除了LFS，有些团队选择把大文件放在外部存储，比如NAS或云盘，然后在代码库里放一个下载脚本。这种方式适合内部项目，但缺点是依赖网络环境，交接成本高。
也有开发者改用Mercurial（Hg），它对大文件的支持比原生Git更友好，不过生态和普及度远不如Git。
是否支持大文件，本质上是个权衡问题。技术上能做到，但要考虑后续维护成本。对于频繁变更的大体积二进制文件，最好从一开始就规划好存储策略，避免后期被迫拆库或清理历史。