一个人写代码Git随便用都行。但几个人一起写机器人项目没有规范就乱套了。我之前实习的时候团队里三个人同时往develop分支上push代码有一天直接push冲突了谁也不敢force push最后三个人坐在工位上面面相觑花了半天才理清楚。从那以后团队立了规矩再也没出过这种事。面试的时候团队协作相关的Git知识是加分项。因为这说明你不是只会自己写代码而是能融入团队工作流。分支策略Git Flow和简化版Git Flow是最经典的分支模型。核心思路是main分支——永远是可发布的稳定版本。每次发布新版本打一个tag比如v1.2.0。这个分支上的代码随时可以部署到机器人上运行。develop分支——日常开发的主线。所有功能分支最终都合并到这里。develop上的代码不一定稳定但一定是当前开发进度的最新状态。feature/*分支——每个新功能从develop开出来开发完了合并回develop。命名规范比如feature/imu_driver、feature/path_planning。hotfix/*分支——线上版本有紧急bug从main开出来修复修完同时合并到main和develop。release/*分支——准备发布的时候从develop开出来做最后的测试和修复确认没问题后合并到main。听起来很复杂确实。对于小团队来说可以用简化版只保留main和develop两个长期分支功能分支直接从develop开修完合并回去不用release分支。很多机器人创业团队就是这么干的。关键不是用哪种模型而是团队要统一。所有人对分支的作用有共识就不会乱。冲突解决别怕没那么恐怖两个人改了同一个文件的同一几行代码Git不知道听谁的就会报冲突。第一次遇到冲突很多人会慌其实解决冲突没那么难。冲突长这样 HEAD void initLidar(int baud_rate 115200) { void initLidar(int port 3, int baud_rate 9600) { feature/new_sensor HEAD到之间是你当前分支的代码到是要合并进来的代码。你需要手动决定保留哪个版本或者把两个版本合并在一起。解决步骤# 1. 打开冲突文件手动编辑删掉冲突标记 # 2. 编辑完之后 git add 冲突文件 git commit # Git会自动生成一个合并commit有几个减少冲突的好习惯。第一开始工作前先pull最新代码保持本地和远程同步。第二功能分支不要开发太久超过一周就应该考虑合并或者至少rebase一下最新代码。第三和同事沟通好分工尽量避免两个人同时改同一个文件。如果冲突实在太多、太复杂别硬着头皮解。跟同事商量一下看看谁的改动更合理或者一起坐下来合并。这不是能力问题是工程习惯。有个小技巧用图形化的merge工具。VS Code内置了冲突编辑器左右两边分别显示两个版本的代码你点一下就能选择保留哪个。比手动删冲突标记直观多了。命令行下可以用meld或者kdiff3效果类似。Pull Request和Code ReviewPull RequestPRGitHub的叫法GitLab叫Merge Request是团队协作的核心流程。基本流程是这样的你在feature分支上开发完了push到远程仓库然后在GitHub上创建一个PR请求把你的feature分支合并到develop。创建PR的时候要写清楚这几件事这个PR做了什么改动为什么这么改有没有测试过有没有已知的遗留问题。好的PR描述能帮reviewer快速理解你的意图。Code Review就是其他同事来审查你的代码。他们看什么逻辑对不对——代码实现是否符合需求边界条件有没有考虑。在机器人项目里这特别重要因为代码bug可能导致硬件损坏甚至人身伤害。代码风格——命名是否清晰注释是否充分是否符合团队的编码规范。很多团队会用clang-format统一C代码风格在CI里自动检查不符合格式的直接拒绝合并。架构合理性——改动是否引入了不必要的复杂度是否和现有架构兼容。潜在问题——有没有内存泄漏有没有线程安全问题有没有资源未释放。C项目里这些问题尤其常见reviewer会特别关注new和delete是否配对锁的获取释放是否正确。一个好的PR应该控制在200-400行改动以内。太大了reviewer看不下去质量就下降了。如果你一个功能改了几千行应该考虑拆分成多个PR。每个PR做一件事reviewer容易理解合并也安全。reviewer提出修改意见后你在本地改完push上去PR会自动更新。所有reviewer都approve了才能合并。有些团队要求至少两个人approve这在机器人安全相关的代码里很有必要。机器人项目中的协作实践在机器人项目里团队协作有一些特殊的地方。硬件依赖。不同版本的代码可能对应不同版本的硬件。比如你换了激光雷达型号相关的驱动代码和配置都需要改。这时候分支管理要和硬件版本对应起来最好用tag标记比如hw-v2.0。仿真和实机的差异。很多代码先在仿真环境里跑通了再上实机。可以建两个长期分支一个用于仿真环境一个用于实机部署。仿真分支验证通过了再合并到实机分支。配置管理。机器人的参数配置比如PID参数、传感器标定数据也应该纳入版本控制。但要注意这些文件可能很大或者包含敏感信息。大文件用Git LFS敏感信息用环境变量或者加密存储别直接提交明文密码。面试中怎么聊团队协作面试官问你们团队怎么管理代码你可以这样回答我们用的是简化版Git Flow。main是稳定版本develop是开发主线。每个功能开feature分支开发完了提PR。PR至少要一个人review才能合并。我们有CIPR创建后会自动跑编译和单元测试。冲突的话一般是两个人同时改了同一个文件pull最新代码后手动解决。我印象比较深的一次是两个人同时改了CMakeLists.txt冲突比较多最后一起坐下来花了半小时才理清楚。这种回答好在有具体流程、有实际场景、有真实案例。面试官一听就知道你在团队里干过活。Git Hooks自动化团队规范Git hooks是Git自带的钩子机制可以在特定操作前后自动执行脚本。团队常用的hooks有两个pre-commit在提交前运行用来检查代码格式和敏感信息commit-msg在提交时运行用来检查commit message格式。# 安装pre-commit工具 pip install pre-commit # 在项目根目录创建.pre-commit-config.yaml # 配置clang-format、check-merge-conflict等hooks pre-commit install配置好之后每次git commit都会自动跑clang-format检查C代码格式、检查是否有遗留的冲突标记、验证commit message是否符合规范。不符合就拒绝提交从源头保证代码质量。团队里所有人都装pre-commit代码风格就统一了。Code Review的实践经验在团队开发中Code Review是保证代码质量的重要环节。一个好的PR应该改动范围明确不要在一个PR里混杂功能修改和重构描述清楚改了什么、为什么改附带测试用例。Review时重点关注逻辑正确性、边界条件处理和代码可读性。在机器人项目中还要特别注意线程安全、资源释放和实时性问题这些都是容易出bug的地方。给你的建议如果你还没参与过团队项目找机会参与一个。GitHub上有很多开源的机器人项目从提一个小PR开始体验一下code review的流程。学会用GitHub或者GitLab的PR界面。上面有diff视图、评论功能、CI状态显示。比纯命令行方便很多。最后code review的时候心态要好。别人指出你的代码问题不是针对你个人是为了让代码更好。同样你review别人的代码也要友善提建议而不是挑毛病。团队协作沟通比技术更重要。上一篇第99篇 Git进阶——rebase/cherry-pick/stash的实战场景下一篇预告第101篇 GDB调试基础——断点、单步、内存查看
