4. 版本控制实战

4.1 为什么C++项目需要一套Git规范？

说实话，我见过太多C++团队在Git上栽跟头了。

有人把整个项目塞在一个分支里，有人commit信息写「改bug」、「更新」、「111」。你想想看，一个大型C++项目，动辄几十万行代码，几十号人同时开发。没有规范，那就是灾难。

我个人习惯，在项目启动的第一天，就把Git规范定下来。这不是束缚，是保护。

4.2 分支策略：选对模型，少走弯路

分支策略有很多种。Git Flow、GitHub Flow、GitLab Flow……我该用哪个？

我的建议是：看团队规模和发布节奏。

4.2.1 小型团队（3-5人）推荐：GitHub Flow

• main：永远可部署
• feature/*：从main拉出，开发完合并回main
• 没有develop分支，没有release分支

简单直接。我在一个创业项目里用过，效果很好。缺点是，如果同时有多个feature在开发，main分支可能不太稳定。

4.2.2 中型团队（5-20人）推荐：Git Flow 简化版

嗯，这里要注意：不要把feature分支的生命周期拖太长。我曾经见过一个feature分支活了两个月，最后合并时冲突多到让人崩溃。

4.2.3 大型团队（20人以上）推荐：Trunk-Based Development + 短特性分支

• 所有开发者在主干（trunk/main）上工作
• 特性分支不超过2天
• 频繁合并，频繁集成

说白了，就是「小步快跑」。我参与过一个百人级别的C++项目，用的就是这种策略。每天合并几十次，但冲突反而少。为什么？因为每次改动都很小。

4.3 Commit规范：让历史变得可读

你打开git log，看到的全是「fix bug」、「update」、「commit」。你什么感觉？

反正我是想骂人。

4.3.1 我推荐的Commit格式

<type>(<scope>): <subject>

<body>

<footer>

举个例子：

feat(parser): 添加JSON配置文件的解析支持

实现了基于nlohmann/json的配置文件解析器。
支持嵌套对象和数组的读取。
添加了单元测试覆盖主要场景。

Closes #123

4.3.2 type类型说明

4.4 Code Review流程：不只是走形式

很多团队把Code Review搞成了「走过场」。点个赞，合并，完事。

这其实是在浪费机会。

4.4.1 我建议的Review流程

1. 提交PR前自检：跑一遍单元测试，检查代码风格
2. PR描述要清晰：说明改了啥、为什么改、怎么测试
3. 指定Reviewer：不要超过2个人，人多嘴杂
4. Reviewer在24小时内响应：拖太久会阻塞开发
5. 修改后重新请求Review：不要悄悄改

4.4.2 Review时看什么

• 逻辑正确性：代码能不能跑？边界情况处理了吗？
• 代码风格：符合团队的C++编码规范吗？
• 性能：有没有不必要的拷贝？内存管理对吗？
• 可维护性：变量命名合理吗？注释到位吗？

4.5 知识体系总览

下面这张图，是我对本章内容的总结。你可以把它当作一个检查清单。

4.6 避坑指南：我踩过的那些坑

• 大文件提交：我曾经不小心把编译产物提交到了Git仓库，导致仓库体积暴涨。后来加了.gitignore，才解决。
• 合并冲突处理不当：有人遇到冲突就强制覆盖，结果把别人的代码搞丢了。记住：先理解冲突，再解决冲突。
• rebase滥用：rebase确实能让历史更干净，但如果你rebase了已经push的分支，别人pull时会很痛苦。我的原则是：公共分支不要rebase。
• 忽略二进制文件：C++项目经常有.so、.dll、.exe等二进制文件。一定要在.gitignore里排除掉，否则每次编译都会产生大量变更。

好了，关于Git在C++项目中的最佳实践，就聊到这里。记住：规范不是束缚，是效率的保障。花点时间把Git用好，后面会省下大把时间。