当远程 master 分支比开发分支 feature 领先
通常情况下，master 分支的合并权限由专门的高一级开发者组长拥有，作为小开发的我们需要提交 merge 合并的申请，大家一起 review 代码后，由组长合并。而 master 分支有可能比我们本地分支超前，其他同事可能解决了一些 bug fix，比我们本地分支超前。如下图：
如果这个时候我们向 master 分支直接提交 merge 很有可能存在文件冲突的问题，就是自己的分支 feature-ask 和 bug-fix 同时修改了某个文件，直接向 master 提交 merge 相当于让你的组长帮你解决冲突，这显然不合理的。因为代码是你自己写的，逻辑只有提交 merge 的人更清楚。
这个时候就需要使用 rebase 了，rebase 的意思就是 replace base, 将自己分支 feature-ask 的 base 移动到 main 最新的位置。
rebase 有冲突的时候
如图是 main 分支合并了 bug-fix 分支的代码，这时，远程 main 分支已经比本地的 feature-ask 分支领先了。如果我们直接在 main 分支合并 feature-ask 分支的话会有如下提示：
意思就是得先解决冲突才能完成合并，这就给组长添麻烦了 😂 。组长也不会给你合并的。
正确的解决方案是：在自己的分支 feature-ask 解决完冲突再提交合并。
- 在 feature-ask 分支
git pull --rebase origin main，将远程分支 main 的代码更新到 feature-ask 分支上。 - 解决冲突。
git add .git commit -m "rebase and feature-100"git rebase --continue- 强制将本地修改推送到远程 feature-ask 分支上：
git push -f
然后我们就可以发起合并 master 的合并请求了。
在 feature-ask 分支执行 - git log --graph --pretty=oneline --abbrev-commit 后，可以看到:
相当于将 feature-ask 的基础调整到 bug101-fix 之后，然后再向 main 分支合并。
rebase 没有冲突
如果 bug-fix 分支修改的文件正好与我们开发的分支 feature-ask 没有相同的修改文件，那就不会有代码冲突了，这个时候的步骤如下：
- 在 feature-ask 分支
git pull --rebase origin main，将远程分支 main 的代码更新到 feature-ask 分支上。 - 强制将本地修改推送到远程 feature-ask 分支上：
git push -f
如果已经没有冲突了，为什么还要使用 rebase 呢？因为当远程 master 分支比开发分支 feature-ask 分支领先的时候，我们并不能保证一定没有冲突，不能等出现冲突的时候再去想怎么解决，所以要提前将领先的 master 分支的代码更新到自己的开发分支，然后再去申请合并。
