Git团队协作——分支策略、冲突解决和Code Review流程

郑伟强dev

320人浏览 · 2026-07-23 00:31:28

郑伟强dev · 2026-07-23 00:31:28 发布

一个人写代码，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 Review

Pull Request（PR，GitHub的叫法；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才能合并。我们有CI，PR创建后会自动跑编译和单元测试。冲突的话，一般是两个人同时改了同一个文件，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的地方。