Git 进阶操作：分支策略与协作实战

分支管理，说白了就是团队协作的交通规则。没有规则，大家各开各的车，早晚撞在一起。我在智能座舱项目里见过太多因为分支混乱导致的发布事故——代码合丢了、功能漏了、冲突改坏了。嗯，今天我们就来把这些坑填上。

两种主流分支策略：Git Flow 与 Trunk Based

先看一张对比图，帮你快速建立整体认知：

Git Flow：适合座舱的正式发布场景

Git Flow 有 5 种核心分支，每种分支有明确的职责。我参与过的几个量产座舱项目，用的都是 Git Flow 的变体。

Trunk Based：适合快速迭代的座舱敏捷团队

如果你团队小、发布频繁，Trunk Based 更合适。核心规则就一条：所有人往主干合并，每天至少一次。

• 分支存活时间不超过 2 天
• 每次提交必须通过 CI 构建
• 功能开关（Feature Toggle）代替长分支

我有个项目从 Git Flow 切到 Trunk Based 后，集成周期从 2 周缩短到 2 天。但前提是——你的自动化测试覆盖率要够高，否则主干分分钟变废墟。

合并（Merge）与变基（Rebase）

这两个操作经常被搞混。我直接说结论：

冲突解决：别慌，一步步来

冲突是家常便饭。座舱项目里，最常冲突的文件是 HMI 配置文件、资源索引和协议头文件。我的解决流程：

1. 先拉最新代码：git pull --rebase 或 git merge origin/develop
2. 查看冲突文件：git status 列出所有冲突
3. 手动编辑：打开文件，找到 <<<<<<< 标记
4. 选择保留：保留当前分支、传入分支，或手动合并
5. 标记已解决：git add <file>
6. 继续操作：git rebase --continue 或 git merge --continue

Cherry-pick：精准移植提交

Cherry-pick 就是从某个分支挑一个或多个提交，应用到当前分支。座舱项目里常用场景：

• hotfix 修复从 release 分支移植到 main
• 某个功能提交从 develop 移植到 release 分支
• 紧急修复跨版本移植

基本用法：

# 查看提交哈希
git log --oneline

# 移植单个提交
git cherry-pick a1b2c3d

# 移植多个提交
git cherry-pick a1b2c3d e4f5g6h

# 移植一段连续提交
git cherry-pick a1b2c3d..e4f5g6h

实战：座舱项目分支操作示例

假设我们正在开发座舱的 HMI 2.0 版本：

# 1. 从 develop 创建 feature 分支
git checkout develop
git checkout -b feature/hmi-v2

# 2. 开发过程中同步主干
git fetch origin
git rebase origin/develop

# 3. 开发完成，合并回 develop
git checkout develop
git merge --no-ff feature/hmi-v2

# 4. 创建 release 分支
git checkout -b release/2.1.0

# 5. 修复 bug 后 cherry-pick 到 main
git checkout main
git cherry-pick -x 9a8b7c6

你想想看，如果没有分支策略，每个人都在 main 上直接提交，那发布前根本没法控制哪些功能进、哪些不进。分支策略不是束缚，是保护。