Git Merge与Git Rebase 的区别及使用场景，附带案例解释_git rebase和git merge区别 应用场景

ii：git merge

合并某分支到当前分支： git merge --no-ff 分支名   （正常合并）
回到解决冲突之前的状态: git merge --abort
1
2

使用时机和用法：

可以将master分支pull下来，此时就会得知俩个分支的不同点，修改完成之后就后进行merge请求，请求同意后自己分支的代码就合并到master分支上去了。
1

ui工具的操作底层指令以及含义：

底层指令：git merge --no-ff 分支名 

含义：在箭头所指的右侧图中本地分支weijiang/XQ与远程的dev分支进行合并，其含义就是将远程分支dev pull到当前的分支项目上，检查是否有冲突并解决冲突。
如果选择本地的话，就是本地的相同文件名不同内容的进行冲突解决。
1
2
3
4

iii：git rebase

git rebase -i dev 表示的是可以将dev分支合并到当前分支  -i 表示交互模式，可以干预rebase这个事物的过程，包括设置commit message，暂停commit等等
git rebase --abort 放弃一次合并，解决冲突报错回退
git rebase --continue 继续合并
1
2
3

使用时机和用法：

自己的开发分支一直在做，然后某一天，你想把主线的修改合到你的分支上，做一次集成,这种情况就用rebase比较好.把你的提交都放在主线修改的头上，为什么不建议使用merge呢？
1

ui工具的操作底层指令以及含义：

底层指令：git git rebase -i 分支名

含义：其实是和merge的含义是相同的，在箭头所指的右侧图中dev分支与master分支进行rebase，其含义是将master分支与分支dev进行merge操作，只是rebase与merge的操作的历史纪录情况会有不同，以至于可能会影响一些回退操作。
1
2
3

iv：git rebase 和 git merge的区别：

   rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
   举例:如果你从 master 拉了个prod分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。
   master 初始状态为1，2，3.在此基础上新建一个prod分支
   master 提交了4，5.  prod分支提交了6，7.
   此时分支状态：master->1-2-3-4-5
               prod ->1-2-3-6-7
   在prod上使用rebase master，prod分支状态变成1-2-3-4-5-6-7            如果merge master，prod分支状态变成1-2-3-6-7-8
           这里的8提交的是4-5合起来的提交
   merge之后想回退到你分支上的某个提交就会很麻烦！      
1
2
3
4
5
6
7
8
9

merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交
1

实操演示步骤：

前提准备：新建俩个项目，并且进行初始化，在俩个项目里面都新建一个a.txt文件，并提交到本地仓库（有哪个步骤不懂得都可以私信博主哦！）


接下来就是流程操作了

一：选择新建一个分支dev分支，在这个分支下进行俩个操作，修改a.txt,添加b.txt,
完后提交到本地仓库
1
2

二：切换成master分支，在master分支上再次修改a.txt文件，**并且提交之后在master分支进行merge操作，**效果图如上merge操作ui展示效果来操作就可以，完后提示一个冲突框，选择自己想要的代码作为最终代码即可，完后提交修改后的最终代码，按照如下的步骤来操作即可
1

如上是给git merge 的效果展示，接下来是git rebase 的操作

一：在准备的前提下，同gir merge的操作一样，选择新建一个分支dev分支，在这个分支下进行俩个操作，修改a.txt,添加b.txt，完后提交到本地仓库
1

二:切换成master分支，在master分支上再次修改a.txt文件，**完后切换回dev分支上，进行rebase操作**，效果图如上rebase操作ui展示效果来操作就可以如下图,之后会出现一个解决冲突的，选择自己想要的最终结果就可以，之后继续点击resume继续完成rebase的操作即可，便可以看到如下第二张图的效果
1

实操效果图

用1234来表述的话，dev分支上的情况就是：
merge ： 1-3-4 4是2和3的head指向合并之后的
rebase： 1-2-3 
1
2
3

rebase操作之后的log日志时间是一条线比较清楚，而merge操作在多人开发的情况下，log日志则是错综复杂的交错着，看着很混乱