3、版本控制基础：Git核心概念回顾、分支策略选择与.gitignore配置技巧
版本控制，说白了就是给文件系统装上一台「时光机」。你想想看，多项目并行时，最怕什么？怕改错文件、怕覆盖代码、怕找不到历史版本。Git 就是来解决这些问题的。我个人习惯把 Git 当作项目的「安全网」——有了它，你才敢大胆重构、频繁实验。
3.1 Git 核心概念回顾
先快速过一遍 Git 的核心概念。这些是基础，但很多人用错了。
| 概念 | 一句话解释 | 我踩过的坑 |
|---|---|---|
| 工作区 | 你电脑上能看到的文件目录 | 有人直接在服务器上改工作区文件，结果冲突一堆 |
| 暂存区 | 准备提交的「候车室」 | 我曾经忘了 git add，以为改了就会自动保存 |
| 本地仓库 | 你电脑上的 .git 目录 | 硬盘坏了才后悔没推远程 |
| 远程仓库 | 服务器上的共享仓库 | 多人同时 push 到 master，那场面… |
| 提交（commit） | 一次快照，有唯一哈希值 | 提交信息写「fix bug」等于没写 |
| 分支（branch） | 独立的开发线 | 在 master 上直接改，被同事骂了 |
核心原则：每次提交只做一件事。提交信息要能说清楚「为什么改」而不是「改了啥」。我见过太多「update file」这种提交，回滚时根本不知道哪个版本是稳定的。
3.2 分支策略选择
分支策略，说白了就是团队怎么协作开发。选错了，合并冲突能让你怀疑人生。我经历过两种主流策略，各有优劣。
3.2.1 Git Flow
Git Flow 是经典的分支模型，适合有固定发布周期的项目。它定义了五种分支：
- master：只放生产就绪的代码
- develop：日常开发的主线
- feature：每个新功能一个分支，从 develop 拉出
- release：发布前的准备分支，只修 bug
- hotfix：紧急修复，从 master 拉出，修完合并回 master 和 develop
我的经验：Git Flow 适合 10 人以上的团队，或者有严格发布流程的项目。但小团队用起来会觉得「太重了」——光分支切换就够你忙的。
3.2.2 Trunk Based（主干开发）
Trunk Based 正好相反——所有人在一条主干上开发，分支存活时间不超过几天。我最近两年都在用这个模式。
- 主干（trunk/main）：唯一的长期分支
- 短期特性分支：从主干拉出，开发完立刻合并回去
- 没有 release 分支：用标签（tag）标记发布版本
注意：Trunk Based 要求团队有完善的 CI/CD 和代码审查机制。我曾经在一个没有自动化测试的项目上强推 Trunk Based，结果主干天天挂，被同事吐槽了整整一个月。
3.2.3 如何选择？
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 多项目并行，每个项目独立发布 | Trunk Based | 减少分支管理成本，快速迭代 |
| 单一项目，多个版本同时维护 | Git Flow | 需要同时支持 v1.0、v2.0 等版本 |
| 团队小于 5 人 | Trunk Based | 沟通成本低，没必要搞复杂分支 |
| 团队大于 20 人 | Git Flow 或定制版 | 需要明确的责任划分和发布流程 |
我个人建议：如果你在做多项目并行，优先考虑 Trunk Based。原因很简单——分支越少，冲突越少，你花在「解决合并冲突」上的时间就越少。
3.3 .gitignore 配置技巧
.gitignore 这个文件，看着简单，但用不好能让你抓狂。我见过有人把整个 node_modules 提交到仓库，也有人不小心把数据库配置文件传到了 GitHub 上。
3.3.1 基本原则
- 忽略编译产物：如 .class、.o、.exe、dist/、build/
- 忽略依赖目录：如 node_modules/、vendor/、.venv/
- 忽略 IDE 配置：如 .idea/、.vscode/、*.swp
- 忽略敏感信息：如 .env、config/local.*、*.key
- 忽略操作系统文件：如 .DS_Store、Thumbs.db
避坑指南：我曾经在一个项目中把 .env 文件加入了 .gitignore，但同事不知道，直接 git add . 把生产环境的数据库密码推到了远程仓库。还好发现得早，不然就出大事了。所以我的建议是：在项目初始化时就配置好 .gitignore，并且让所有人都知道哪些文件不能提交。
3.3.2 多项目场景下的 .gitignore 配置
多项目并行时，每个项目可能有不同的构建工具和依赖管理方式。我习惯在项目根目录放一个通用的 .gitignore，然后针对子项目做补充。
# 通用忽略
node_modules/
dist/
build/
.env
*.log
.DS_Store
# 项目 A（前端）
/frontend/.cache/
/frontend/coverage/
# 项目 B（后端）
/backend/__pycache__/
/backend/*.pyc
/backend/.pytest_cache/
# 项目 C（文档）
/docs/_build/
/docs/.doctrees/
小技巧：使用 git check-ignore -v filename 可以查看某个文件被哪条规则忽略了。这在调试 .gitignore 时特别有用。
3.3.3 常见错误与解决方案
| 错误场景 | 后果 | 解决方案 |
|---|---|---|
| 忘记配置 .gitignore | node_modules 被提交，仓库体积暴增 | 初始化项目时立即配置 |
| 使用通配符过于宽泛 | 误忽略了需要的文件 | 用 ! 取反，如 !*.example |
| 已经提交了不该提交的文件 | 即使加入 .gitignore 也不会自动删除 | 用 git rm --cached 从跟踪中移除 |
| 不同项目共用同一个 .gitignore | 某些规则不适用 | 使用全局 .gitignore 或子目录覆盖 |
重要提醒：如果你已经提交了某个文件，再把它加入 .gitignore 是没用的。你需要先执行 git rm --cached filename 把它从 Git 的跟踪中移除，然后再提交。否则，这个文件会一直存在于仓库历史中。
3.4 本章小结
版本控制的核心不是工具，而是习惯。Git 只是帮你把「后悔药」准备好了，但吃不吃取决于你自己。我个人建议：
- 多项目并行时，优先选 Trunk Based 分支策略
- 每次提交只做一件事，提交信息写清楚「为什么」
- 项目初始化时就配好 .gitignore，别等出事了再补救
- 定期清理本地分支，保持仓库整洁
嗯，这些基础打好了，后面讲「多项目文件结构设计」时你才能跟得上。记住：版本控制不是束缚，而是让你更自由地去改代码。