2015-06-19

git merge or rebase?

昨天在Hacking Thursday (H4)參與Git Workflow的讀書會,突然想到一個問題:
feature branch完成後,在發送pull request前,如果master branch(或develop branch)又有新的commit,如圖

這時候應該要先git rebasegit mergefeature branch追上master branch才好呢?
一直以來我都是用git mergefeature branch的程式碼整理好才發pull request,也不知道我這樣用到底是不是大家習慣的用法,想不到在H4也是兩派人都有。上網一查才發現,這個問題的爭論,不亞於Emacsvim哪種編輯器比較好?看了兩篇文章Git team workflows: merger or rebase?Merge or Rebase?,覺得整理得還不錯。

使用git merge會像這樣

這種做法的優點是:容易了解與使用;保留完整的歷史紀錄,便於追蹤;如果feature branch也有分享出去的話,用git merge才不會搞爛大家的歷史紀錄。而其最大的缺點就是會讓歷史紀錄變得非常複雜,如果分支(fork)的人很多,歷史紀錄很有可能變成網狀的,而不再只是樹枝狀的結構。

使用git rebase會像這樣

這種做法最大的優點就是:簡化歷史紀錄,讓雜訊消失,變得更容易閱讀。但是其缺點是:git rebase使用起來不夠直覺,而且處理衝突(conflict)時不方便;由於歷史紀錄被簡化過,部分的資訊會消失,不利於後續追蹤;對於公開分享的feature branch,常常搞壞其他人的歷史紀錄。

看了大家的討論,會覺得當初何必多弄一個指令git rebasegit merge著重的點是完整記錄所有的歷史;而git rebase則讓歷史紀錄更容易閱讀。對專案管理者來說,或許git rebase有比較大的誘因,因為歷史紀錄容易閱讀,也很容易產生進度報告及報表。但是對於開發者來說,最重要的反而是詳盡的歷史紀錄,H4的Thinker說:
你要誠實面對你自己
其實在這之前我並沒有深入想過這個問題,純粹只是覺得git merge就夠用了,而且常聽說git rebase要小心使用。因此在Github上貢獻專案時就會想說避免闖禍,先用git merge就好。認真瞭解後才發現這真是一個有趣的問題,為了保留完整的歷史紀錄,現在可以更有信心的使用git merge了~
Post a Comment