Git进阶工作流：GitFlow、Feature Branch、Pull Request流程、标签管理
说实话，很多团队用Git，就停留在「add、commit、push」三板斧。我见过不少项目，master分支上乱七八糟，hotfix和feature混在一起，发布时全靠人工记版本。嗯，这其实挺危险的。
今天聊的这几个工作流，说白了就是给团队协作定规矩。规矩定好了，冲突少了，发布也稳了。我个人习惯是：小团队用Feature Branch，中大型项目上GitFlow，配合PR流程和标签管理，基本能覆盖90%的场景。
一、GitFlow：经典的分支模型
GitFlow是2010年Vincent Driessen提出的。到现在十几年了，虽然有人觉得它重，但我在嵌入式项目里用下来，感觉它特别适合有固定发布周期的产品。
核心分支就两条：master和develop。master只存正式发布的代码，develop是日常开发的主线。除此之外，还有三种辅助分支：
- Feature分支：从develop拉出来，开发新功能。开发完合并回develop。
- Release分支：从develop拉出来，做发布前的测试和修bug。修完合并到master和develop。
- Hotfix分支：从master拉出来，紧急修复线上问题。修完合并到master和develop。
我曾经在一个车载项目里用过这套模型。当时有个紧急的CAN总线bug，直接在master上拉了hotfix分支，修完合并回去，develop上的新功能完全不受影响。你想想看，如果没有这个隔离，那得多乱。
关键点：GitFlow的核心价值在于「隔离」。不同目的的分支互不干扰，发布流程清晰可控。
二、Feature Branch：轻量级的替代方案
如果你的团队不大，或者项目迭代很快，GitFlow可能显得有点重。这时候Feature Branch模式就派上用场了。
说白了，就是所有开发都在feature分支上做，做完直接合并回master。没有develop分支，也没有release分支。简单粗暴。
我有个朋友做IoT网关，团队就5个人，用GitFlow觉得太啰嗦。后来改成Feature Branch，配合CI自动测试，效率反而高了。不过要注意：master必须保持可发布状态，合并前一定要做code review。
我的建议：Feature Branch适合10人以下、持续交付的团队。如果项目有固定版本号，还是用GitFlow更稳。
三、Pull Request流程：代码质量的守门员
PR不是Git的原生功能，是GitHub、GitLab这些平台提供的。但它的价值，怎么说呢，我见过太多团队因为省掉这一步，线上出过不少幺蛾子。
一个标准的PR流程大概是这样的：
- 从master或develop拉出feature分支。
- 在feature分支上开发、提交。
- 推送到远程仓库，发起PR。
- 指定reviewer，进行代码审查。
- 通过后，合并到目标分支。
我曾经在一个项目中，因为PR审查不严，有人把调试用的printf直接带到了release版本。结果产品在现场跑起来，控制台疯狂刷日志，把flash写坏了。嗯，从那以后，我要求所有PR必须至少两个人review，而且必须通过CI。
避坑指南：PR合并前，一定要确保目标分支是最新的。我曾经见过有人合并时产生大量冲突，最后手工解决时漏掉了一行关键代码，导致编译通过但运行时崩溃。
四、标签管理：版本发布的锚点
标签（Tag）在Git里是个轻量级的概念，但用好了，它就是版本管理的基石。我个人习惯是：每次发布，都在master上打一个annotated tag。
为什么用annotated tag？因为它包含作者、日期、备注信息。轻量级tag就是个指针，信息太少，不适合正式发布。
# 创建annotated tag
git tag -a v1.2.0 -m "Release version 1.2.0: 修复CAN总线超时问题"
# 推送tag到远程
git push origin v1.2.0
# 查看所有tag
git tag -l
# 查看tag详细信息
git show v1.2.0
标签的命名规范也很重要。我推荐用语义化版本号：v主版本.次版本.修订号。比如v2.1.3，表示主版本2，次版本1，修订号3。如果只是修bug，修订号+1；加了新功能但兼容旧版，次版本+1；做了不兼容的改动，主版本+1。
| 标签示例 | 含义 |
|---|---|
| v1.0.0 | 第一个正式版本 |
| v1.1.0 | 新增功能，兼容v1.0.0 |
| v1.1.1 | 修复v1.1.0的bug |
| v2.0.0 | 不兼容旧版的大版本 |
小技巧：在CI/CD流水线中，可以自动检测tag，触发构建和发布。我习惯在打tag后，自动生成release notes，省去手动整理的麻烦。
五、整体工作流关系图
下面这张图，把GitFlow、Feature Branch、PR流程和标签管理串在了一起。你可以看到不同分支的生命周期，以及它们如何配合。
六、实际项目中的组合拳
说了这么多，到底怎么用？我拿一个真实的嵌入式项目举例：
- 日常开发：从develop拉feature分支，开发完提PR，review通过后合并回develop。
- 版本发布：从develop拉release分支，测试修bug，稳定后合并到master，打tag v1.2.0。
- 紧急修复：从master拉hotfix分支，修完合并到master和develop，打tag v1.2.1。
这套流程，我在三个项目里用过，效果都不错。唯一要注意的是：分支别太多，否则管理成本会上升。我建议同时活跃的feature分支不超过5个，超过就说明团队粒度太细了。
总结一下：GitFlow管结构，Feature Branch管开发，PR管质量，Tag管版本。四者配合，基本能覆盖从开发到发布的全流程。
嗯，今天就聊到这儿。这些工作流不是银弹，但用好了，确实能让团队协作顺畅很多。你可以在自己的项目里试试，慢慢找到最适合的那一套。