1、push 的时候之后上传当前分支，并不会上传 HEAD；远程仓库的 HEAD 是永远指向默认分支（即 master）的。
之前以为是和本地保持一致的呢，这个想法有误区。
不过远程分支上的HEAD好像也并没太大的作用。
2、git pull相当于git fetch和git merge。首先git fetch将远程库拉下来，然后merge。即拉取了最新commit后，然后在执行git merge origin/HEAD。
3、 merge 的三种特殊情况：
1. 冲突
1. 原因：当前分支和目标分支修改了同一部分内容，Git 无法确定应该怎样合并；
2. 应对方法：解决冲突后手动 `commit`。
2. `HEAD` 领先于目标 `commit`：Git 什么也不做，空操作；
3. `HEAD` 落后于目标 `commit`：fast-forward。
4、Pull Request 并不是 Git 的内容，而是一些代码托管平台提供的分支快捷合并功能。 pull request时能方便看出差异化的内容。 在gitlab上是叫merge request，github上是pull request，这两者有啥区别呢？ 本质上这两者没啥区别，只是从不同的角度提出的叫法，在网上看到一篇讲的很好的博客，讲的很清楚，具体见如下的链接。 Pull Request 与 Merge Request 本质上是同一个东西，名称有点误导
5、git reset --hard HEAD或commitid 将本地重置到指定的提交，本地未提交的文件都会被重置，保持与远程分支完全一致。
git reset --soft 将差异的部分放到暂存区。
git reset 不加参数即为默认的--mixed，即将差异化的内容放在工作区，和本地未提交的内容一起，这也是mixed的含义。 在git官方book上有较详细的图文教程，可以参考一下。
6、没有被untrack的文件，stash时是会被忽略的。注意这一点。 使用 git stash -u 可以将untrack的文件也包含进来。
7、checkout 和 reset 都可以切换 HEAD 的位置，它们除了有许多细节的差异外，最大的区别在于：reset 在移动 HEAD 时会带着它所指向的 branch 一起移动，而 checkout 不会。当你用 checkout 指向其他地方的时候，HEAD 和 它所指向的 branch 就自动脱离了。
8、git pull是git pull --merge的简写，所以在pull过程中可能会产生新的合并节点。 git pull --rebase是拉取之后使用rebase方式将分支变基础，然后在将分支上的改动合并到分支上来。
在不同分支上merge时的演示如下
在不同分支上rebase时的演示如下
那么在git pull --rebase是相对于谁变基呢？其实是相对于该分支对应的远程分支进行变基的。 通过如下图进行演示该过程
初始状态，branchA分支在本地有一个提交A，但是该分支的远程库上其他人也有一个提交B
在git pull时会先git fetch即拉取远程库的提交，此时状态如下
然后再以远程库分支为基准进行变基操作，此时状态如下
可以看到本地分支以远程分支为的B为基准提交，将之前的提交A，重新提交到B之后，此时就提交记录就会是线性的。
最后将本地提交push到远程时，远程和本地的提交状态如下：
