版本控制解决的问题

最早的协作方式是"共享文件夹 + 文件名加后缀"（报告_v2_最终版_真的最终版.docx）。这种方式的问题显而易见：无法追溯修改历史、无法并行工作、合并修改靠手工。

版本控制系统（VCS）解决了这些：记录每次变更、支持多人并行、提供合并机制。

集中式 vs 分布式

集中式（如 SVN）：有一个中央服务器保存完整历史，开发者从服务器检出、提交。

分布式（如 Git）：每个开发者的本地仓库都是完整的副本，包含全部历史。

分布式的优势：

  • 大部分操作（提交、查看历史、创建分支）在本地完成，速度快且不依赖网络；
  • 无单点故障；
  • 支持离线工作；
  • 协作模式更灵活。

Git 的核心设计

快照而非差异：Git 记录的是每次提交时整个项目的快照（内部通过内容寻址和共享对象来避免冗余），而非文件间的差异。

SHA-1 哈希标识：每个对象（提交、树、文件）都用内容的哈希值标识。这带来两个好处：内容完整性可校验，且相同内容自动共享存储。

指针式的分支：Git 的分支本质上只是一个指向某个提交的可变指针。创建分支几乎零成本，这使得"频繁建分支"成为可行的实践。

常见协作模型

Git Flow：有 master（生产）、develop（开发）、feature（功能）、release（发布）、hotfix（紧急修复）等多类分支。结构清晰，但对快速迭代的项目可能过于复杂。

GitHub Flow：只有 main 分支和功能分支。开发在功能分支上进行，通过 Pull Request 评审后合并。简单直接，适合持续交付。

GitLab Flow：介于两者之间，引入环境分支（如 pre-production、production）。

关键实践

提交粒度：每个提交应该是一个逻辑上完整的改动（"修复登录时的空指针"而非"改了一堆东西"）。这让历史可读、便于回滚和定位问题。

有意义的提交信息：说明"为什么"而不仅仅是"改了什么"。

Pull Request / Merge Request：代码评审的核心载体。它不只是合并代码，更是知识共享和质量把关的环节。

保护主分支：要求通过 CI 检查、至少一人评审后才能合并。

一个常见困境

合并冲突不可避免。减少冲突的实用做法：

  • 分支短命，快速合并回主干；
  • 频繁从主干同步更新到功能分支；
  • 团队在文件/模块层面做合理的职责划分。

说明：本文为版本控制实践的公开知识整理。