版本控制与分支策略：Git基础，分支模型对CI的影响

做CI/CD流水线，绕不开一个话题——版本控制。

说实话，我见过太多团队，CI流水线搭得挺漂亮，但一合并代码就崩。为什么？问题往往不在流水线本身，而在分支策略上。

这一章，我们聊聊Git的核心操作，以及分支模型怎么影响你的CI效率。

Git基础：CI的根基

很多人觉得Git就是「add、commit、push」三板斧。嗯，没错，但在CI场景下，你需要理解更深一点。

说白了，Git本质上是一个内容寻址的文件系统。每次提交，都是一次快照，而不是差异文件。这个特性，决定了我们可以在任意节点上做验证和回滚。

我之前带团队时，发现很多人对rebase和merge的差异不清楚，结果提交历史乱成一团，CI触发逻辑也跟着出问题。记住一个原则：

提交规范对CI的影响

提交信息写得好不好，直接影响CI的决策能力。我建议团队统一使用Conventional Commits规范：

feat: 新增用户登录模块
fix: 修复登录超时异常
chore: 更新依赖版本
docs: 完善API文档

为什么这个重要？因为在CI眼里，提交类型决定了触发策略：

• feat：触发全部自动化测试 + 代码扫描
• fix：触发单元测试 + 集成测试
• docs：只触发文档构建，跳过测试
• chore：触发依赖安全检查

我在项目里还踩过一个坑：有人把fix写成了fixed，CI匹配规则没命中，导致测试被跳过。所以，约定大于配置，规则写进代码里，不如写进规范里。

分支模型对CI的影响

不同的分支模型，直接决定了CI流水线的复杂度。我总结过三种常见模型，你可以对照自己的项目看看：

你想想看，如果团队用的是Git Flow，长期保留develop和feature分支，CI只在合并到develop时触发一次。问题是，这个周期可能是几天甚至几周。中间如果出了bug，修复成本会越来越高。

我个人的习惯是：尽量缩短分支的生存期。Feature分支最好不要超过2天，超过就拆成更小的任务。

合并策略对CI的影响

很多团队纠结一个问题：合并时该用merge还是rebase？

从CI角度看，我推荐先rebase再merge。为什么？

• Merge commit：保留完整历史，但你每次触发的CI是在「合并后的结果」上跑的。如果流水线失败，回滚的是整个merge commit，代价大。
• Rebase：将当前分支的修改重放在目标分支之上，每个提交都是线性历史。CI可以逐个提交验证，问题定位更精确。

# 我习惯的流程
git checkout feature/login
git rebase main
# 解决冲突后
git push --force-with-lease
# 创建PR，触发CI

这里有个坑：很多人不敢用git push --force，怕覆盖别人的代码。改用--force-with-lease，它会检查远程分支是否被更新过，更安全。

SVG：分支策略与CI集成框架

下面这张图，展示了分支策略如何与CI流水线形成完整闭环：

分支策略选择建议

根据我的经验，没有「最好」的分支模型，只有「最合适」的。

给你几条直接可用的建议：

1. 小团队（< 10人）：直接用GitHub Flow，分支即PR，PR即部署。简单粗暴，效果很好。
2. 中大型团队：Trunk-based + Feature Toggle。主分支永远可部署，新功能靠开关控制。CI只需要验证主分支和短期特性分支。
3. 有发布周期要求的项目：Git Flow + 自动化合并。把合并时间点固定下来，比如每周一和周四触发一次CI。

常用Git命令与CI关联

下面这些命令，在CI场景下特别常用，我列出来供你参考：

# 检查当前分支是否干净
git status --porcelain

# 获取最新的远程分支信息
git fetch origin main

# 查找两个分支之间的差异文件
git diff --name-only main...HEAD

# 查找某次提交引入的文件变更
git show --name-only --format="" <commit-id>

# 检查分支是否存在
git branch --list feature/login

这些命令在CI脚本里经常用来做增量分析。比如，git diff --name-only可以告诉CI：这次改动只影响了哪些文件？如果只改了文档，那就跳过测试。如果改了核心模块，就触发全量测试。