版本控制基础：Git核心概念、分支策略、标签与发布管理
聊版本控制，绕不开Git。说实话，我见过太多团队在Git上翻车了——不是不会用，而是没想清楚怎么用。今天咱们就把这块掰开揉碎了讲清楚。
Git核心概念：你真正需要理解的几个东西
Git的核心概念其实不多，但很多人一开始就被那些术语搞晕了。我个人的经验是，先搞懂三个东西：提交（commit）、分支（branch）、引用（ref）。其他的都是这三个的衍生。
提交（Commit）
提交就是一次快照。每次你执行git commit，Git都会把当前工作区的状态拍个照，然后记下来。每个提交都有一个唯一的SHA-1哈希值，这就是它的身份证。
关键点：提交是不可变的。一旦创建，它的内容、父提交、时间戳都不能改。如果有人告诉你他能改历史，那其实是在创建新的提交，然后把旧的扔掉。
我在项目中遇到过一个问题：有同事用git commit --amend改了一个已经推送的提交，结果其他人拉代码时直接冲突。嗯，这就是没理解“提交不可变”这个原则。
分支（Branch）
分支说白了就是一个可移动的指针。它指向某个提交。当你创建新分支时，Git只是创建了一个新的指针，并没有复制任何文件。这也是Git比SVN快的原因之一。
# 创建分支
git branch feature/login
# 切换分支
git checkout feature/login
# 或者一步到位
git checkout -b feature/login引用（Ref）
引用包括分支、标签、HEAD等。HEAD是一个特殊引用，它指向你当前所在的分支。我个人习惯把HEAD理解为“你现在在哪儿”的标记。
小技巧：当你处于“分离HEAD”状态时（即HEAD直接指向某个提交而不是分支），你做的任何提交都不会被任何分支引用。我曾经因为这个丢过代码，后来养成了习惯：不在分离HEAD状态下做重要修改。
分支策略：选对路子，少走弯路
分支策略没有银弹。我见过用Git Flow用得痛不欲生的团队，也见过只用master分支跑得飞起的团队。关键看你的发布节奏和团队规模。
Git Flow
经典的分支模型，适合有固定发布周期的项目。它有五个分支类型：
| 分支类型 | 命名规则 | 用途 |
|---|---|---|
| master | master | 生产就绪代码 |
| develop | develop | 日常开发集成分支 |
| feature | feature/* | 新功能开发 |
| release | release/* | 发布前准备 |
| hotfix | hotfix/* | 紧急修复 |
说实话，Git Flow对小型团队来说太重了。我曾经在一个5人团队里硬推Git Flow，结果光合并分支就占了一半时间。后来我们换成了更轻量的策略。
Trunk-Based Development（主干开发）
这个策略的核心思想是：所有开发都在主干（通常是master或main）上进行，分支的生命周期很短（一般不超过一天）。
核心原则：频繁提交，小步快跑。每次提交都应该是一个可工作的状态。
我个人比较推荐这种模式，尤其是做CI/CD的团队。你想想看，如果每个人都在自己的分支上开发两周，合并时那个酸爽...嗯，经历过的人都懂。
GitHub Flow
GitHub Flow是主干开发的变种。它只有master分支，所有开发都在feature分支上进行，通过Pull Request来合并。
# 典型流程
1. git checkout -b feature/new-feature
2. # 开发、提交
3. git push origin feature/new-feature
4. # 创建Pull Request
5. # 代码审查、测试
6. # 合并到master标签与发布管理
标签（Tag）是Git里最容易被人忽略但又最重要的功能之一。它本质上是一个不可移动的引用，专门用来标记重要节点——比如发布版本。
标签类型
Git有两种标签：轻量标签和附注标签。我强烈建议用附注标签，因为它包含了创建者、时间、消息等元信息。
# 轻量标签（不推荐）
git tag v1.0.0
# 附注标签（推荐）
git tag -a v1.0.0 -m "Release version 1.0.0"
# 推送标签到远程
git push origin v1.0.0
# 推送所有标签
git push origin --tags注意：标签一旦创建，不要删除或修改。如果发布错了，正确的做法是创建一个新的标签（比如v1.0.1），而不是把旧的标签挪走。我曾经见过有人删了标签重新打，结果导致CI/CD流水线混乱，部署了错误的版本。
语义化版本控制
版本号不是随便写的。我建议遵循语义化版本规范（SemVer）：主版本号.次版本号.修订号。
| 版本号 | 变更类型 | 示例 |
|---|---|---|
| 主版本 | 不兼容的API变更 | 1.0.0 → 2.0.0 |
| 次版本 | 向下兼容的功能新增 | 1.0.0 → 1.1.0 |
| 修订号 | 向下兼容的问题修复 | 1.0.0 → 1.0.1 |
发布管理流程
一个标准的发布流程应该是这样的：
- 从develop分支创建release分支
- 在release分支上做最后的测试和修复
- 打上版本标签
- 合并到master和develop
- 从master分支部署
避坑指南：我曾经在release分支上直接改代码，结果忘记合并回develop。下次开发时，develop里的代码还是旧的，导致功能冲突。后来我养成了习惯：release分支上的任何修改，都必须同时合并到master和develop。
知识体系总览
下面这张图把本章的核心内容串起来了。你可以把它当作一个快速参考：
好了，Git版本控制的基础就聊到这儿。记住一句话：工具是死的，策略是活的。找到适合你团队的节奏，比盲目追求“最佳实践”重要得多。