3、版本控制与分支策略：Git核心概念、Git Flow vs Trunk Based、分支命名规范、Commit Message规范

版本控制这件事，说白了就是给项目装一台「时光机」。我见过太多团队，代码改着改着就乱了，最后谁也说不清哪一版是能跑的。嗯，今天我们就来聊聊 Git 的那些核心玩法，以及我这些年踩过的坑。

3.1 Git 核心概念：你只需要记住这几个

Git 其实没那么玄乎。我个人习惯把它的核心概念浓缩成三样东西：提交（Commit）、分支（Branch）、合并（Merge）。

• 提交（Commit）：就像给代码拍了一张快照。每次提交都记录了一个完整的状态，你可以随时回到过去。
• 分支（Branch）：说白了就是一条独立的时间线。你可以在自己的分支上瞎折腾，不影响别人。
• 合并（Merge）：把两条时间线重新接起来。这里最容易出问题，我后面会讲。

我在项目中遇到过最典型的情况：新人直接在主分支上改代码，改到一半发现 bug 更多了，想回退又不知道怎么退。其实只要养成「先建分支再动手」的习惯，这种问题根本不会发生。

3.2 Git Flow vs Trunk Based：两种流派，各有千秋

关于分支策略，业界主要有两派：Git Flow 和 Trunk Based。我两种都用过，说说我的感受。

3.2.1 Git Flow：适合大型项目，但有点重

Git Flow 把分支分成了五类：master、develop、feature、release、hotfix。结构清晰，但说实话，小团队用起来有点累。

分支类型	用途	生命周期
master	生产环境代码，只接受合并	永久
develop	日常开发的主线	永久
feature/*	新功能开发	短期
release/*	发布前的准备	短期
hotfix/*	紧急修复生产问题	极短期

我曾经在一个 50 人的团队里用 Git Flow，每次合并都要走一堆流程。好处是稳定，坏处是慢。如果你团队超过 20 人，或者项目需要严格管控发布，Git Flow 是个好选择。

3.2.2 Trunk Based：轻量高效，适合快速迭代

Trunk Based 就简单多了：所有人都在 main 分支上开发，但每次提交前必须保证代码是能跑的。分支只用来做短期开发，通常不超过两天。

说白了，Trunk Based 就是「小步快跑」。我现在的团队就用这个模式，每天合并几十次，只要 CI 过了就直接上。效率确实高，但要求团队纪律性很强。

3.3 分支命名规范：别让名字成为灾难

分支命名这件事，看起来小，但乱起来真要命。我见过有人用 fix-bug、test、aaa 这种名字，过两周自己都忘了是干嘛的。

我个人习惯用这套规范：

• 功能分支：feature/功能描述-日期，比如 feature/login-page-20240101
• 修复分支：fix/问题描述-日期，比如 fix/null-pointer-20240102
• 发布分支：release/版本号，比如 release/v2.1.0
• 热修复分支：hotfix/问题描述-日期，比如 hotfix/crash-on-startup-20240103

3.4 Commit Message 规范：写好备注，造福后人

Commit Message 这件事，我刚开始做开发时完全不在意，经常写「修改」、「更新」、「fix」这种。直到有一次要回退版本，看着一堆「update」完全不知道哪个是哪个……

现在我用的是 Conventional Commits 规范，结构很简单：

<类型>: <简短描述>

<详细描述（可选）>

<关联的 Issue 或任务编号（可选）>

类型主要有这些：

• feat：新功能
• fix：修复 bug
• docs：文档更新
• style：代码格式调整（不影响逻辑）
• refactor：重构
• test：测试相关
• chore：构建、工具等杂项

举个例子：

feat: 添加用户登录功能

实现了基于 JWT 的登录认证，包括 token 生成和验证。
关联任务：TASK-1234

你想想看，如果每个提交都这么写，回退版本时一眼就能看出哪个提交是干嘛的。我现在的团队就强制要求所有提交必须按这个格式来，谁不写谁请喝咖啡。

3.5 知识体系总览

下面这张图是我自己画的，把本章的核心逻辑串起来了。你看一眼就能明白 Git 分支策略的全貌。

好了，Git 分支策略这块就聊到这儿。记住一句话：版本控制不是技术问题，是习惯问题。养成好习惯，比学什么高级命令都管用。