git rebase 使用场景

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 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。

rebase

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

merge

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时间轴 仍是一条直线

注意：

1.下游分支更新上游分支内容的时候使用 rebase

2.上游分支合并下游分支内容的时候使用 merge

3.更新当前分支的内容时一定要使用 --rebase 参数

4.git reflog查看本地记录 找到你git rebase之前的版本号xxx  然后git reset --hard xxx 即可恢复