什么是git merge和git rebase
在团队协作中，每个人基于自己的分支进行开发，git merge与git rebase都是用于将一个分支新产生的代码变动基于commit记录合并到另一个分支，但二者的实现方法有些不同。以如下working tree为例：
我们在feature分支上开发新的特性时，main分支新增了其他团队成员的commit，在我们需要同步主分支代码到工作分支时，我们拥有merge和rebase两种选择，他们的实现方式如下：
git merge
git checkout feature git merge main
此时git会把主分支的新变动作为一次新的commit，合并到feature分支中，也就完成了同步最新代码的操作，此时可以视作两个分支在merge commit时产生了交汇。
可以看出，merge操作是不具破坏性的，它并不会破坏working tree的结构，但不可避免地，merge也会给代码提交记录中带来很多没有意义的merge commit，并使working tree变为非线性，在今后需要查看历史代码提交版本时将会让人非常头疼。
git rebase
git checkout feature git rebase main
此时git会把main分支的最新commit放在我们新提交的commit之前，如果rebase过程中没有产生代码冲突，则不会产生rebase commit。试想我们使用rebase方式合并代码，并将代码提交至main分支，那么得到的working tree就会是线性的，看上去我们是基于rebase时的main分支开发了新的feature。这样做会得到比merge更干净的working tree，但同时rebase操作也会带来代码分歧等问题。
git rebase的雷区
试想由于操作失误，我们不慎在main分支上进行了
git rebase feature操作，此时main分支的新commit被放在了feature分支的commit之后，这样得到的main分支的working tree将会和远程的main分支的产生分歧，此时只能通过merge来同步远程与本地的代码，这会带来极其混乱的提交记录。
此外，如果在远程的 feature分支有未合并到main分支的代码，再在本地的feature分支进行
git rebase main操作，那么本地与远程的代码提交记录就会产生分歧，此时需要使用如下命令来强制推送代码：git push --force
考虑到这一点，我们就只能在只有自己在使用的分支上进行rebase操作，如果有多人在基于同一个分支进行开发，rebase操作就会是极其危险的，一旦我们使用force push将代码推送至远端，那么所有基于同一分支进行开发的人的代码的working tree就都会和远端代码的产生分歧。
因此，在rebase操作前，务必确认自己的rebase分支是否正确，当前分支是否与其他开发者共享。