終於知道為什麼要 rebase 而不是 merge (2)

git merge 很好很強大，不過在面對 local branch 時，
一直 merge 真的是會很煩，會看到一大堆：

Merge branch 'master' into sandbox

如果說這個 branch 不會跟別人共享，其實也沒必要留下 merge 資訊。
改用 rebase 的話，還能隨時生出針對別人 HEAD 的 patch,
會讓整個 commit history 漂亮些。相關的東西，還有 squash merge 等等...

剛剛有幸試用了一下 rebase:

godfat ~/p/g/photos> git rebase master
First, rewinding head to replay your work on top of it...
Applying: setup t2 configs.
Applying: run only one thin for test server.
Applying: only one image_server.

這樣做真的漂亮多了！現在這個 t2 branch 跟之前的 sandbox 類似，
就是為了跑在某個特定環境下的 branch, 所以平時根本不需要 commit,
只要一開始改一些設定檔就可以了。如果一直用 git merge master,
就會生出一堆不必要的 merge 資訊。改用 rebase 的話，
這個 branch 的 config commit 就會永遠放在最上面，
然後底下的 commit 就會完全跟 master 相同！

所以 rebase 可以想像成把 master 複製一份，
然後把原本的 branch t2 的獨立 commit 抽出，再一一 apply 至
這個新複製好的 master branch, 產生出 t2' 的新 branch.

也就是說這是新的 branch! 只是名字還是用 t2 而已。
所以如果這個 branch 要 push 進其他 repository,
就會需要 force push... 雖然我還不太懂這是什麼意思，
但這個動作其實是很危險，不能隨便亂用，他會造成一些 commit 消失。

在這邊，就是原本的 merge commit 和原始的 config commit 會消失。

不熟千萬別亂用... 現在是只有我在用，所以我確定不會蓋掉不該蓋掉的 commit...

這大概也是為什麼 git svn rebase 肯定會使得 git repo 同步碰到困難。
至於為什麼沒有 git svn pull? 大概是先天問題吧...