版本控制简介

版本控制是记录文件变化、保留历史版本的机制。它让我们能够比较两个版本改了什么、查找变更原因，也能取回以前保存的内容。Git 是一种分布式版本控制系统：本地就能保存提交历史，与他人协作时再交换这些提交。

学习 Git，首先要分清两个问题：一次修改怎样进入历史，以及本地历史怎样与远程仓库共享。前者关系到能否找回代码，后者关系到能否把不同人的工作合到一起。

1. 为什么需要版本控制

版本控制解决的是文件反复修改后，怎样保留、比较和整合各个版本的问题。比如修改一份项目报告时，我们可能把文件依次保存为「初稿」「修改版」「最终版」。单看文件名，很难知道每一版具体改了什么；两个人分别修改后，还要手动比较内容，才能决定保留哪些部分。

代码也有同样的问题。修复一个缺陷后，需要留下修改前后的记录；引入新问题时，需要找到从哪一次变更开始出错；多人修改同一个项目时，需要把各自的工作整合起来。即使只有一个人开发，保留这些记录也有用。

版本控制系统能帮助记录和比较修改，但不能保证修改之间没有冲突。两个人对同一处代码作出不兼容的修改时，仍需要理解双方的意图，再决定最终结果。

版本控制保存文件的版本和相关说明，让后来的人能知道改了什么、为什么改。一次变更主要包含以下信息：

这些记录连起来，就形成了项目的变更历史。系统能展示文件差异，但修改的原因仍需要作者说明。例如，「修改代码」几乎没有解释作用，「修复空订单计算总价时报错」则能让读者知道这次变更要解决什么问题。

在 Git 中，只有主动提交的版本才会进入提交历史，编辑器里每保存一次文件，并不会自动产生一次提交。除了代码，项目文档和配置文件也可以纳入版本控制。

仓库是版本控制系统保存文件版本和历史记录的地方。协作时，集中式与分布式系统的主要区别，在于这些历史记录保存在中央服务器，还是也保存在开发者的本地仓库中。

集中式版本控制系统由中央服务器管理共享的版本历史，开发者取出文件到本地编辑，再把修改提交给服务器。CVS 就属于这一类。

这种方式便于集中管理仓库和访问权限，但提交依赖服务器可用。如果服务器暂时无法访问，开发者仍可以编辑本地文件，却无法向中央仓库提交修改。中央仓库还需要可靠的备份，否则它保存的历史一旦丢失，仅靠各人的工作文件未必能够恢复。

权限控制决定谁能访问或修改仓库，代码质量则还需要评审和测试。两者不能混为一谈。

分布式版本控制系统让开发者在本地也拥有仓库，可以独立保存和查看提交历史。以 Git 为例，完整克隆得到的本地仓库包含项目的提交历史，所以断网时仍能提交修改、查看已有历史和创建分支。

团队可以约定一个远程仓库来交换提交。你先在本地保存自己的修改，再把提交推送到远程，也可以获取其他人的提交并整合到本地。远程暂时不可用时，本地工作可以继续，向这个远程同步则需要等待恢复。

分布式带来的额外工作，是区分自己的提交和远程已有的提交，并在同步时处理不同人的修改。冲突取决于修改能否兼容，集中式与分布式协作都可能遇到。

本地仓库还能提供一份历史副本，但只能恢复它实际拥有的数据。尚未同步到本地的提交，不能指望从这个本地仓库找回；已经分发到各台电脑的代码和历史，也需要分别保护。

Git 起源于 Linux 内核的协作开发需求。Linux 内核项目曾使用 BitKeeper 管理代码；2005 年，BitKeeper 撤回对社区的免费使用许可后，Linus Torvalds 等开发者开始开发自己的版本控制工具，Git 由此诞生。

Git 的设计目标包括快速处理大型项目、支持并行分支开发，以及让各个仓库能够独立工作。这些目标也解释了它为什么把本地提交和远程协作分开。

GitHub 则是基于 Git 的代码托管平台。Git 负责版本控制，托管平台提供存放和协作的场所；完成本地提交，并不要求先创建 GitHub 仓库。

来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明