上篇聊了代码审查PR机制是建立在Git之上的。版本管理是团队协作的基础设施不会版本管理的工程师就像不会存钱的会计——基本功能都缺失。Git是每个机器人工程师必须熟练掌握的工具。机器人项目的版本管理比普通软件项目复杂一些。原因有几个代码仓库多感知、控制、导航各自独立、有大文件URDF模型、点云地图、训练好的模型文件、需要和硬件版本对应固件版本、驱动版本。面试时如果你能聊清楚Git在机器人项目中的特殊用法会加分不少——这说明你有实际工程经验。分支策略机器人项目常用的分支策略有两种Git Flowmain分支始终保持可发布状态develop分支做日常开发feature分支从develop拉出来开发新功能完成后合回develop。发布时从develop切release分支修完bug打上tag合回main。适合有固定发布周期的项目。Trunk Based Development所有人直接在main分支上开发用feature flag控制新功能的开关。适合持续部署的团队要求代码审查和自动化测试非常成熟。大多数机器人团队用Git Flow或者它的变体。因为机器人发布往往和硬件版本绑定需要有明确的发布节点。你不太可能给已经出厂的机器人推送一个持续部署的更新。而且硬件迭代周期长软件需要同时维护多个版本——新机器用最新代码老机器用稳定分支打补丁。大文件管理机器人项目有个头疼的问题大文件。点云地图动辄几百MB深度学习模型文件几十到几百MBGazebo世界文件里的网格模型也不小。这些文件直接放Git仓库里仓库体积会迅速膨胀clone速度越来越慢。解决方案有几种Git LFSLarge File Storage最主流的方案。大文件不直接存在Git仓库里而是存在LFS服务器上Git仓库里只保存一个指针。clone时默认不下载LFS文件需要时再拉取。缺点是LFS服务器需要额外维护而且有存储空间限制。Git Annex类似LFS但更灵活支持多种存储后端S3、NAS、USB硬盘都行。适合不想依赖第三方服务的团队。外部存储引用最简单的方案。大文件放在NAS或者云存储上Git仓库里只保存一个下载链接或者路径引用。缺点是版本对应关系需要手动管理。# Git LFS基本用法 git lfs install git lfs track *.pcd git lfs track *.onnx git add .gitattributes git add maps/ models/ git commit -m Add map and model files via LFS多仓库协调机器人项目通常有多个代码仓库感知模块一个仓库、导航模块一个仓库、控制模块一个仓库、机器人描述URDF/Mesh一个仓库。这些仓库之间有版本依赖关系——导航v2.3必须配合感知v1.5才能正常工作。怎么管理这种跨仓库的版本依赖Git Submodule在主仓库里引用子仓库的特定commit。优点是版本锁定精确缺点是操作复杂很多工程师搞不清楚submodule的更新流程。vcstoolROS社区常用的工具。用一个yaml文件描述所有仓库的地址和版本一条命令checkout所有仓库到正确版本。比submodule简单很多。ros2的源码管理就是用vcstool你可以看看它的repositories.yaml文件作为参考。还有一种思路是monorepo——所有代码放在一个仓库里。Google就是典型的monorepo。优点是版本一致性天然保证不需要跨仓库同步。缺点是仓库太大Git操作变慢。机器人项目如果团队不大10人以内monorepo其实是个不错的选择省去了多仓库协调的麻烦。# repositories.yaml repositories: perception: type: git url: https://github.com/myorg/perception.git version: v1.5.0 navigation: type: git url: https://github.com/myorg/navigation.git version: v2.3.0 robot_description: type: git url: https://github.com/myorg/robot_description.git version: mainvcs import repositories.yamlTag和发布管理机器人项目的发布release需要记录的信息比普通软件多。一个完整的发布tag应该包含软件版本号遵循语义化版本major.minor.patch对应的固件版本对应的硬件版本PCB版本号标定参数版本已知问题和限制这些信息通常写在一个CHANGELOG.md或者release notes里和tag关联。出了问题需要回溯的时候能精确知道当时用的是哪个版本的代码、跑在哪块硬件上、用的什么标定参数。Commit规范版本管理的质量很大程度上取决于commit message的质量。好的commit历史就像一本项目日记能帮你快速定位这个bug是什么时候引入的。我们团队遵循Conventional Commits规范feat(navigation): 添加动态障碍物预测功能 fix(control): 修复PID积分饱和导致的超调问题 perf(perception): 优化点云降采样速度提升40% docs(readme): 更新安装说明和依赖版本要求每条commit message包含三部分类型feat/fix/perf/docs等、作用域哪个模块、简短描述。复杂的改动在正文里补充详细说明解释为什么而不是做了什么。有个纪律很重要一个commit只做一件事。不要在一个commit里既改算法又改UI还修了一个typo。这样出问题需要回滚的时候你不需要把不相关的改动一起回滚。用git add -p可以按代码块分阶段暂存不需要把所有改动一次性提交。面试追问你们怎么处理紧急bug修复从main分支切一个hotfix分支修复后同时合回main和develop。hotfix分支要走完整的代码审查和测试流程不能因为紧急就跳过。如果bug影响已经部署的机器人还需要评估是否需要OTA更新。Git rebase和merge有什么区别你们用哪个rebase把提交历史变干净merge保留完整的分支历史。我们团队的规范是feature分支用rebase保持和develop同步合入develop时用merge。main分支上的历史永远是线性的方便追溯。仓库被误推了大文件怎么办用git filter-repo或者BFG Repo-Cleaner清理。清理后所有人需要重新clone仓库。这是为什么我们要在CI里加大文件检测——PR里包含超过10MB的文件就自动拒绝。版本管理是团队协作的地基。地基打不好上面的代码审查、CI/CD、发布管理全都受影响。机器人项目的版本管理比纯软件项目多了一些维度——硬件版本、固件版本、标定参数——这些都要纳入版本管理的范畴。我见过一个团队因为没有做好版本管理花了整整一周时间排查一个问题。最后发现是有人改了URDF模型里的关节限位参数但没有更新版本号导致测试用的模型和实际部署的模型不一致。如果版本管理做好了这种问题根本不会发生。下一篇聊技术文档写作。代码写得好不够还得把设计思路、接口规范、使用手册写清楚。文档能力是工程师的隐形竞争力——会写文档的人在团队里的影响力远大于他的代码产出。如果这篇文章对你有帮助欢迎点赞、在看、转发三连。 你的支持是我持续更新的最大动力。「机器人软件开发面试·从入门到精通」连载系列上一篇第331篇 代码审查——怎么review别人的代码下一篇预告第333篇 技术文档写作——工程师的隐形竞争力有任何问题欢迎评论区留言我会尽量回复。