【Git Rebase 解决多人开发冲突】

rebase原理

rebase为当master有了新的提交，而自己的分支拉取的master相比最新提交有了落后的情况，需要及时通过变基转换为新的底座，这个master就是底座，我们需要进行rebase

背景

笔者在开发中，需要依赖下游分支，而下游分支也是正在开发联调以及测试中的，因此不时就应该对下游分支进行merge拉取，而这种merge会增加新的一条无效提交记录，让自己的改动和下游分支的改动混合在一起，难以做Code Review的分辨，因此最好使用rebase进行冲突的解决

解法

如果当前开发分支是feature/A，feature/A是从远程feature/B分支上拉取过来的，远程feature/B也在同步进行开发，如果想要拉取feature/B最新的分支，有两种方法：

1 git merge：

假设你有两个分支，一个是 master 分支，一个是 feature 分支，你在 feature 分支上开发了新功能，现在你想把这个新功能合并到 master 分支上，你可以按照以下步骤操作：
首先，你需要切换到 master 分支：
git checkout master
然后，你可以使用 git merge 命令将 feature 分支合并到 master 分支：
git merge feature
如果在合并过程中出现冲突，Git 会提示你。此时，你需要手动打开冲突文件，找到以下类似的标记：
<<<<<<< HEAD
代码片段 A
代码片段 B
你需要决定保留代码片段 A 还是代码片段 B，或者可能是两者的某种组合。解决冲突后，删除 <<<<<<< HEAD，=======，>>>>>>> feature 这些标记。

解决完所有冲突后，使用 git add 命令将解决冲突后的文件标记为已解决状态：
git add <解决冲突后的文件>
最后，提交这次合并以及冲突解决：
git commit -m “Merge feature branch and resolve conflicts”
这样，feature 分支的新功能就被合并到了 master 分支上。

2 git rebase

俗称变基，如果远程feature/B自拉取之后有 1——2——3——4，4次提交，我本地的feature/A有1‘——2’——3‘ 这3次提交，rebase会生成下面的这种情况

1——2——3——4——1‘——2’——3‘，尽管在开发的过程中，可能1‘、2’、3‘先于feature/B的4提交，执行rebase依次会将1’、2‘、3’放在4的后面，这也是rebase的弊端，无法区分当前开发分支（feature/A）是从什么时候在feature/B中拉取出来的，因此在有一些公司中不推荐使用

git rebase的原理：