版本控制与CI集成：分支策略与自动触发

聊到CI，版本控制是绕不开的基石。你想想看，没有清晰的分支策略，流水线就像没头苍蝇——不知道从哪接代码，往哪部署。Webhook则是CI的“眼睛”，没有它，代码变了CI也看不见。这部分内容我踩过不少坑，今天结合实战经验，把分支策略、Webhook配置和代码合入触发捋清楚。

分支模型的选择

分支模型直接影响CI的触发策略。我经历过两种主流模式：GitFlow 和 Trunk-Based Development。

GitFlow的分支又多又长： feature → develop → release → master，每层都可能触发不同流水线。但我在项目中发现，分支多导致合并冲突频繁，CI排队也慢。后来切换到Trunk-Based，所有开发都在main分支上，或者最多加个短期feature分支。这才发现CI爽多了——push即触发，冒烟测试几分钟跑完。

Webhook配置：CI的“传感器”

Git仓库怎么知道代码变了？靠Webhook。说白了就是你告诉Git平台：“嘿，代码有变化时，往这个URL扔个POST请求”。CI服务器（比如Jenkins、GitLab CI Runner）收到请求后就开始拉代码、跑流水线。

配置时注意三点：

• URL + ： 设置一个带secret 的URL，避免第三方随意触发。我见过有人直接裸URL，结果被恶意刷CI，服务器直接挂了。
• 事件选择： 通常选 push 和 pull_request。但注意——如果是GitHub，pull_request事件分为opened、synchronize、closed等。我建议至少勾选“推送到分支”和“pull request创建/同步”。
• 白名单IP： 只让Git平台的IP段访问你的CI端点，再加一层防护。

# 示例：Jenkins Webhook URL (GitHub设置)
https://jenkins.example.com/github-webhook/
# 在Jenkins中配置Secret ，然后在GitHub仓库设置中填入同一

代码合入触发流水线

分支策略和Webhook都准备好了，剩下就是“什么时机触发什么流水线”。我一般按这个逻辑：

1. Push到feature分支 → 触发单元测试 + 代码扫描（快速验证，不跑冒烟）
2. Pull Request创建/更新 → 触发冒烟测试 + 集成测试（确保合入前质量）
3. PR合并到main → 触发完整流水线：冒烟→集成→部署（或仅冒烟，视项目而定）

这里特别说下PR合并触发。GitHub的 pull_request 事件有个“closed”类型，当PR被合并时也会触发。你可以在CI里判断 merged == true 后再执行部署。我见过团队直接把PR合并和master push都当作触发源，结果重复触发两次。建议只监听master的push事件，或者用 pull_request closed + 合并状态判断。

# Jenkins Pipeline 片段：根据分支判断流水线类型
def branch = env.BRANCH_NAME
if (branch == 'main') {
    // 全量冒烟测试
    runSmokeTest()
} else if (branch.startsWith('feature/')) {
    // 仅单元测试
    runUnitTest()
}