参考资料
目录
前提
0.1 merge与rebase
⏹merge
- 如果你希望保留分支的历史记录，并且不介意有合并提交。适用于团队合作时保留每个人的工作记录。
⏹rebase
- 如果你希望保持提交历史的简洁和线性，适用于希望干净历史的项目。
🤔一般而言，如果你在自己的本地分支上进行开发，并且想要保持分支历史记录的干净和整洁，就可以使用git rebase。
而对于多人协作的项目来说，由于需要共享代码库，因此最好使用git merge来避免破坏其他人的历史记录。
0.2 merge合并分支
⏹下图是 merge 合并分支时前后版本变化的情况
- merge 会创建一个新的合并提交，将两个分支的历史记录保留在一起。
- 日志保存完整，不管你之前合并进来的那个版本有多少个提交历史，都会被完整的合并到目标分支。
- 过多的提交合并到主分支之后，主分支的Graph会很乱。
0.3 rebase合并分支
⏹下图是 rebase 合并分支时前后版本变化的情况
- rebase 会将分支上的更改重新应用在目标分支上，重写提交历史。
- rebase 方式提交的版本历史是线性的，不会创建新的合并提交，历史记录非常干净。
⏹合并压缩
- 在rebase 的时候还可以使用 squash 参数来压缩提交记录。
- 例如下图，Feature 1 分支的 A、B、C 三个提交记录，使用 rebase squash 后会在主分支变为一个提交记录 F。
0.4 💥超级注意事项💥
❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌
❌❌❌避免在公共分支上使用 rebase❌❌❌❌
❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌❌
⏹不要在已经推送到公共仓库的分支上使用 rebase：变基会重写提交历史，这会使其他基于这些提交的工作分支出现冲突。
如果你在公共分支上使用 rebase，其他开发者可能会遇到合并冲突，并且需要强制拉取和合并他们的工作，这会带来很多不必要的麻烦。
⏹如果将本地分支的代码已经推送到远端，并且远端的代码并没有被合并到任何分支中，并且没有任何人基于你的分支进行开发，
此时rebase操作不会对别人的开发带来影响。
一. 代码已提交，未推送，交互式变基
1.1 通过SourceTree操作
🤔变基可以将多次本地提交合并为一次提交，简化提交履历。
💥注意：多次提交只是提交到本地Git仓库，并没有推送到远端仓库。
⏹如下图所示，我们分3次提交了代码到本地Git仓库，这3次提交都只是添加了console.log语句，
因此可以合并为一次提交然后推送到远端仓库
⏹交互式变基操作如下所示，选中要合并的提交的前一次提交，点击交互式变基功能，
然后将多次提交合并为一次。
1.2 通过Git命令行操作
⏹如下图所示，我们分3次提交了代码到本地Git仓库，这3次提交都只是添加了console.log语句
这次我们使用Git命令行的方式，将这三次提交合并为一次。
1.2.1 进入命令行终端，指定交互变基版本
⏹通过SourceTree的命令行模式进入Git命令行终端
⏹指定交互变基的版本为最近的3次提交
git rebase -i HEAD~3
1.2.2 指定需要处理的提交
⏹如下图所示，在vim模式下处理指定的提交
pick：保留该提交。reword：保留该提交，但允许你修改提交信息。edit：保留该提交，但在此提交暂停，允许你进行更改。squash：将此提交与前一个提交合并，并保留两个提交的信息。fixup：将此提交与前一个提交合并，但丢弃此提交的信息。drop：删除该提交。
⏹如下图所示，指定后两次提交与第一次提交合并，同时丢弃后两次的提交信息
f是fixup的简写
同时指定要修改提交的消息的版本
r是reword的简写
⏹修改完成之后，在vim模式下按下ESC之后，输入wq保存
1.2.3 指定提交信息
⏹如下图所示又进入编辑提交信息的界面，编辑完成之后，同样在vim模式下按下ESC之后，输入wq保存
⇓⇓⇓⇓
1.2.4 查看修改效果
⏹如下图所示，提交记录变成了一个，提交更加整洁了！
二. 代码已提交，已推送，交互式变基
2.1 通过命令行进行交互式变基，合并提交
⏹如下图所示，有3次打印消息，都已经推送到远端。
⏹在git终端通过下面的命令对最近3次提交进行交互式变基。
git rebase -i HEAD~3
⏹效果如下
2.2 将合并的提交推送到远端
2.2.1 遇到的问题
⏹ 直接推送的话，会发生如下图所示的错误
2.2.2 通过命令行强制推送
⏹git push origin 分支名称 --force
⏹效果如下
