Git背后的设计理念

首先要清楚Git版本管理中提交的概念。通过按行对比（line diff）将有差异的部分作为增量补丁，使用git add添加到暂存区里的每一个文件都会由按行对比得到他们的增量补丁，而使用git commit将暂存区里的所有文件的增量补丁合并起来存入仓库，这就是一次提交。

通常在提交时，会生成一个SHA-1 Hash值作为commitID。每个commitID中有40个十六进制数字。

就是该次提交在Git仓库中存储的内容和头信息的校验和。Git使用SHA-1并非为了保证安全性，而是为了保证数据的完整性，即可以保证很多年后重新检验某次提交时，一定是它多年前的状态，完全一模一样、完全值得信任。

按时间线依次排列的一组提交记录形成一个分支，比如默认分支master，也可以根据某种需要创建分支。

tag是某个提交的标签，比如发布1.0版本时的那次提交被专门打了个标签v1.0。标签就是别名，便于记忆和使用。

我们简要总结一下以上几个关键概念：

•  按行对比是制作增量补丁的方法，即通过按行对比将有差异的部分制作成增量补丁。
• 提交是存储到仓库里的一个版本，是整个项目的一个或多个文件的增量补丁合并起来形成的项目的增量补丁，是一次提交记录。每次提交都生成一个唯一的commitID。
• 分支是按时间线依次排列的一组提交记录，理论上可以通过当前分支上最初的提交依次打补丁直到HEAD得到当前工作区里的源代码。
• 标签是某次提交的commitID的别名。

合并操作常指将远程分支合并到本地master分支，或者某个本地分支合并到master分支。以下图为例，项目在A版本处开始分叉，形成了两个分支，分别提交了B、D、F和C、E、G，这时希望将这两个分支合并，只要将F与A有差异的部分放入工作区，此时C、E、G已经在工作区了，如果有冲突，解决冲突后就可以提交一个版本H，即完成了两个分支的合并。

简要总结一下，合并操作可以用一个公式来表示：H = A + (F - A) + (G - A)，即F版本与A版本的差异，以及G版本与A版本的差异，与A合并起来，如果有冲突，解决冲突，形成一个新的版本H。

具体技术实现上，因为每一个版本都有上一个版本的“增量补丁”，只要将合并的分支里的B、D、F的增量补丁，合并到当前工作区G版本里，解决冲突后即可提交为H版本。