变基

在开发中除了通过merge合并分支外，还可以通过变基来完成分支的合并。

我们通过merge合并分支时，在提交记录中会将所有的分支创建和分支合并的过程全部都显示出来，这样当项目比较复杂，开发周期比较长时，必须要反复的创建、合并、删除分支，这样一来将会使得我们代码的提交记录变得极为混乱。

原理（变基时发生了什么）：

1. 当我们发起变基时，git会首先找到两条分支的最近的共同祖先

2. 对比当前分支相对于祖先的历史提交，并且将它们提取出来存储到一个临时文件中

3. 将当前部分指向目标的基底

4. 以当前基底开始，重新执行历史操作

变基和merge对于合并分支来说最终的结果是一样的！但是变基会使得代码的提交记录更整洁更清晰。

注意：大部分情况下合并和变基是可以互换的，但是如果分支已经提交给了远程仓库，那么这时尽量不要变基。

执行 git rebase 后最终的结果都是一条直线，但是中间的顺序会稍微有些不同，这是由于rebase的机制导致的。

在 Git 中每个分支都有一个指针（HEAD），指向当前分支的最新提交记录，而执行 rebase 操作的时候，Git会先找到当前分支和目标分支的共同祖先，再把当前分支上从共同祖先到最新提交记录的所有提交都移动到目标分支的最新提交后面

# 切换dev分支
git switch dev

# 将dev分支提交记录变基到main分支上
git rebase main

squash 压缩提交

压缩提交会重写历史，这在你的提交已经推送到远程仓库并且被其他人使用时会造成困扰。在这种情况下，如果你需要压缩提交，应该与团队协调，因为其他人需要处理重写后的历史。

通常，只有在提交尚未推送，或者在一个你负责的个人分支上，才应该压缩提交。

# 启动交互式变基，N是想要合并的提交数量
git rebase -i HEAD~N

# 将除了第一个提交之外的其他提交的pick改为 squash 或 s：这会指示 Git 将这些提交合并到它们上面的提交中。也可以使用 fixup 关键字代替 squash。

# 保存文件后 Git 将开始合并提交，如果出现冲突，Git会暂停并让你解决冲突，然后继续变基。

rebase和merge有什么区别，该如何使用呢？

	优点	缺点
git merge	不会破坏原分支的提交历史，方便回溯和查看。	会产生额外的提交节点，分支图比较复杂
git rebase	不需要新增额外的提交记录，形成线性历史，比较直观和干净。	会改变提交历史，改变了当前分支 branch out 的节点。 避免在共享分支上使用rebase操作

一般来说，如果你只是想把两个分支合并起来，而不关心提交历史的话，那么就可以使用 git merge。如果你确定只有你自己在一个分支上开发，并且希望提交历史更加的清晰明了，那么就建议使用 git rebase 命令。