2. Git基础与分支策略：版本管理的基石
说实话，我见过太多团队在版本管理上栽跟头了。有的项目代码乱成一锅粥，有的上线前才发现合并冲突。这些问题，说白了都是Git没用好。今天我就把这些年积累的经验，跟大家好好聊聊。
2.1 Git核心概念：你得先搞懂这几个东西
仓库（Repository）
仓库就是你的代码家。我习惯把本地仓库比作「草稿本」，远程仓库比作「正式出版物」。你在本地随便改，改好了再推送到远程。
核心要点：
- 本地仓库：你电脑上的.git目录
- 远程仓库：GitHub/GitLab上的项目
- 工作区：你正在编辑的文件
- 暂存区：准备提交的临时区域
提交（Commit）
提交就是给代码拍张快照。我经常跟团队说：「每次提交都要像写日记一样，记录清楚你干了什么。」
# 好的提交信息示例
git commit -m "fix: 修复用户登录时token过期未刷新问题"
# 不好的提交信息
git commit -m "改了点东西"我的习惯：每次提交前先git diff看看改了啥。曾经有一次我手滑把配置文件也提交了，结果线上环境崩了一下午。从那以后，我提交前必看diff。
分支（Branch）
分支就是平行宇宙。每个分支可以独立开发，互不干扰。我见过最夸张的团队，一个项目有50多个分支同时存在...嗯，那场面确实壮观。
标签（Tag）
标签是给历史版本贴个标签。我一般只在发布正式版本时打标签，比如v1.0.0、v2.3.1这样。
# 打标签
git tag -a v1.0.0 -m "正式发布1.0.0版本"
# 查看标签
git tag -l2.2 分支模型对比：Git Flow vs Trunk Based
这两个模型我都在实际项目中用过。Git Flow适合大型项目，Trunk Based适合快速迭代。你想想看，选哪个取决于你的团队节奏。
Git Flow：经典但有点重
- master分支：只放稳定版本
- develop分支：日常开发主分支
- feature分支：新功能开发
- release分支：发布前准备
- hotfix分支：紧急修复
我曾经踩过的坑：用Git Flow时，团队有5个人同时开发，结果合并冲突处理了整整两天。后来我学乖了，小团队用Trunk Based更合适。
Trunk Based：轻量高效
- 只有一个主分支（trunk/main）
- 开发直接提交到主分支
- 通过特性开关控制功能上线
- 适合持续集成/持续部署
我的建议：团队小于10人，用Trunk Based。大于10人，考虑Git Flow。但不管用哪个，分支数量别超过5个，否则管理成本太高。
2.3 团队协作中的版本管理规范
这部分是我最想强调的。规范不是束缚，而是保护。我见过太多因为不规范导致的事故了。
提交规范
| 类型 | 说明 | 示例 |
|---|---|---|
| feat | 新功能 | feat: 添加用户注册功能 |
| fix | 修复bug | fix: 修复空指针异常 |
| docs | 文档更新 | docs: 更新API文档 |
| refactor | 重构 | refactor: 优化数据库查询 |
分支命名规范
# 推荐格式
feature/功能名称-日期
bugfix/问题编号
hotfix/紧急修复描述
# 实际例子
feature/login-20240115
bugfix/ISSUE-1234
hotfix/critical-security-patch避坑指南：我曾经见过有人用「feature/最终版」「feature/最终版2」「feature/绝对最终版」这种命名...嗯，后来那个项目重构了。分支命名一定要清晰，别偷懒。
代码审查流程
- 开发完成后创建Pull Request
- 至少2人审查通过才能合并
- 合并前必须通过CI/CD流水线
- 合并后删除源分支
2.4 知识体系总览
这张图基本概括了本章的核心内容。记住，Git只是工具，真正重要的是团队怎么用它。我见过用Git很烂但项目成功的团队，也见过Git用得飞起但项目一塌糊涂的。关键还是人，是规范，是流程。
最后说一句：版本管理没有银弹。Git Flow也好，Trunk Based也罢，适合你的才是最好的。我建议你先小范围试点，跑通了再推广。别一上来就搞大跃进，容易翻车。