1. 前言
提交与分支是Git中两个基本对象，对初学者而言需要花些时间理解。正如我们之前所说，计算机中很多新概念是新瓶装旧酒。计算机技术来源于需求，服务于需求，需求是计算机技术的出发点和落脚点。梳理清楚工程实践中，版本管理工作的每个需求点和细节，就能摸清Git的来龙去脉。
2. 手动版本管理过程
2.1 初级版本管理
某高校软件开发团队，简称A团队，承接了一个商品管理系统项目，名为ProductManager。
通过紧锣密鼓的开发，一个月后，基本功能开发完成，发送客户确认后，客户比较满意。并提出了改进意见。
此时A团队的代码目录如下所示：
此时，项目负责人小张并没有直接开展项目改进工作，为了巩固团队开发成果，防止后续修改出现问题无法回退到当前的源码状态，小张将此时的代码复制了一份，将其命名为 ProjectManager V1.0，至此，第一个版本诞生了：
此后，开发团队可以在 ProductManager 源码目录中继续开发，而不会影响目录 ProductManager V1.0。想要在任意时刻恢复某个文件，只需要将其从ProductManager V1.0 中拷贝出来进行文件替换即可完成恢复操作。通过创建版本，实现了将文件回退到过去某个状态的效果。
经过一段时间改进后，软件被发送给客户使用，客户觉得软件界面样式还是改进前的好看，于是提出恢复以前的界面样式。由于开发团队创建了 V1.0 版本的备份，所以可以轻松的将以前皮肤的代码提取出来，替换当前皮肤。手中有版本，心中绝不慌。
为了防止客户再次反悔以及应对各种各样的代码恢复问题，小张决定，团队每次修改一个功能，都需要进行备份。于是产生了很多备份版本：
以上备份文件夹我们称之为“提交”。
由于版本很多，备份的数据占用了很大的磁盘空间，这是手动版本管理方式的缺点之一。实际上，版本与版本之间，并不是所有文件都有变化，所以按照文件夹进行完全拷贝式备份，有很多文件是完全相同的，也就是存在冗余备份。如果只对版本与版本之间，差异的文件进行备份，简称“差异备份”，这样肯定会节省很大的空间，但是会增加人工管理成本，没有直接全部拷贝简单直接。
另外，版本与版本之间究竟修改了哪些内容，修改的目的是什么，都没有进行记录，不够规范，没有统一版本管理标准。如果缺少版本描述，会增版本的使用难度。
2.2 进阶版本管理
在 V3.0 版本开始，客户要求，软件需要提供两个版本，分别提供给两个 超市A 和 超市B 使用。分别基于V3.0版本，针对两个超市的实际需求，继续完善软件。针对这样的需求，小张决定新建两个文件夹来保存两个超市的软件代码和各自的备份版本，分别叫 SuperMarketA，SuperMarketB，如下所示：
在随后的开发过程中，SuperMarketA 和 SuperMarketB 独立进行版本备份，互不影响，一段时间后，版本结构如下：
SuperMarketA 和 SuperMarketB 不是一个具体的备份，而是一系列连续备份的集合，我们称之为 “分支”。分支示意图如下：
其中，初级阶段的所有提交所在的分支，默认称之为 “master分支”。
以上只是最简单的版本管理过程，实际工程中的版本管理场景及需求更加复杂。正因为如此，手动版本管理无法胜任复杂的软件开发工作，工程实践中，已被 版本管理软件 所替代。
3. Git版本管理
Git是一款免费开源的版本管理软件，用以替代手动版本管理，克服手动版本管理的不足。它完善了版本管理理论，统一了版本管理规范，能够满足各种版本管理需求。以上提到的 “提交”，“分支”，正是Git中的数据对象。
通过手动版本管理过程，我们发现：
“提交”，“分支” 的本质，其实就是（手动版本管理过程中的）备份文件夹 （注意此处是名词）。
Git提供给使用者的绝大部分功能，就是在操作 “提交”、“分支” 这两个数据对象。如果不能很好的理解这两个关键对象，学习Git命令就会比较困难。操作 “提交”、“分支”，可以类比为操作备份文件夹，二者形式上有所不同，但是本质上相同。
4. 结语
没有魔法，提交与分支的本质就是备份文件夹。
后续文章中，我们将以使用文件夹操作来模拟Git操作的思路，形象分析Git中的基本操作的具体含义。
本文原创发布于Qt未来工程师。
