0 写在前面

即将面临工作，逐渐意识到了涉及企业级开发的时候，如何高效、安全的管理自己的代码显得尤为重要。我相信掌握至少一种代码管理工具是每一个程序猿必须要做的功课，在我之前的一篇博客：Git版本控制入门中简单的记录了Git基本使用，为了能更加深入的理解其原理，于是准备再做一次总结。

1 分布式版本控制

Git属于分布式版本控制系统，显然还有另外一种集中式版本控制系统（即SVN）

上图直观的显示了两种版本控制系统的区别所在，集中式版本控制只有中心服务器拥有一份代码。而分布式版本控制则不同，顾名思义，分布式版本控制每个开发人员的电脑上都有一份完整的代码。
显然集中式版本控制有安全问题，因为一旦中心服务器Down掉了那么所有人都没法工作了。
集中式版本控制需要联网才能工作，网速就会影响开发人员提交文件的速度。而分布式版本控制不需要联网就能工作。
分布式版本控制新建分支、合并分支等操作速度非常快，而集中式版本控制新建一个分支相当于复制一份完整代码。

2 中心服务器

中心服务器是用来交换每个用户的修改。 Github实际就是一个中心服务器。

3 工作流

在本地新建一个仓库之后，当前目录就成为了工作区，工作区下面有一个隐藏目录**.git**，它属于Git的版本库。
Git的版本库包含两部分：

Stage的暂存区
History版本库，存储所有分支信息，并用一个HEAD指针指向当前分支

几条常用的Git指令：

git add <files>：将工作区文件的修改添加到暂存区
git commit：把暂存区的修改提交到当前工作分支，提交后暂存区会被清空
git restore --staged <file>：使用当前分支上的修改覆盖暂存区，用来撤销git add <file>
git restore <file>：使用暂存区的修改覆盖工作目录，用于撤销本地修改
git restore --source master~2 --worktree <file>：从某一特定commit中恢复文件

4 分支实现

使用指针将每个提交连接成一条时间线，HEAD指针指向当前分支指针（即下图中master）。

新建一个分支实际上就是新建了一个指针（即下图中的dev）指向时间线的最后一个节点，并让HEAD指针指向新分支的指针（dev），新分支成为当前分支。

每次提交只会让当前分支指针向前移动，不影响其他分支。

合并分支也只需要改变指针即可。

5 合并冲突

当两个分支都对同一个文件的同一行进行了修改时，在分支合并时就会产生冲突。

Git会使用<<<<<<< ，======= ，>>>>>>> 标记出不同分支的内容，只需要把不同分支中冲突部分修改成一样就能解决冲突。

<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

6 储藏（Stashing）

在一个分支上操作之后，如果还没有将修改提交到该分支上，此时进行切换分支，发现在另外一个分支上也能看到新的修改。这是因为所有分支都共用同一个工作区的缘故。
注：可以使用git stash将当前分支的修改储藏起来，次是当前工作区的所有修改都会被存到栈中，也就是说当前工作区是干净的，没有任何未提交的修改。此时就可以安全的切换到其他分支上进行开发了！

git stash
Saved working directory and index state WIP on master: 38c19b7 master

该功能可以用于bug分支实现。如果当前正在dev分支上进行开发，但是此时master分支上有一个bug急需修复，而dev分支上的开发还未完成，不想立即提交。在新建bug分支并切换到bug分支之前就可以使用git stash将dev分支的未提交修改储藏起来，bug分支就不会看到dev分支上的修改。之后回到dev分支上，想要恢复之前储藏起来的未提交修改可以使用git stash apply命令。