git 基本原理

哈希

哈希是一个系列的加密算法，各个不同的哈希算法虽然加密强度不同，但是有以下几个共同点：

（1）不管输入数据的数据量多大，输入同一个哈希算法，得到的加密结果长度固定；
（2）哈希算法确定，输入数据确定，输出数据能保证不变；
（3）哈希算法确定，输入数据有变化，输出数据一点有变化，而且通常变化很大；
（4）哈希算法不可逆；
MD5、SHA-1、CRC32都属于哈希算法，Git底层采用的是SHA-1算法。
哈希算法可以被用来验证文件。原理如下图：

image.png

Git靠这种机制来从根本上保证数据的完整性。

保存版本的机制

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

   
   
   image.png

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

   
   
   image.png

3. Git 的文件管理机制细节

   
   
   image.png

Git分支管理机制

1. 分支的创建

   
   
   image.png

2. 分支的切换

   
   
   image.png
   
   

   切换testiing分支

   
   
   image.png
   
   切换回master分支
   
   image.png
   
   

   master再次提交后

   
   
   image.png

Git 工作流

1. 集中式工作流：像SVN一样，集中式工作流以中央库作为项目所有修改的单点实体。所有修改都提交到Master这个分支上。这种方式与SVN的主要区别就是开发人员有本地库。Git很多特性并没有用到。

   
   
   image.png

2. GitFlow工作流：通过为功能开放、发布准备和维护设立了独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

   
   
   image.png
3. Forking工作流：是在GitFlow基础上，充分利用了Git和Fork和pull request的功能已达到代码审核的目的。更适合安全可靠得管理大团队的开发者，而且能接收不信任贡献值的提交。（虚拟团队用得较多）

GitFlow工作流详解

1. 主干分支 master：主要负责管理正在运行的生产环境代码。永远保持与正在运行的生产环境完全一致；
2. 开发分支 develop：主要负责管理正在开发过程中的代码。一般情况应该是最新的代码；
3. bug 修理分支 hotfix ：主要负责管理生产环境下出现的紧急修复的代码。从主干分支分出，修复完毕并测试上线后，合并回主干分支。合并后，视情况可以删除该分支。
4. 准生产分支（预发版分支）release：较大的版本上线前，会从开发分支中分出准生产分支，进行最后阶段的集成测试。该版本上线后，会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除；
5. 功能分支 feature：为了不影响较短周期的开发工作，一般把中长期开发模块，从开发分支中独立出来。开发完成后合并到开发分支。

GitFlow工作流举例

image.png

image.png

分支操作

1. 创建分支dev：git branch dev
2. 切换到dev分支：git checkout dev
3. 编辑代码并提交到本地：
   git add [文件名]
   git commit -m "日志信息"
4. 推送到远程：git push origin dev
5. 检出远程dev分支：git checkout origin dev
6. 合并master：
   切换回master：git checkout master
   合并：git merge dev
   （解决冲突）
7. 合并成功后推送到远程master：git push origin master