为什么代码需要版本控制：从手工备份到分布式 Git

核心问题手工备份和集中式版本控制有什么限制Git 的分布式设计解决了什么问题本文只讨论版本控制的必要性和集中式、分布式两种协作方式。本文暂不讨论Git 的数据结构和具体操作。多保存几个副本为什么不够没有版本控制工具时我们很容易得到这样的目录project project-修改版 project-最终版 project-最终版2复制文件确实留下了旧内容却很难继续回答两个版本具体差在哪里这次修改是谁完成的为什么修改多个人同时改动时怎样合并各自的成果问题是什么时候出现的怎样回到一个确定可靠的状态版本控制系统记录的不只是文件副本还包括项目随时间变化的过程。它让我们能够比较版本、追踪修改、恢复内容并组织多人协作。集中式版本控制集中式版本控制系统通常由一台中央服务器保存主要版本历史成员从服务器取得文件再把修改提交回服务器。它的优点是管理方式直观权限和历史集中在一个位置。但中央服务器也是协作中的关键节点服务器无法访问时很多依赖服务器的操作会受到影响如果中央数据没有可靠备份故障影响也会更集中。可以把它想成公司统一管理的档案室。所有人都围绕同一个档案室借阅和归还资料。分布式版本控制分布式版本控制系统不只把当前文件交给开发者本地仓库通常还拥有完整的项目历史。浅克隆、部分克隆等特殊方式可能只取得部分数据但不影响这里建立的基本认识。因此即使暂时没有网络开发者仍然可以在本地记录版本、查看历史和建立分支。需要协作时再与其他仓库交换变化。这相当于每位成员都有一套可以独立工作的档案副本之后再与其他档案库同步变化。Git 和 GitHub 分别是什么Git 是分布式版本控制工具。GitHub、GitLab 等平台可以托管 Git 仓库并提供评审、权限和团队协作能力但它们不是 Git 本身。没有代码托管平台Git 仍然能够在本地管理项目历史接入托管平台以后团队才更方便地共享这些历史。分布式仓库保存的不只是当前文件分布式版本控制并不是让每位开发者多保存一份当前项目目录而是让本地仓库也具备记录和查询版本历史的能力。为了做到这一点Git 需要区分三类内容当前正在编辑、还可能继续变化的内容已经选择好、准备记录为下一个版本的内容已经形成提交、可以追溯和比较的历史。下一篇“Git 如何将一次修改记录为可追溯的版本”将继续说明这三类内容如何通过工作区、暂存区和版本库连接起来。我的理解版本控制真正管理的是项目变化的过程。集中式系统围绕中央历史协作分布式系统让本地也拥有历史和独立工作能力。Git 采用分布式设计所以很多查看、记录和分支操作可以先在本地完成。参考资料Git 官方资料About Version ControlGit 官方资料What is Git?