2.4 源代码管理
← 2.3 整洁代码 | 首页 | 下一节: 2.5 技术协作 →
版本控制基础
- 核心概念：仓库（repository）、提交（commit）、分支（branch）、标签（tag）、合并（merge）、变基（rebase）。
- 集中式（SVN）vs 分布式（Git）：分布式系统每个本地仓库都是完整副本，离线可提交。
- SCM 工具（Git）vs 托管平台（GitHub/GitLab/Bitbucket）：Git 是工具，托管平台是附加了协作功能的远程仓库服务。
- 理解为什么版本化至关重要：可以回滚、追溯变更原因、并行开发、审计。
微提交（Micro Commits）
核心理念：每个提交只做一件事，让提交历史"讲述一个完整故事"。
四大好处： 1. 叙事性：把增量过程展示给评审者，而不是扔出一个巨大补丁。 2. 纪律性：迫使你将复杂方案拆分为定义清晰的步骤序列。 3. 更好的 Code Review：小补丁容易审查，每次只看一件事。 4. Bisect 和 Cherry-pick 有效：精确找到哪个提交引入回归，方便跨分支拣选。
Git 的 rebase -i 让你能在提交前整理提交历史——"假装自己是一个完美的开发者"。
约定式提交（Conventional Commits）
提交信息格式：type[可选 scope]: description
fix:→ PATCH 版本（Bug 修复）feat:→ MINOR 版本（新功能）!后缀或BREAKING CHANGE:脚注 → MAJOR 版本（破坏性变更）- 其他类型：
docs:、style:、refactor:、perf:、test:、build:、ci:、chore: - scope 示例：
feat(parser): add ability to parse arrays
可以据此自动生成 CHANGELOG、自动确定 SemVer 版本号跳跃、触发构建和发布流程。
分支策略
- 短命特性分支（Short-lived Feature Branches）：1-3 天内合并回主干，减少合并冲突。
- 主干开发（Trunk-Based Development）：所有开发直接或通过极短分支在主分支上进行，配合特性开关控制未完成功能的可见性。
- 避免长期存在的分支（如数周未合并的 feature 分支），这是合并地狱的根源。
依赖地狱（Dependency Hell）
当多个软件包依赖同一个共享库的不同且不兼容的版本时，就会陷入依赖地狱。
| 问题类型 | 描述 |
|---|---|
| 依赖过多 | 应用依赖大量库，占用大量磁盘，难以移植 |
| 长依赖链 | A→B→C→…→Z 的手工安装链条 |
| 冲突依赖 | app1 需要 libfoo 1.2，app2 需要 libfoo 2.0，两者不可同时安装 |
| 循环依赖 | A 需要 B，B 又需要 A |
| 钻石依赖 | A 依赖 B 和 C，B 需要 D v1，C 需要 D v2 |
解决方案：语义化版本、智能包管理器（APT/Yum/Pacman 自动解析版本）、私有依赖/容器化（Docker 打包完整运行环境）、Nix 等可重现构建工具。
来源
- Lucas Rocha — Micro Commits: https://lucasr.org/2011/01/29/micro-commits/
- Conventional Commits 1.0.0: https://www.conventionalcommits.org/en/v1.0.0/
- Wikipedia — Dependency hell: https://en.wikipedia.org/wiki/Dependency_hell