Experience Share about how to merge patch in a quick and correct way.

1. 經驗分享 -
從 patch merge 談起
Kris Wang

2. 當你要處理的事情 規模放大到數倍
你仍然可以用一樣的人力限制跟時間
限制來完成
這時我才認為你有一個 " 方法“
否則你只是有個把事情做完的 " 做
法 " 罷了

3. 我們從
Patch Merge 開始談起

4. 情境
早上九點半 , 老闆要求你幫忙
merge 14 筆 issue 的 patch 到另
一個 branch, 預備今天 release

5. 你認為你需要多久完成這個工作
?
你怎麼知道你不會少 merge
code?
你怎麼知道你不會 merge 錯
code?

6. 來估計一下完成任務所需時間吧

7. 所需時間 = issues * (
( 尋找 issue 的相關 patch) +
(git cherry-pick) +
(conflict resolve) +
(git commit))

8. 你不是 issue owner, 怎麼知道某
筆 issue 總共 commit 了幾個
patch?

9. 做法 1:issue resolve( 包含 re-open 後的
patch) 後 , 必須記載所有相關的 commit
id
Risk: 無
搜尋時間 : 0
延伸思考 : git 使用者 , 可以用 commit
SHA 值當 id 嗎 ?

10. 做法 2: 直接問 issue owner, 要
merge 哪幾筆
Risk:owner 也可能漏了 . 或者根本
不鳥你
搜尋時間 : 看 issue owner 記憶跟
熱情程度

11. 做法 3: 自己用肉眼找
Risk: 不能確認看完幾筆才算掃完 ?
(git log 並不是依照 Date 欄位排序 )
或者鬼遮眼
搜尋時間 : 看你精神夠不夠好

12. 做法 4: 匯出 commit log 後 , 用工具搜尋
例如 :
(1) git log --since=“2014-03-01” > patch.txt
(2) 用 editer 搜尋 issue number or title
Risk: 如果有人 commit message 亂寫 , 就找
不到了
搜尋時間 : 幾分鐘
延伸思考 :commit log 格式規範

13. Merge 發生 conflict 時 ,
怎麼解決 ?

14. Google 上說 ,
自己看著辦

15. 方法 1: 用肉眼看 and 在 editor 上
解決
But 你真的看得懂這一片花花綠綠 ?
眼花了就 merge 錯囉

16. 方法 2: 用好的 merge tool 幫忙你

17. BTW, “beyond compare” 好像不能用

18. 最後分享一下
Patch merge 的至高境界
“Auto Patch Merge”