rebase 和 merge 一樣，都是要整合另一個 branch 的內容，
rebase 有一點 "管理 commit " 的意味。
如果把git 的每一次 commit 都當作一個 patch。
merge 會依照每個 patch 的時間，依序把merge 的兩個 branch 的 patch 一一上到source。
所以merge 完，兩個 branch 的 commit 有可能會穿插.
rebase 的話，就一律先上另一個branch 的 commit ，然後再上自己的 commit。
這在系統廠的工程師比較合用。
因為系統廠都是拿 vendor 的 bsp 來改。
所以當 vendor 有新版bsp 時，如果作 merge，
自己的修改和 vendor 的修改就會混在一起，
merge 時的 conflict 也會比較多(?)，因為有可能是 vendor 的commit 的 conflict，所以會比較不好 resolve。
如果是用 rebase 的話，至少第一步，vendor 的 new bsp 的 commit一定都上得去。
在自己的commit 才會發生 conflict，
這樣因為 conflict 是在自己的 修改，會比較好 resolve。
