https://segmentfault.com/a/1190000019455172

1

在現實的開發過程中，嚴格禁止在公共分支上 rebase on 其他分支（譬如不允許在 master 分支上直接執行 git rebase branchname）。使用 merge 是最保險的合併分支方式，如果你對時間線清晰度要求不是那麼高的話。但是如果你對時間線的清晰程度有比較高的要求，那麼在合併分支的時候按第二種方法 rebase 就能幫助形成清晰的線性時間線，但是 rebase 的壞處是丟失了一部分提交操作歷史。

$ git checkout feature
$ git rebase master
$ git checkout master
$ git merge feature

2

除了合併不同分支這種情況，還有一個十分常見的情況，多人在同一個分支上開發，如何保證同一條分支具有清晰的時間線。我們假設有三個人在開發 feature 分支，通常開發習慣是：

checkout feature 分支到本地。
開發，並把開發的內容提交到本地 feature。
使用 pull 把遠端倉庫中的 feature 和本地 feature 同步（pull 的預設方式是把遠端的程式碼和原生代碼做 merge 操作）。
push 同步完的 feature 分支到遠端倉庫。

因為 pull 預設是通過 merge 遠端倉庫和本地倉庫實現同步的，所以每次 pull 都會多出一個提交記錄。但是我們可以通過指定引數來指定 pull 的時候使用 rebase 策略：$ git pull --rebase。

通過圖示我們看到，如果使用 pull 的 rebase 模式，那麼多人協作同一個分支也可以做到時間線清晰。最後再通過之前提到的 rebase 方式把 feature 合併到 master 分支上。那麼整個開發過程時間線就呈現出清晰的時間線。

3 總結

和遠端倉庫同步當前分支的時候使用 pull --rebase 的方式。
合併分支的使用 feature rebase on master，master merge feature 的方式。