4、版本控制与分支策略：Git基础操作、GitFlow工作流、主干开发模式、代码Review流程
版本控制这件事，说白了就是团队的「后悔药」和「时光机」。我见过太多项目因为版本管理混乱，最后上线时都不知道该发布哪个版本。嗯，今天我们就来聊聊Git的那些事儿。
4.1 Git基础操作：你每天都在用的那些命令
Git的基本操作，其实你每天都在用。但很多人只是机械地敲命令，并不理解背后的原理。我个人习惯把Git操作分为三类：本地操作、远程交互、分支管理。
4.1.1 本地操作三板斧
# 初始化仓库
git init
# 添加文件到暂存区
git add .
# 提交到本地仓库
git commit -m "feat: 添加用户登录功能"这里有个坑，我踩过好几次。就是git add .会把所有文件都加进去，包括那些不该提交的临时文件。所以我建议你养成好习惯，先git status看看哪些文件变了，再用git add指定文件。
4.1.2 远程交互要小心
# 拉取最新代码
git pull origin main
# 推送本地提交
git push origin feature/login我曾经在项目中遇到过，有人直接git push --force把别人的提交给覆盖了。那场面，简直是一场灾难。记住，--force是核武器，能不用就别用。
⚠️ 警告： 永远不要在公共分支上使用
git push --force。如果确实需要强制推送，先和团队沟通，确保没人正在基于你的分支工作。
4.2 GitFlow工作流：经典的分支模型
GitFlow是我最早接触的分支策略，它把分支分得很细。说实话，刚开始我觉得挺复杂的，但用久了发现，它确实能应对复杂的发布场景。
4.2.1 核心分支
| 分支类型 | 命名规则 | 用途 |
|---|---|---|
| 主分支 | main / master | 生产环境代码，只接受合并 |
| 开发分支 | develop | 日常开发集成，功能分支的基线 |
| 功能分支 | feature/* | 开发新功能，从develop拉出 |
| 发布分支 | release/* | 准备发布版本，从develop拉出 |
| 热修复分支 | hotfix/* | 紧急修复生产问题，从main拉出 |
4.2.2 工作流程
# 1. 从develop创建功能分支
git checkout -b feature/login develop
# 2. 开发完成后合并回develop
git checkout develop
git merge --no-ff feature/login
# 3. 准备发布时创建release分支
git checkout -b release/1.2.0 develop
# 4. 修复bug后合并到main和develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "版本1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
💡 小技巧： 使用
--no-ff 参数可以保留分支历史，方便以后追溯。我个人习惯所有合并都加这个参数。
4.3 主干开发模式：简单粗暴但有效
主干开发模式，说白了就是大家都在一条主干上干活。你想想看，如果团队只有5个人，搞那么复杂的分支策略是不是有点多余？
4.3.1 核心原则
- 所有开发都在main分支上进行
- 提交要小而频繁，最好每天多次
- 通过特性开关控制功能上线
- 代码必须通过CI/CD才能合并
4.3.2 什么时候用主干开发？
我在项目中遇到过这样的情况：一个10人的小团队，用GitFlow搞得大家天天合并冲突。后来我们切换到主干开发，效率反而提升了。主干开发适合：
- 小团队（10人以下）
- 持续交付成熟度高的团队
- 功能粒度小的项目
- 有完善的自动化测试覆盖
🔑 关键点： 主干开发不是没有分支，而是分支的生命周期很短。通常一个分支只存在几个小时，而不是几天或几周。
4.4 代码Review流程：不只是找bug
代码Review这件事，很多人觉得就是找bug。其实不然，它更重要的目的是知识传递和代码规范统一。我见过最差的Review就是「LGTM」三个字母就完事了。
4.4.1 Review流程
1. 开发者创建Pull Request
2. 填写PR描述（做了什么、为什么、怎么测试）
3. 指定Reviewer（至少2人）
4. Reviewer逐行审查
5. 提出修改意见
6. 开发者修改后重新请求Review
7. 所有Reviewer批准后合并4.4.2 Review清单
| 检查项 | 具体内容 |
|---|---|
| 功能正确性 | 代码是否实现了需求？边界情况处理了吗？ |
| 代码质量 | 命名是否清晰？函数是否过长？有没有重复代码？ |
| 安全性 | 有没有SQL注入风险？用户输入是否校验？ |
| 性能 | 有没有不必要的循环？数据库查询是否优化？ |
| 可测试性 | 代码是否容易写单元测试？有没有依赖注入？ |
⚠️ 避坑指南： 我曾经见过一个团队，Review时只关注代码风格，忽略了严重的逻辑错误。结果上线后出了大问题。记住，功能正确性永远比代码风格重要。
4.5 如何选择分支策略？
你可能会问，到底该用哪种分支策略？我的建议是：
- 小团队、快速迭代 → 主干开发模式
- 多版本并行、复杂发布 → GitFlow
- 介于两者之间 → GitHub Flow（简化版GitFlow）
其实没有银弹。我在不同项目里用过不同的策略，关键是要适合团队当前的规模和节奏。嗯，记住一点：分支策略是为团队服务的，不是反过来。
💡 我的建议： 刚开始用GitFlow，等团队成熟了再考虑切换到主干开发。不要一上来就搞最复杂的，容易把团队搞懵。
好了，这一章的内容就到这里。下一章我们会聊聊持续集成和持续部署，那是让代码真正跑起来的环节。