有如下版本库的树型结构
（一）git cherry
如下图示：左上图①表示本地当前提交的历史记录。右上图②是远程库当前提交的历史记录。图③是两都之间的差异。默认比较本地分支(HEAD)和远程分支, 即当前分支和当前分支追踪的远程分支。找到本地提交列表中,尚未推送到远程的提交。等同如下
git cherry origin/b1 b1（超前者为第二参数）
git cherry origin/b1 head
由图④可以看出本地b1超前于远程b1一个提交。
（二）git cherry-pick
（三）git stash
有如下版本库：当前版本库的提交状态如下图所示
修改test.txt为如下内容
（四）git commit
（五）git fork：
如下图有share1.git，share2.git、share3.git三个版本库，其中share1.git和share2.git是两个单独的开源项目版本库。share3.git版本库是基于share1.git、share2.git两个开源项目版本库开发的本地项目版本库。此时share1.git、share2.git版本库将作为share3.git版本库的上游库而存在。如何能保证share3.git能与上游share1.git、share2.git版本库更新同步？
场景一：关联share3.git到share1.git、share2.git，并更新开源版本库代码到本地库share3中
（六）git fetch
（七）git reset：有如下所示的版本树结构，从a4f767e经历了两次提交后此时head指向9678728位置。
①：git reset –soft a4f767e 如下图记录了此次操作的变化。此时在.git文件夹下会产生一个ORIG_HEAD文件来记录原始的head值。变化到a47后head指向发生了变化。但是暂存区和工作区的文件并没有改变。(保留了上图⑥所处的状态，即ORIG_HEAD=9678728b5指向的版本区和工作区状态)如果基于变化后进行提交则可以将head改变到a47处。丢弃了之前的两次提交且工作区文件没有变化。
②：git reset –hard a4f767e2 如下图所示，reset –hard操作修改了index文件和工作文件。(回到上图④所处的状态即当前head：a4f767e2工作区和版本区的状态)
③：git reset –mixed head^^： 如下图所示
不修改工作区文件（保留了上图⑥所处的状态，即ORIG_HEAD=9678728b5指向的版本区和工作区状态）。
修改暂存区文件index。（回到上图④所处的状态即当前head：a4f767e2版本区的状态）
git commit时会
git stash
git stash list
git stash pop
git系列之（四）git stash工作原理
https://www.cnblogs.com/yelbosh/p/7471979.html
https://www.jianshu.com/p/d73dcee2d907