Git代码管理

分支管理策略

TrunkBased

Trunk-Based Development（简称 TBD）是一种 更轻量、更现代的 Git 分支策略，跟 GitFlow 的“分支分工明确”理念不同，TBD 主张的是：

大家都直接在主分支（trunk，通常叫 main 或 master）上开发，尽可能少开分支、快速合并、持续集成。

🌱 核心理念

1. 只有一个主分支（trunk）
   1. 所有开发人员每天（甚至多次）将自己的代码合并到 trunk。
   2. 保证 trunk 始终处于可构建、可部署的状态。
2. 短生命周期的分支（if any）
   1. 如果有 feature 分支，也必须非常短（几小时到一两天）。
   2. 多数改动直接通过小步提交（small commits）+ feature flag 控制上线节奏。
3. 强依赖 CI（持续集成）
   1. 每次 push 都会触发自动构建、测试。
   2. 合并代码前需通过所有自动化测试。

✅优点

优点	说明
⚡ 迭代快速	所有人每天多次向主干提交，持续推进开发
🧹 分支极简	避免维护多个长期分支，减少合并麻烦
✅ 持续集成友好	每次提交自动触发 CI/CD，提高反馈速度
🔍 减少“代码漂流”	不存在长期未合并的 feature 分支，冲突早暴露早解决
🛠️ 鼓励小步快跑 + 精细测试	搭配自动化测试、feature flag，上线更灵活
💡 更贴合 DevOps / 云原生 / 微服务开发	配合自动部署，真正实现持续交付（CD）

❌缺点

缺点	说明
🔐 需要严格的 CI/CD 支撑	没有良好测试和代码审查机制，很容易破坏主干
🧪 未完成功能需额外隔离机制	比如 feature flag、环境切换，否则可能影响用户
🧠 需要成熟的团队协作习惯	所有人必须频繁合并、快速修复冲突、严格审查
📦 没有明确“发布分支”概念	对需要长期维护旧版本的项目不太友好（如企业软件）

适用场景

Trunk-Based Development 更适合“快速迭代 + 自动化部署”的现代开发模式，但前提是你有成熟的 CI/CD 流程和严格的团队协作。

场景	是否推荐	说明
✅ 敏捷开发团队	✔️ 强烈推荐	快节奏、小步迭代，配合 CI 效果最佳
✅ 持续交付/部署环境（CI/CD）	✔️ 推荐	自动部署 + feature flag 控制上线
✅ 微服务/云原生项目	✔️ 推荐	适合解耦、独立发布的架构 每个服务可以独立地采用主干开发模式，各自拥有较短的开发周期和较快的发布节奏。
✅ DevOps文化的团队	✔️ 推荐	开发/运维一体化，更强调稳定 + 快速响应
❌ 缺乏测试或流程工具支撑的团队	❌ 不推荐	主干代码不稳定会直接影响产品质量
❌ 有复杂版本维护需求的传统软件	❌ 不推荐	缺少发布分支，不适合长期 LTS 支持

GitFlow

GitFlow 定义了 五种主要分支类型，各自有明确的职责：

1. master 主分支**
   1. 永远保持稳定、可随时部署上线的代码。
   2. 每次发布版本都会打一个 tag（比如 v1.0.0）。
2. develop 开发分支**
   1. 所有开发功能的集成分支。
   2. 新功能开发完成后会合并到这个分支。
   3. 从 develop 分支创建 release 或 feature 分支。
3. feature/*** 新特性分支**
   1. 用于开发新功能，从 develop 分支拉出。
   2. 开发完成后合并回 develop。
4. release/*** 版本发布分支**
   1. 准备发布的分支，从 develop 拉出。
   2. 进入测试阶段，主要进行 bug 修复、文档完善、准备发布。
   3. 最终合并到 master 和 develop。
5. hotfix/*** 线上问题分支**
   1. 用于紧急修复线上生产环境问题。
   2. 从 master 分支拉出，修复后合并回 master 和 develop。

✅ GitFlow 的优点

优点	说明
🔧 清晰的分支结构	明确区分开发、测试、发布、修复等阶段，降低混乱
👥 适合多人协作	不同职责可以在不同分支上并行推进
🔄 便于版本管理	每次发布都打 tag，可清晰追踪版本变更历史
🛠️ 支持发布前测试	release 分支允许发布前进行集成测试和优化
🧯 紧急修复机制清晰	hotfix 分支确保线上问题快速修复并同步到 develop
✅ 适配传统发布节奏	非持续部署的项目可以按需发布版本，流程可控

❌ GitFlow 的缺点

缺点	说明
🌀 流程繁琐	分支较多，新手上手门槛高，容易出错
🕒 合并频率低，容易冲突	特别是在多人并行开发时，长时间不合并会产生大冲突
🚀 不适合持续部署/快速迭代	分支粒度和周期与敏捷开发/DevOps 理念不一致
🔁 需要手动维护多个分支	发布时要合并到多个分支（master、develop），易出漏
⚙️ 依赖人为操作较多	没有自动化或 CI/CD 支持时维护成本高

适用场景

GitFlow 适合节奏较慢、有明确发布周期和质量控制要求的团队；
不适合追求极致效率和持续部署的现代 DevOps 环境。

场景	是否推荐	说明
✅ 传统企业项目	✔️ 推荐	有明确版本节奏（如每季度一次发布）
✅ 需要稳定发布流程的团队	✔️ 推荐	需要专门的 release 流程和测试周期
✅ 中大型开发团队	✔️ 推荐	各模块可并行开发，分支机制能保持协作秩序
严格的预发版与生产环境隔离	✔️ 推荐	需要确保新特性在正式发布前经过充分测试和集成验证的项目。
⚠️ CI/CD 不成熟的团队	✔️ 推荐	可以用分支替代部分自动化工作
❌ 频繁上线/微服务架构	❌ 不推荐	不适合持续交付、快速部署场景
❌ 敏捷开发+特性开关模式	❌ 不推荐	分支复杂度反而增加沟通成本

AOneFlow

由阿里巴巴技术专家林帆基于 TrunkBased 和 GitFlow 提出的一种新改进，其主要分为三种分支类型：主干分支、特性分支以及发布分支，AOneFlow = 单主干 + 灵活分支 + 发布策略清晰 + 强化自动化

核心思路是：

1. 只维护一个长期主分支（如 main）
2. 所有的功能开发、修复、发布都在临时分支中进行，生命周期短
3. 分支命名统一规范，合并策略清晰（支持 squash / merge / rebase）
4. 强依赖 CI/CD 工具链来保障质量和效率

✅ AOneFlow 的优点

优点	说明
🔄 分支管理简单	没有 develop、hotfix、多个长期分支的混乱
⚡ 开发流程快速	和 Trunk-Based 类似，分支生命周期短，合并快
🔍 更适合敏捷 + CI/CD	可以配合流水线快速测试部署
🧩 分支命名统一，语义清晰	易于沟通、审查、自动化处理
🛠️ 兼容 GitHub Flow、GitLab Flow、Trunk-Based	可以根据团队规模调整策略灵活性

❌缺点

缺点	说明
📐 需要团队规范强一致性	命名、合并策略、CI 要严格统一
🔁 需要一定自动化基础	否则容易退化为混乱分支乱合
🧠 文档和传播较少	还不是主流标准，学习资料相对较少
🎯 需要团队理解其哲学	否则可能不如 GitFlow 易懂直观

适用场景

场景	是否推荐	说明
✅ 敏捷团队、DevOps	✔️ 推荐	流程快速、自动化友好
✅ CI/CD 完善	✔️ 推荐	每次合并都能自动测试、部署
✅ 远程或跨区域团队协作	✔️ 推荐	语义分支 + 明确规则减少沟通成本
⚠️ 项目流程保守、手动为主	⚠️ 慎用	自动化程度低可能难以发挥其优势

---

如何选择分支策略？

根据项目需求和团队规模，合理规划项目仓库结构。可根据以下思维导图，选择适合的分支管理策略。

---

代码提交规范

🌱分支管理

main       # 主分支，始终保持可部署状态
develop    # 开发分支，日常开发合并到这里
feature/*  # 新功能开发分支（如 feature/login）
bugfix/*   # 修复 bug 分支
hotfix/*   # 线上紧急修复
release/*  # 预发布分支

1. 不在 main 分支直接开发。
2. 每个开发任务（feature/bug）都需从 develop 分出，完成后合并回 develop。
3. 发布前将 develop 合并到 release，测试通过后再合并进 main

🔄代码更新

1. 鼓励频繁拉取代码。开发者应养成定期从远程仓库拉取（fetch）并合并（merge）主分支或 其他开发分支到本地对应分支的习惯，以保持代码与团队其他成员同步。
2. 及时更新的目的：防止冲突代码越来越多，越来越难处理；防止打包时，漏掉其他人提交的代 码。

git checkout develop
git pull origin develop
git checkout feature/xxx
git merge develop --no-ff  # 或 git rebase develop，不使用快进方式合并

⚔️ 冲突合并

检测和解决冲突：

1. 当拉取远程分支时，如果出现合并冲突，Git会提示并停止合并进程。
2. 出现冲突千万不要强行合并，需要跟相关人员确认并处理完每个冲突。
3. 使用 git diff 等命令查看冲突详情，手动编辑冲突文件，保留正确的更改并删除冲突标记。

确认解决冲突后提交：

1. 解决完所有冲突后，需要执行 git add 命令添加已解决冲突的文件，然后使用规范化的提交信息格式进行提交。
2. 提交消息中应明确指出此次提交涉及冲突解决的部分。

🏷️提交信息格式化

<type>[optional scope]: <description>
[BLANK LINE]
[optional longer description]

type （类型）：描述提交的类型，通常是一个简短的动词，用于表示此次提交的主要性质。

常见的类型包括但不限于：

类型	含义
feat	新功能
fix	修复问题
docs	仅文档修改
style	代码格式（不影响功能）
refactor	重构代码（无新增功能或修复）
perf	性能优化
test	测试相关的修改
chore	构建过程或辅助工具的变更
revert	回滚上一次提交

optional scope （可选，范围）：用于进一步描述该提交影响的模块、组件或区域。例如，如 果在一个大型项目中修复了某个特定模块的bug，则可以写为 fix(parser): 。

description （描述）：简洁明了地概述这次提交做了什么。应该使用现在时态，并且首字 母大写。

optional longer description （可选，详细说明）：如果有需要，可以在空行后提供详细 的变更解释、原因分析、兼容性影响等。

feat(用户管理)：添加禁用/解禁用户的功能

新增了一个新的API接口，并对应调整了数据库表结构以支持用户的禁用和解禁操作。
同时包含了对此功能的单元测试。

代码审查

1. 所有 PR 必须经过 至少一位团队成员 Review 后方可合并。
2. 提交 PR 前请确保：
   1. 功能开发完成，测试通过。
   2. 遵守 lint 规范，无 ESLint 报错。
   3. 添加了必要的测试用例。
3. 评审人需检查：
   1. 代码质量、命名规范
   2. 逻辑正确性
   3. 是否有重复代码
   4. 是否引入了未使用的依赖/模块

---

持续集成部署、发布