Git的基本原理
本质上，Git是一套内容寻址（content-addressable）文件系统，而和我们直接接触的Git界面，只不过是封装在其之上的一个应用层。这个关系颇有点类似于计算机网络中应用层和下属层的关系。在Git中，那些和应用层相关的命令（也就是我们最常用的命令，如git commit、 git push等），我们称之为porcelain命令（瓷器之意，意为成品、高级命令）；而和底层相关的命令（几乎不会在日常中使用，如git hash-object、git update-index等），则称之为plumbing命令（管道之意，是连接git应用界面和git底层实现的一个管道，类似于shell，底层命令）。要了解Git的底层原理，就需要了解Git是如何利用底层命令来实现高层命令的。在此之前，让我们先来看一下Git的目录结构，和各个文件在Git中的作用。
Git的目录结构
在操作系统中，我们的仓库就是一个文件夹。但是为什么这些文件夹就是Git仓库呢？这是因为Git在初始化的时候会生成一个.git的文件夹，而Git进行版本控制所需要的文件，则都放在这个文件夹中。在桌面上新建一个目录，然后利用命令行在该目录下运行git init命令即可完成git仓库的初始化。如果这个时候你看不到.git目录，这是因为你的操作系统自动隐藏了该文件夹，需要在系统设置中设置隐藏文件可见。进入.git目录，便可以看到其中有很多的文件和文件夹，这每一个文件都有各自的作用，下面结合图1来进行说明。
图1 .git目录结构示意图
在上图中，第一排的几个文件和文件夹是Git的核心，而第二排的则是一些不需要特别关注的。核心文件包括：config文件、objects文件夹、HEAD文件、index文件以及refs文件夹。下面依次对其进行说明。
config文件：该文件主要记录针对该项目的一些配置信息，例如是否以bare方式初始化、remote的信息等，通过git remote add命令增加的远程分支的信息就保存在这里；
objects文件夹：该文件夹主要包含git对象。关于什么是git对象，将会在下一节进行详细介绍。Git中的文件和一些操作都会以git对象来保存，git对象分为BLOB、tree和commit三种类型，例如git commit便是git中的commit对象，而各个版本之间是通过版本树来组织的，比如当前的HEAD会指向某个commit对象，而该commit对象又会指向几个BLOB对象或者tree对象。objects文件夹中会包含很多的子文件夹，其中Git对象保存在以其sha-1值的前两位为子文件夹、后38位位文件名的文件中；除此以外，Git为了节省存储对象所占用的磁盘空间，会定期对Git对象进行压缩和打包，其中pack文件夹用于存储打包压缩的对象，而info文件夹用于从打包的文件中查找git对象；
HEAD文件：该文件指明了git branch（即当前分支）的结果，比如当前分支是master，则该文件就会指向master，但是并不是存储一个master字符串，而是分支在refs中的表示，例如ref: refs/heads/master。
index文件：该文件保存了暂存区域的信息。该文件某种程度就是缓冲区（staging area），内容包括它指向的文件的时间戳、文件名、sha1值等；
Refs文件夹：该文件夹存储指向数据（分支）的提交对象的指针。其中heads文件夹存储本地每一个分支最近一次commit的sha-1值（也就是commit对象的sha-1值），每个分支一个文件；remotes文件夹则记录你最后一次和每一个远程仓库的通信，Git会把你最后一次推送到这个remote的每个分支的值都记录在这个文件夹中；tag文件夹则是分支的别名，这里不需要对其有过多的了解；
Git对象的类型包括：BLOB、tree对象、commit对象。BLOB对象可以存储几乎所有的文件类型，全称为binary large object，顾名思义，就是大的二进制表示的对象，这种对象类型和数据库中的BLOB类型（经常用来在数据库中存储图片、视频等）是一样的，当作一种数据类型即可；tree对象是用来组织BLOB对象的一种数据类型，你完全可以把它想象成二叉树中的树节点，只不过Git中的树不是二叉树，而是"多叉树"；commit对象表示每一次的提交操作，由tree对象衍生，每一个commit对象表示一次提交，在创建的过程中可以指定该commit对象的父节点，这样所有的commit操作便可以连接在一起，而这些commit对象便组成了提交树，branch只不过是这个树中的某一个子树罢了。
Git的核心是它的对象数据库，其中保存着git的对象，其中最重要的是blob、tree和commit对象，
blob对象实现了对文件内容的记录，
tree对象实现了对文件名、文件目录结构的记录，
commit对象实现了对版本提交时间、版本作者、版本序列、版本说明等附加信息的记录。
这三类对象，完美实现了git的基础功能：对版本状态的记录。
Git引用是指向git对象hash键值的类似指针的文件。通过Git引用，我们可以更加方便的定位到某一版本的提交。Git分支、tags等功能都是基于Git引用实现的。
分支的目的是让我们可以并行的进行开发。比如我们当前正在开发功能，但是需要修复一个紧急bug，我们不可能在这个项目正在修改的状态下修复 bug，因为这样会引入更多的bug。有了分支的概念，我们就可以新建一个分支，修复 bug，使新功能与 bug 修复同步进行。
Git的工作流程
git跟传统的代码管理器（如:svn）不同， 主要区别在于git多了个本地仓库以及缓存区，所以即使无法联网也一样能提交代码。术语解释：
工作区间: 即我们创建的工程文件， 在编辑器可直观显示；
缓存区: 只能通过git GUI或git shell 窗口显示，提交代码、解决冲突的中转站；
本地仓库: 只能在git shell 窗口显示，连接本地代码跟远程代码的枢纽，不能联网时本地代码可先提交至该处；
远程仓库: 即保存我们代码的服务器，本文以公共版本控制系统：github为例，登录github账号后可直观显示；
接下来， 我们以三个实际操作的例子讲解git的日常，代码如何在上述4个区域流动。
Git常用命令
https://www.cnblogs.com/my--sunshine/p/7093412.html
rebase的黄金法则
当你理解rebase是什么的时候，最重要的就是什么时候 不能 用rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。
比如说，如果你在develop分支上，rebase到你的feature分支上会发生什么：
这次rebase将develop分支上的所有提交都移到了feature分支后面。问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的develop上工作。因为rebase引起了新的提交，Git会认为你的develop分支和其他人的develop已经分叉了。
同步两个develop分支的唯一办法是把它们merge到一起，导致一个额外的合并提交和两堆包含同样更改的提交。不用说，这会让人非常困惑。
所以重要的再强调一遍，绝不要在公共的分支上使用它。在你运行git rebase 之前，一定要问问你自己“有没有别人正在这个分支上工作？”。如果答案是肯定的，重新找到一个无害的方式（如git revert）来提交你的更改。不然的话，你可以随心所欲地重写历史。