1.get pull、git pull --rebase之间的区别
git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase
2.git merge 跟git rebase又有什么区别呢？
rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交
rebase没有产生新的节点，使用rebase的git演进路线(提交树)是一直向前的，这样在版本回退时也很容易，用merge的git路线是跳跃的，如果版本回退你也找不到自己想要的版本，如果在merge时出现了冲突那就麻烦了，当前merge就不能继续进行下去，需要手动修改冲突内容后，add，commit, push. 而rebase 操作的话，会中断rebase,同时会提示去解决冲突
3.什么场景适合使用rebase呢？
打个比方，你现在有个dev开发分支，这时你从dev分支切了个新功能分支feature，你从现在开始基于feature分支开发
张三提交了一段代码到dev分支，此时你在feature分支上也开发新的功能需要提交，但是是希望基于张三的提交代码之上，且希望提交的commit是一条直线时间轴，而不是交叉的时间轴，此时你应该在feature分支上执行 git rebase dev
如果git rebase dev 后 出现冲突，那么你手动解决一下冲突然后
①执行 git add .
②执行 git rebase --continue
③git push origin feature 此时你发现你提交不了，那么接下来继续
④执行git push origin feature --force 提交成功
此时你的feature分支已经同步了张三在dev的提交
4.那么在dev分支，如何同步feature分支呢
① 在dev分支，先pull最新代码 注意 使用git pull --rebase origin dev
② 执行git merge dev 如果你之前在dev的rebase操作是正常，这步不会出现冲突，直接看第④步，出现了冲突我们看第③步
③ merge dev 分支发现出现冲突咋办，这个时候应该不急着解决冲突提交操作。而是思考下为什么feature分支明明rebase dev分支的代码，为啥还会冲突呢。问题就出在你在feature的rebase操作，可能在rebase冲突解决中，冲突没有解决完整，也有可能你在feature分支做了重复的commit，此时我们应该在dev分支中撤销刚刚的git pull --rebase origin dev操作，并且切回feature分支，同样撤销上一次的git rebase操作提交(如何撤销rebase，看下文注意说明)，重新git rebase dev 解决冲突操作
④ merge没问题后，直接git push推送代码到远程仓库，这时你的commit时间轴 仍是一条直线
