git rebase使用及详解
git rebase有三种特别常用的地方
- 拉取远程代码
- 合并多次提交
- 合并分支
1. 拉取远程代码
首先要说的是在这三种使用场景中,使用最为频繁的 拉取远程代码的场景
而拉取远程代码进一步可细分为两种情景
- 远程代码中他人的提交与本地我们的提交有重合
- 无重合
1.1 代码无重合
先说这个简单一些的,无重合代码的情况
我们已经明白了如何从其它地方 pull 提交记录，以及如何 push 我们自己的变更。
看起来似乎没什么难度，但是为何还会让人如此困惑呢？
困难来自于远程库提交历史的偏离。
在讨论这个问题的细节前，我们先来看一个例子……
假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。
这种情况下, git push 就不知道该如何操作了。
如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，亦或由于你的提交已经过时而直接忽略你的提交？
实际上正因为这情况（历史偏离）有许多的不确定性，所以Git 是不会允许你 push 变更的。它会强制我们先合并远程最新的代码，然后才能分享自己的工作内容。
演示均在一个运用了沙盒技术的网站中进行的,任何人都可以访问,其中说到的git clone和git push之类的命令都是简写, 网站地址https://learngitbranching.js.org/,学习git的时候一般建议入门先看廖雪峰的git教程,进阶后再刷完刚刚给的网站上的所有的git任务
push失败之远程库包含新内容https://www.zhihu.com/video/1142116522108506112那该如何解决这个问题呢？
我们需要做的就是使我们的工作基于最新的远程分支。
有许多方法做到这一点呢,最直接的方法就是通过 rebase 调整你的工作.咱们继续,看看怎么 rebase！
将远程库中多出的提交合并到本地https://www.zhihu.com/video/1142117844316753920注意到我们是先在本地做了一次提交c3,之后有人提交到了远程库c4,然后我们git pull --rebase,使得我们的c3提交得到了转变c3',为什么会转变,因为git pull --rebase的按照提交时间顺序排列指的是相对于远程库的,由于c4先提交到了远程库,而我们本地的还没有在远程库中记录,所以在pull --rebase的时候,c4会变化到我们的c3之前,也就是此时的c3的基础从c2变为了c4,也就是rebase(变基)
还有其它的方法可以在远程仓库变更了以后更新我的工作吗?
当然有，我们还可以使用 merge.
尽管 git merge 不会移动你的工作（它会创建新的合并提交），但是它会告诉 Git 你已经合并了远程仓库的所有变更。这是因为远程分支现在是你本地分支的祖先，也就是说你的提交已经包含了远程分支的所有变化。
演示...
将远程库中多出的提交合并到本地https://www.zhihu.com/video/1142118315966222336如此,我们就可以使用rebase很好的解决,诸如此类的,团队伙伴先于我们提交到远程库,而我们的修改又是没有基于远程库的最新提交(就是团队伙伴的提交)的情况,也就是,使用git rebase使得我们本地的提交基于远程的最新提交.