In git, what is the difference between merge --squash and rebase?
上面鏈接的回答中的總結：
Both git merge --squash and git rebase --interactive can produce a "squashed" commit.
So the differences are:
- one does not touch your source branch (tmp here) and creates a single commit where you want.
- the other allows you to go on on the same source branch with:
- a new base
- a cleaner history
squash（聚合）
假設從master分支有三個節點C1，C2，C3
從C3切出develop分支，並在develop分支上開發了C4,C5
現在切回master分支，將develop分支合並到master。如果使用聚合的方式進行合並的話，那么git會將develop分支上所有的commit壓縮成一個新的commit為C6直接合並到master分支。
最后master分支上的節點為C1，C2，C3,C6
git詳解之三 git分支中的解釋：
3.6 分支的衍合
把一個分支整合到另一個分支的辦法有兩種：merge 和 rebase（譯注：rebase 的翻譯暫定為“衍合”，大家知道就可以了。）。在本章我們會學習什么是衍合，如何使用衍合，為什么衍合操作如此富有魅力，以及我們應該在什么情況下使用衍合。
基本的衍合操作
請回顧之前有關合並的一節（見圖 3-27），你會看到開發進程分叉到兩個不同分支，又各自提交了更新。
圖 3-27. 最初分叉的提交歷史。
之前介紹過，最容易的整合分支的方法是 merge 命令，它會把兩個分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）進行三方合並，合並的結果是產生一個新的提交對象（C5）。如圖 3-28 所示：
圖 3-28. 通過合並一個分支來整合分叉了的歷史。
其實，還有另外一個選擇：你可以把在 C3 里產生的變化補丁在 C4 的基礎上重新打一遍。在 Git 里，這種操作叫做_衍合（rebase）_。有了 rebase 命令，就可以把在一個分支里提交的改變移到另一個分支里重放一遍。
在上面這個例子中，運行：
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it... Applying: added staged command它的原理是回到兩個分支最近的共同祖先，根據當前分支（也就是要進行衍合的分支 experiment）后續的歷次提交對象（這里只有一個 C3），生成一系列文件補丁，
然后以基底分支（也就是主干分支master）最后一個提交對象（C4）為新的出發點，逐個應用之前准備好的補丁文件， 【這里需要特別注意，是以master分支的最后一個提交對象為新的出發點】
最后會生成一個新的合並提交對象（C3’），從而改寫 experiment 的提交歷史，使它成為 master 分支的直接下游，如圖 3-29 所示：
圖 3-29. 把 C3 里產生的改變到 C4 上重演一遍。
現在回到 master 分支，進行一次快進合並（見圖 3-30）：
圖 3-30. master 分支的快進。
現在的 C3’ 對應的快照，其實和普通的三方合並，即上個例子中的 C5 對應的快照內容一模一樣了。雖然最后整合得到的結果沒有任何區別，但衍合能產生一個更為整潔的提交歷史。如果視察一個衍合過的分支的歷史記錄，看起來會更 清楚：仿佛所有修改都是在一根線上先后進行的，盡管實際上它們原本是同時並行發生的。
一般我們使用衍合的目的，是想要得到一個能在遠程分支上干凈應用的補丁 — 比如某些項目你不是維護者，但想幫點忙的話，最好用衍合：
先在自己的一個分支里進行開發，當准備向主項目提交補丁的時候，根據最新的origin/master 進行一次衍合操作然后再提交，這樣維護者就不需要做任何整合工作
（譯注：實際上是把解決分支補丁同最新主干代碼之間沖突的責任，化轉為由提交補丁的人來解決。），只需根據你提供的倉庫地址作一次快進合並，或者直接采納你提交的補丁。
請注意，合並結果中最后一次提交所指向的快照，無論是通過衍合，還是三方合並，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合並是把最終結果合在一起。