關鍵點
違反就會遭到詛咒的重點中的重點：
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
官方文件