Git rebase_git 提交记录 rebase top 导致没按时间顺序排列

-------------------------------Rebase--------------------------------------------------
rebase 刷新当前分支基底，用于保证feature分支是基于master分支的最新变化上作为基底，

时张三想拉下最新代码，于是他在feature分支上执行了git rebase master，
rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（新节点新commit id），如此feature分支的基底就相当于变成了M而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

merge和rebase都是增加当前分支内(从别的分支拉过来
merge是在最新的时间：累加一次提交
rebase是刷新基地后，拼接N次提交，不按时间顺序，会容易出现 多次 冲突

三、推荐使用场景
拉公共分支最新代码的时候使用rebase，也就是git pull -r或git pull --rebase。这样的好处很明显，我用rebase拉代码下来，但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛。

正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序
————————————————
log-显示 按照时间的提交记录 reflog-显示所有动态
无论怎样向前reflog把穿越这个动作本身都被记录了下来/也就是说 把每次后退算成一次向前进
git的时间线，git reflog显示的才是我们git真正的时间线。不过一般的情况，我们就按照git log的时间线来理解就行了