rebase命令不要使用的场景

场景1：

​ 永远不要在公共分支上使用rebase命令

​ 这个我就不举例了，可以直接参考

​ https://git-scm.com/book/zh/v2/Git-分支-变基

场景2：

​ 合并到测试分支时用merge方式，不要用rebase方式

​ 当你从master分支拉出一条分支来进行开发，开发完后需要进行测试，此时你要测试的分支叫dev分支，你需要合并到dev上进行测试。这个时候，千万不要用rebase方式合并到dev分支，正确做法是使用merge方式合并到dev后测试。测试完成后，再rebase到master分支。

​ 原因：如果dev分支和你的分支不一样（实际情况往往不一样，因为好多开发人员都往dev分支提交代码），这个时候rebase dev会出现你的分支落后于你的远程分支的提示，让你git pull合并，这个时候，无论你是git pull或者git pull --rebase，你都会获取到dev的分支杂乱的commit信息和杂乱的代码到你的分支。如果再合并到master上，就有一些乱七八糟的代码，从dev分支，进入你的分支，然后进入master分支

​ 举个例子说明

①先从master分支（发布分支）上拉出一个分支叫dev（测试分支），再拉出一个分支叫mybranch（用于开发新功能的分支）

②master分支添加新文件后，使用git add 和git commit和git push推到远程master分支了【模拟master分支有新功能分布了】

③dev分支添加新文件后，使用git add 和git commit和git push推到远程dev分支了【模拟dev分支有人在测试】

④mybranch分支添加新文件后，使用git add 和git commit和git push推到远程mybranch分支了【模拟mybranch开发新功能】

此时的graph

⑤使用rebase方式合并到dev分支后的graph(mybranch上rebase dev，然后dev上merge mybranch)

此时可以看到dev上已经有了mybranch开发的新功能了

再看一下mybranch分支情况

这个时候问题就出来了，提示你mybranch分支落后于远端mybranch分支

这个时候可以有以下几种做法，我一一来测试一下：

❎错误做法1：直接rebase master然后合并到master上，你会发现dev提交的代码也上了master

查看graph，可看到master分支有dev分支的杂乱代码，而不是只有你自己新功能的代码

❎错误做法2：此时使用git pull来更新mybranch分支，更新完成再rebase合并到master分支

PS:我重来拉出两个分支测试，和之前流程一样，只是dev变为dev1,mybranch变成mybranch1

执行了①②③④后的graph

使用git pull来同步远程mybranch分支

使用命令git pll同步远程mybranch1分支，按下回车后，会提示输入commit信息

同步完远程mybranch1分支后push上去，查看graph

可以看到mybranch1和dev1已经有交叉点了。此时rebase master后看看情况

虽然交叉点在mybranch1和dev1分支上，但是dev1上的新功能也同步到master上了，这也是错误的做法

❎错误做法3：此时使用git pull --rebase来更新，然后rebase到master

PS:我重来拉出两个分支测试，和之前流程一样，只是dev变为dev2,mybranch变成mybranch2

执行了①②③④后的graph

使用git pull --rebase命令后，再push上去后，发现mybranch分支已经有了dev的新代码

通过rebase方式合并到mster上，也可以看到有了dev的杂乱代码

✅正确做法：merge到dev测试，然后rebase到master分支。

PS:我重来拉出两个分支测试，和之前流程一样，只是dev变为dev3,mybranch变成mybranch3

执行了①②③④后的graph

此时切换到dev3分支，merge mybranch3，查看graph

测试完后，rebase到master，查看graph

可以看到master中只有mybranch3中的代码，没有dev中的杂乱代码。也没有交点。大功告成。

验证：删除其他分支，只留下master分支，查看graph