1. 问题背景：为什么我们放弃了“标准”GitFlow

2024年3月，我们的SaaS产品进入密集迭代期，每周要发布2次。当时用着标准的GitFlow：develop长期分支，feature分支从develop切出，合并回develop，每两周从develop拉release分支。

第一个问题：合并地狱。5个开发者在develop上并发，每次merge都会产生大量冲突。我们的代码库是单体Java服务，平均每次merge要花40分钟解决冲突。

第二个问题：发布周期失控。因为develop不稳定，我们不得不提前3天冻结代码，导致紧急bugfix无法及时进发布。2024年3月某次线上事故，fix分支从创建到上线用了22小时，被业务方投诉。

我们查了DORA报告，高效能团队部署频率是每天多次，变更前置时间小于1小时。而我们两周一次发布，前置时间2.3天——属于低效能团队。问题不在工具，而在分支模型与发布节奏的错配。

2. 环境与版本：我们用的具体工具链

• 代码托管：GitLab Enterprise 16.7（支持MR、Code Owners、Push Rules）
• CI/CD：GitHub Actions（因为团队已有GitHub私有仓库，通过GitLab Mirror同步）
• 本地Git版本：2.43.0（支持git worktree的稳定版本）
• 语言环境：Java 17 + Maven 3.9，单体应用，模块化程度中等

关键版本注意点：Git 2.40以上才支持git branch --rebase的默认策略调整，否则pull --rebase行为不一致。

3. 方案设计：动态TrunkBased分支模型

我们最终落地的策略是“动态TrunkBased”，核心规则：

• main：唯一长期分支，始终可发布。受保护，禁止直接push，只能通过MR合并。
• feat/*：从main切出，生命周期不超过3天。合并前必须rebase到最新main。
• fix/*：紧急修复，不经过feat，直接切出，合并后立即发布。
• 不允许develop、release、hotfix长分支。所有临时分支合并后立即删除。

核心逻辑是：任何改动必须在24小时内回到main，保持主干干净且可部署。我们通过MR模板强制约束。

4. 核心实现：分支保护、MR流水线、CI配置

4.1 分支保护规则（GitLab设置）

在GitLab的Settings → Repository → Protected Branches中配置：

Branch: main
Allowed to merge: Maintainers（禁止开发者直接合并）
Allowed to push: No one（必须通过MR）
Code owner approval: 至少1人
Pipeline must succeed: 开启

4.2 本地git配置与pre-commit钩子

每个开发者必须执行以下全局配置：

```bash

全局启用rebase策略，避免merge commit污染历史

git config --global pull.rebase true
git config --global branch.autosetuprebase always

创建worktree，支持并行开发多个feat

git worktree add ../feature-A -b feat/支付模块重构 main

安装pre-commit钩子（.git/hooks/pre-commit）

cat > .git/hooks/pre-commit Asia/Shanghai，并统一Docker容器的TZ`环境变量。

6. 效果数据：我们测了什么，提升了多少

从2024年4月切换到新策略，我们跑了8周，对比Q1的数据：

最直观的变化：原来自测+review+发布要走2天流程，现在因为main始终可部署，一个简单的bugfix（2个文件改动）从push到生产环境只需要40分钟（含15分钟CI，10分钟人工approve，15分钟滚动发布）。

7. 总结：价值与适用边界

这套动态TrunkBased策略不是银弹。适合：5-15人小团队、CI成熟、自动化测试覆盖率高（>40%）、产品迭代快。不适合：30人以上多团队并行、需要严格版本隔离的合规场景（如金融核心系统）。

关键收获：
1. 分支数量与发布频率成反比——分支越多，集成成本越高。
2. CI必须成为硬门禁——rebase check和test失败直接阻断merge，比人工review高效10倍。
3. 本地工具链决定协作效率——worktree和pre-commit钩子，投入产出比极高。

最后给一个建议：不要盲目崇拜任何工作流。GitFlow有它的适用场景，但我们用数据说话——如果你的团队部署频率低于每周一次，先解决CI和自动化测试，再谈分支策略。我们花了3周迁移，但收益是长期且显著的。