git rebase 何時用

簡介

git rebase 俗稱變基，做用是將提交到某一分支上的全部修改都移至另外一分支上，就好像「從新播放」同樣。這樣操做後，提交歷史會變得簡潔，可讀性更高，由於提交記錄改變了時間線，把某個完整功能的提交記錄整合在了一塊兒，使得這期間其餘人的提交記錄不會穿插到其中，乾淨舒爽！🚾👯‍♂️

原理

它的原理是首先找到兩個分支（當前分支 experiment、變基操做的目標基底分支 master）的最近共同祖先 C2，而後對比當前分支相對於該祖先的歷次提交，提取相應的修改並存爲臨時文件，而後將當前分支指向目標基底 C3, 最後以此將以前另存爲臨時文件的修改依序應用。

重點 ❗❗❗

具體該如何操做網上有不少文章，這裏只是記錄一下git rebase使用時該注意什麼

需遵循的金科玉律：不要對在你的倉庫外有副本的分支執行變基。

若是你遵循這條金科玉律，就不會出差錯。 不然，人民羣衆會仇恨🌚你，你的朋友和家人也會嘲笑🌚你，唾棄🌚你。

只要你把變基命令看成是在推送前清理提交使之整潔的工具，而且只在從未推送至共用倉庫的提交上執行變基命令，就不會有事。 假如在那些已經被推送至共用倉庫的提交上執行變基命令，並所以丟棄了一些別人的開發所基於的提交，那你就有大麻煩了，你的同事也會所以鄙視🌚你。

變基 vs. 合併🌏

你必定會想問，到底哪一種方式更好。 在回答這個問題以前，讓咱們退後一步，想討論一下提交歷史到底意味着什麼。

有一種觀點認爲，倉庫的提交歷史便是 記錄實際發生過什麼。 它是針對歷史的文檔，自己就有價值，不能亂改。 從這個角度看來，改變提交歷史是一種褻瀆，你使用 謊話 掩蓋了實際發生過的事情。 若是由合併產生的提交歷史是一團糟怎麼辦？ 既然事實就是如此，那麼這些痕跡就應該被保留下來，讓後人可以查閱。

另外一種觀點則正好相反，他們認爲提交歷史是 項目過程當中發生的事。 沒人會出版一本書的初版草稿，軟件維護手冊也是須要反覆修訂才能方便使用。 持這一觀點的人會使用 rebase 及 filter-branch 等工具來編寫故事，怎麼方便後來的讀者就怎麼寫。

如今，讓咱們回到以前的問題上來，到底合併仍是變基好？但願你能明白，這並無一個簡單的答案。 Git 是一個很是強大的工具，它容許你對提交歷史作許多事情，但每一個團隊、每一個項目對此的需求並不相同。 既然你已經分別學習了二者的用法，相信你可以根據實際狀況做出明智的選擇。

總的原則是，只對還沒有推送或分享給別人的本地修改執行變基操做清理歷史，從不對已推送至別處的提交執行變基操做