git主分支覆盖子分支
本例子展示的是主分支“强制”覆盖子分支；也就是说你决定不再需要你的子分支了；
1 本地pull 主分支master的最新代码；git log 看最新的日志；
2 git push origin master:temp
相当于拉一个字分支叫temp;如果temp本来就存在，那主分支的更新原则上会覆盖子分支的东西；
但是实际上可能会有这样的错误：
! [rejected] master -> temp (non-fast-forward) error: 无法推送一些引用到 'https:/****' 提示：更新被拒绝，因为您当前分支的最新提交落后于其对应的远程分支。 提示：再次推送前，先与远程变更合并（如 'git pull ...'）。详见 提示：'git push --help' 中的 'Note about fast-forwards' 小节。
这是为什么呢？
说明你的字分支拉取时候的版本，后来在主分支是倍别人改了很多，但是你没有及时同步，你又基于拉取时候的分支做了修改；
“别人上传到远程仓库后，你没有及时的同步（、拉取）到本地，但是你同时又添加了一些内容（提交），以致于你在提交时，它会检测到你之前从远程仓库拉取的时候的仓库状态和现在的不一样。于是，它为了安全起见拒绝了你的提交（然后就报了这个错误）。-https://blog.csdn.net/weixin_41287260/article/details/89742151”
3 此时，为了方便，我也不想要我的分支了，因为我修改的很少我用文本文件把我修改的东西保存下来了；那我就强制用master把我的temp分支覆盖：git push origin master:temp -f
之后我再把我刚才在temp上的修改重新写一下。。。这个方法有些麻烦的；
4 假设我的git上边的时间线是这样的
这种写法并不能成功的将“我的git上边的时间线的代码”主分支合并到temp分支；因为merge是下图这个样子的：而我上边的git状态，除了共同的起始点，还有共同的X状态的，就是说我在temp上改的不仅出现在temp分支上，master上也有的；
我的合并前状态：合并的原理是找到共同的起源，现在共同的起源应该是master0，但是绿色的圈（我自己修改的代码）对merge有影响
