学会使用 git-rebase
关键点
违反就会遭到诅咒的重点中的重点：
Do not rebase commits that exist outside your repository and that people may have based work on.
不要 rebase 一个可能会被别人 checkout 的提交点
因为如果这个 commit 如果被队友签出，那么下一次他的代码提交肯定是基于这一个 commit 的
不在被别人可能引用的 commit 上使用 rebase，不然会导致 commit 失效
可以创建干净的 commit 历史
对 commit 产生的并行历史修改为串行历史
rebase 还可以压缩 commit，将多个 commit 压缩为一个commit
当你准备 commit 的时候，先使用 rebase 来快进到目标分支末尾，项目维护者不需要手动处理合并工作
常用于本地分支，多用于对 commit 进行重新修改，与 merge 不同，merge 会创建一个 commit，而 rebase 不会
基本原理为在某一个 commit 上重新执行你的修改（将你的修改重新播放到某一个 commit 之后）
说明
merge 创建了新的 commit
![[Pasted image 20221123163558.png]]
rebase 重新在 C3 上“重新播放”你的修改
![[Pasted image 20221123163623.png]]
这一操作叫做 rebase <source> onto <target>，在上面这个例子为 rebase experiment onto master
$ git checkout experiment
$ git rebase master
我如何提交
所有新的任务一律先签出一个分支进行开发，开发完成以后 fetch 远程最新主分支，然后对远程最新的主分支进行一个 rebase 操作，这样就能让提交历史成为一个串行
如果在开发的过程中，因为某些原因这个任务被暂停，没有特殊要求那么就将这个分支保留在自己本地
如果开发过程中，新加入紧急修复 bug 任务，那么就 stash 当前任务，处理紧急任务，完毕后再 stash pop 回归
如果需要在不同的地方开发并使用不同的电脑，那么就在远程开辟一个自己的临时 dev 分支，所有提交使用 -f 强推到自己的临时分支上去，点始终只保留一个提交（前提是仓库需要做好主分支的保护工作，避免误推），等到所有工作开发完毕后，fetch 远程最新主分支，然后将自己的分支 rebase 过去并提交，然后删除自己的远程临时分支
为什么要这么麻烦
取决于我们如何看待提交历史，如果你认为提交历史需要清晰干净，每一个提交点都有明确的意义，那么可以考虑加入 rebase
如果你认为提交历史就是历史，不应该对这种自然行为做出干涉，那么你可以完全不使用 rebase
