Git&&GitHub的使用（第二节）

分支管理

什么是分支？
在版本控制过程中，使用多条线同时推进多个任务。

如上图所示，一个项目刚创建并commit到本地库里时，自动为master（主干），这时我要增加一个蓝皮肤功能和一个游戏功能，那么我就可以分别创建这两个分支，如果我在开发过程中遇到无法解决的问题，我可以再回退到master上，就相当于有后悔药吃，然后master如果出现了bug，那么我可以在出现bug的版本建立一个分支修复bug，最终这些确认无误的分支都要与主干进行合并。

分支的好处？
 同时并行推进多个功能开发，提高开发效率
 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

分支操作

如上图，我们开始是在master上，现在创建新分支git branch 分支名，然后用git branch -v查看有哪些分支，这时master是绿的，因为我们在master上，现在我们使用git checkout 分支名 进行分支切换，然后我们就来到了hot_fix上。

如上图，我在hot_fix这个分支里对test.txt做了修改，然后查看状态，是红的。如下图，我将修改后的test.txt提交，然后切换到master，我们会发现master里的test.txt是master自己的，不是hot_fix提交的！！

分支合并
我们通过上面的操作，可以知道目前master和hot_fix是分离的，我这里用hot_fix表示修补bug的这个分支，这时bug修复好了，我要与主干master合并才行，如下图~

如上图，首先我们要切换到被合并的主干，然后再执行merge操作，合并有新内容的hot_fix，然后查看master里的test.txt，这时就与hot_fix一样了。

解决冲突

冲突是版本控制工具要解决的重要问题，我就单独说一下。
什么时候会冲突？
比如我master的test.txt为版本1，然后我hot_fix基于将test.txt做了修改，变为版本2，这时我提交了，同时master的test.txt我也做修改，变为版本3，这时相当于双方都同时做了修改，这时我合并分支就会出现冲突，原因是我的hot_fix是基于版本1来改的，我要合并也是与版本1合并，而不是版本3.。
下图是合并分支产生冲突的样子。

下图是在这个merging状态下vim test.txt，这时我们会发现这个文件中有两个分支不一样的内容，head指示当前分支，我们需要手动去解决我们要保留哪些内容，记得删掉head那一行和hot_fix那一行。

就改成下图这样吧，然后保存。

这时如下图查看状态，我们还是在这个特殊的分支里。

然后把他add到暂存区里，然后查看状态。

然后如下图提交，我又回到了master。

Git原理

哈希算法

哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下 几个共同点：
①不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定。
②哈希算法确定，输入数据确定，输出数据能够保证不变
③哈希算法确定，输入数据有变化，输出数据一定有变化，而且通常变化很大
④哈希算法不可逆
Git 底层采用的是 SHA-1 算法。
哈希算法可以被用来验证文件。原理如下图所示：

Git 保存版本的机制

集中式版本控制工具的文件管理机制 （如SVN）
以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

svn是增量式的，他只更新我们提交的部分。
Git 的文件管理机制
Git 把数据看作是小型文件系统的一组快照。每次提交更新时 Git 都会对当前 的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改， Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。所以 Git 的 工作方式可以称之为快照流。

Git 文件管理机制细节
 Git 的“提交对象”

灰框是我们提交的对象，里面包含若干个文件，这时我们要有一个根，提交对象里面就含有这棵树的根对应的哈希值，然后这个树根里包含着这些文件的哈希值。
提交对象及其父对象形成的链条

git的原理就是通过哈希值串成一个链条来实现历史记录。

Git 分支管理机制

分支的创建
这里有master和testing两个分支指针。

分支的切换
一开始head指针指向master分支，现在直接改一下指针就能指向testing分支。