git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase
变基：rebase命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。在对两个分支进行变基时，所生成的“重放”最好在目标分支上应用。更多变基详见：Git-分支-变基
⚠️注意：如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。
比如有两个分支，master和test，test上开发完毕，准备合并到master上
用git merge命令把"origin"分支上的修改pull下来与本地提交合并，生成一个新节点G，并保留了原有的提交，但这样会形成图中的闭环。
用git rebase创建一个新的提交，提交的内容和上面的一样，但我们将test提交重放到master分支上，保持提交曲线为直线，让大家易于理解。
总结git merge和git rebase的区别：
merge:生成一个新节点,之前的提交分开显示。 rebase:不生成新节点,是将两个分支融合成一个线性的提交。
⚠️注意：在rebase的过程中，有时也会有conflict，这时Git会停止rebase并让用户去解决冲突，解决完冲突后，用git add命令去更新这些内容，然后不用执行git-commit,直接执行git rebase --continue,这样git会继续apply余下的补丁。
在任何时候，都可以用git rebase --abort参数来终止rebase的行动，并且mywork分支会回到rebase开始前的状态。
问1：难道仅仅为了避免产生闭环，所以用git pull --rebase吗？如果我care这个呢？
答：变基合并问题才是主要的非用git pull --rebase的理由，避免产生闭环只是表象。这种合并方式有潜在的 bug，2015 的时候bitbucket 就说过这个事情了 https://blog.developer.atlassian.com/a-better-pull-request/，同时增量代码修复问题的的时候导致的这种情况，git是不会报git merge conflict的直接就合并了。如下图。
问2：当我每次需要在新分支上开发，然后合并到master上，怎样避免变基合并问题？
每次开发的新分支都是dev，每次到dev时，git pull --rebase origin dev，一次迭代开发完，合并完代码mr后跑一下这个命令： git pull --rebase origin master
问3: 怎么复现增量代码修复问题不报错merge conflict问题？（待实操验证）
比如线上的dev分支出了个bug，现在需要修复，A，B都跑来修，但彼此都不知道对方也在修。假定此时开发A和B此时的本机dev分支与线上的都是一样一样的。
A来修，在第4行写了修复代码，A修完，git pull,git push.
B也来修，在第6行写了修复代码，B修完，此时A已经修完提交了但B不知道，B修完提交。git pull,git push。这样，如果A和B修复的内容就算一样，但是一个在第4行修的，一个在第6行修的。B在提交的时候，第4行和第6行的代码都保留着，不会发生冲突。但实际上只需要保留一个。因而，B修完的话，应该先git pull --rebase origin dev，将最新的线上的dev分支在B的本地dev分支重新播放一次，发现第4行和第6行冲突，就会报错merge conflict出来！
但是，实际中，谁知道A和B谁先修完呢？所以最好在提交代码到线上的时候，都先git pull --rebase origin dev，然后再git push origin dev。
