3、版本控制工具选择：Git vs SVN vs 企业网盘，光学设计场景下的优劣分析
做光学设计这些年，我换过不少版本管理工具。从最早用网盘瞎折腾，到后来公司强推SVN，再到现在团队全面转向Git。说实话，每种工具都有它的脾气。选错了，轻则效率打折，重则设计文件损坏、版本回退不了——这种事我见过太多次了。
这一章，我就结合自己的实际经验，把Git、SVN和企业网盘这三类工具放在光学设计场景下，掰开揉碎讲清楚。你想想看，一个透镜设计文件动辄几百兆，ZEMAX或Code V的格式又很特殊，选工具真不是随便拍脑袋的事。
3.1 企业网盘：看似简单，坑最多
很多小团队起步时都用网盘。我也干过这事——把设计文件往某度网盘或某信里一丢，谁改谁下载。嗯，这里要注意，这其实不叫版本管理，这叫文件共享。
网盘在光学设计场景下的致命问题有三个：
- 没有差异对比能力——网盘只知道文件变了，但变了哪个镜片曲率？变了哪组玻璃？完全不知道。
- 并发冲突全靠人工——两个人同时改同一个文件，后保存的人直接覆盖前者。没有合并机制。
- 历史版本有限——大部分网盘只保留最近30天或50个版本，超过就自动清理。一个光学项目动辄半年，你想想看。
网盘唯一的好处是上手快。但说白了，它只适合做最终成果的归档备份，不适合做设计过程中的版本管理。
3.2 SVN：集中式管理的代表，适合传统光学团队
SVN是我用得最久的版本管理工具。在2015年前后，国内大部分光学设计团队都在用SVN。它的核心逻辑是集中式——所有版本数据存在中央服务器，每个人从服务器拉取最新版本，改完再提交回去。
我个人习惯把SVN比作图书馆借书。你要改设计，先"借出"文件，服务器会锁定它，别人就不能改了。改完再"还回去"，解锁。这样就不会出现两个人同时改同一个文件的问题。
- 大文件支持好——光学设计文件通常很大，SVN对大文件的传输和存储优化得不错。我管理过单个超过2GB的镜头设计文件，SVN跑起来还算稳。
- 权限管理精细——可以按目录设置读写权限。比如，镜头结构文件只让资深工程师改，新人只能看不能动。
- 学习成本低——概念少，就几个命令：checkout、commit、update。团队里五六十岁的老师傅也能快速上手。
- 二进制文件友好——光学设计文件大多是二进制格式（.ZMX、.SEQ、.ZDA），SVN对二进制文件的锁定机制天然适合。
但SVN也有明显的短板。我记得有一次，一个同事在出差路上想提交设计修改，结果连不上公司内网的SVN服务器，活活等了两天。集中式管理的通病就是——离了服务器，你什么都干不了。
3.3 Git：分布式管理的王者，现代光学团队的标配
Git这几年在光学设计圈越来越火。我大概在2018年才开始认真用Git管理光学设计文件。一开始很不习惯——概念太多了，分支、暂存、变基、合并冲突……但用顺手之后，真香。
Git的核心优势在于分布式。每个开发者的电脑上都有完整的版本历史。就算服务器挂了，你本地照样能提交、能回退、能看历史。这对经常出差的光学工程师来说太重要了。
但Git在光学设计场景下也有几个需要特别注意的地方：
- 二进制文件无法做行级对比——Git的diff工具对文本文件很好用，但对.ZMX这种二进制文件，只能告诉你"文件变了"，变在哪里？不知道。我一般配合ZEMAX的API写脚本做参数级对比。
- 大文件需要额外配置——Git本身对大文件支持不好。我推荐用Git LFS（Large File Storage）来管理光学设计文件。配置好之后，大文件会被替换成指针文件，仓库体积能缩小90%以上。
- 分支管理要规范——光学设计不像软件开发那样频繁分支。我建议只保留三个分支：main（稳定版）、develop（开发版）、feature/xxx（功能分支）。不要搞太复杂。
- 离线工作——在飞机上、在客户现场，照样能提交和查看历史版本。
- 分支灵活——可以同时维护多个设计方案。比如，一个分支做高像质版本，一个分支做轻量化版本，互不干扰。
- 社区生态好——GitHub、GitLab、Gitee都有丰富的工具链，可以集成CI/CD做自动化测试。
- 历史不可篡改——每次提交都有哈希值校验，谁改了什么东西，一查一个准。
3.4 三种工具的对比总结
下面这张表是我根据自己的使用经验整理的，你可以直接拿来当选型参考：
| 对比维度 | 企业网盘 | SVN | Git + LFS |
|---|---|---|---|
| 上手难度 | 极低（5分钟） | 低（1天） | 中（1-2周） |
| 大文件支持 | 一般（有上传限制） | 好（原生支持） | 好（需配置LFS） |
| 离线工作 | 不支持 | 不支持 | 完全支持 |
| 并发冲突处理 | 无（后覆盖前） | 锁定机制（防冲突） | 合并机制（需手动解决） |
| 历史版本保留 | 有限（30-90天） | 完整（按提交记录） | 完整（按提交记录） |
| 权限管理 | 粗粒度（文件夹级） | 细粒度（目录级） | 中粒度（仓库级） |
| 二进制文件对比 | 不支持 | 不支持 | 不支持（需第三方工具） |
| 适合团队规模 | 1-3人 | 3-20人 | 5-100人 |
| 推荐场景 | 个人归档、临时共享 | 传统光学团队、网络稳定 | 现代研发团队、多地协作 |
3.5 我的选型建议
说了这么多，到底选哪个？我的建议很简单：
- 如果你是一个人做设计——用Git就够了。本地仓库，轻量高效。配合Git LFS管理大文件，基本够用。
- 如果你是3-10人的小团队——我推荐SVN。学习成本低，锁定机制适合光学设计文件的特性。我见过很多光学设计所，SVN一用就是七八年，很稳。
- 如果你是10人以上的研发团队——必须上Git。分布式协作、分支管理、CI/CD集成，这些能力是SVN给不了的。但一定要配好Git LFS和二进制文件对比工具。
- 企业网盘——只用来做最终交付件的归档。别拿它当版本管理工具用，血的教训。
3.6 知识结构图：版本控制工具选型决策流程
下面这张图是我画的选型决策流程，你可以对照自己的情况走一遍：
3.7 避坑指南：我踩过的几个坑
最后分享几个我亲身经历过的坑，你遇到了可以绕开走：
我曾经有一个项目，Git仓库体积达到了12GB。后来发现是LFS配置漏掉了.ZDA文件类型。每次提交都把完整的二进制文件塞进了仓库。修复方法是重新配置.gitattributes文件，然后用BFG工具清理历史。折腾了两天。
有一次，一个同事在提交ZEMAX文件时网络断了，文件被锁定在服务器上。其他人想改同一个文件，提示"被锁定"。最后只能让管理员手动解锁。从那以后，我规定：锁定文件超过2小时不操作，自动释放。
这个最坑。某网盘的同步机制是边上传边覆盖。有一次一个.ZMX文件上传到一半，另一个同事开始下载，结果下载了一个不完整的文件。打开ZEMAX直接报错，设计参数全乱了。从那以后，我再也不用网盘同步设计文件了。
选工具这件事，没有绝对的对错。关键是要清楚自己的团队规模、工作流程和网络条件。我个人建议：小团队用SVN稳，大团队用Git活，网盘只归档。你按这个原则选，基本不会出大问题。