git rebase 是不是就是跟 merge master 到你的 branch 产生代码的效果一样的, 不考虑 history log 等其他的因素
你都说不考虑 History Log 了,那就没啥可说的了……
不过实际上 Rebase 是没有方向约束的,你可以把 Master Rebase 到你的分支,也可以反过来,任何分支 Rebase 到任何目标都是可以的。
本质上 Merge 就是无视两棵树在历史记录上的差异,只是在执行 Merge 那一刻的将差异进行合并而已;而 Rebase 则是要梳理两棵树在历史记录上的差异,然后才是合并。
你可以形象的记忆:
举个例子,我从 master 分离一个分支出去,在此基础上做了一些提交,而此时 master 上也有别人的新提交了。如果我在新分支 merge master,则我的分支上会出现一个新的 commit,记录下我的和 master 上的变更的合体。就像两条线合成了一点。如果我用 rebase,则从我分离的那一点开始,master 上的新提交先填充进来,然后再把我自己做的提交重新写在更新的上面。于是内容还是合并了,但历史记录则是顺序的,从你的角度来看就好像从未和 master 分离过一样。
你都说不考虑 History Log 了,那就没啥可说的了……
不过实际上 Rebase 是没有方向约束的,你可以把 Master Rebase 到你的分支,也可以反过来,任何分支 Rebase 到任何目标都是可以的。
本质上 Merge 就是无视两棵树在历史记录上的差异,只是在执行 Merge 那一刻的将差异进行合并而已;而 Rebase 则是要梳理两棵树在历史记录上的差异,然后才是合并。
你可以形象的记忆:
举个例子,我从 master 分离一个分支出去,在此基础上做了一些提交,而此时 master 上也有别人的新提交了。如果我在新分支 merge master,则我的分支上会出现一个新的 commit,记录下我的和 master 上的变更的合体。就像两条线合成了一点。如果我用 rebase,则从我分离的那一点开始,master 上的新提交先填充进来,然后再把我自己做的提交重新写在更新的上面。于是内容还是合并了,但历史记录则是顺序的,从你的角度来看就好像从未和 master 分离过一样。