經驗分享 -從 patch merge 談起

Kris Wang

當你要處理的事情 規模放大到數倍

你仍然可以用一樣的人力限制跟時間限制來完成

這時我才認為你有一個 " 方法“

否則你只是有個把事情做完的 " 做法 " 罷了

我們從Patch Merge 開始談起

情境

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

你認為你需要多久完成這個工作?

你怎麼知道你不會少 merge code?

你怎麼知道你不會 merge 錯code?

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

所需時間 = issues * (( 尋找 issue 的相關 patch) +

(git cherry-pick) + (conflict resolve) +

(git commit))

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

patch?

做法 1:issue resolve( 包含 re-open 後的patch) 後 , 必須記載所有相關的 commit

id

Risk: 無搜尋時間 : 0

延伸思考 : git 使用者 , 可以用 commit SHA 值當 id 嗎 ?

做法 2: 直接問 issue owner, 要merge 哪幾筆

Risk:owner 也可能漏了 . 或者根本不鳥你

搜尋時間 : 看 issue owner 記憶跟熱情程度

做法 3: 自己用肉眼找

Risk: 不能確認看完幾筆才算掃完 ?(git log 並不是依照 Date 欄位排序 )

或者鬼遮眼

搜尋時間 : 看你精神夠不夠好

做法 4: 匯出 commit log 後 , 用工具搜尋

例如 : (1) git log --since=“2014-03-01” > patch.txt

(2) 用 editer 搜尋 issue number or title

Risk: 如果有人 commit message 亂寫 , 就找不到了

搜尋時間 : 幾分鐘

延伸思考 :commit log 格式規範

Merge 發生 conflict 時 ,怎麼解決 ?

Google 上說 ,自己看著辦

方法 1: 用肉眼看 and 在 editor 上解決

But 你真的看得懂這一片花花綠綠 ?眼花了就 merge 錯囉

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

BTW, “beyond compare”好像不能用

最後分享一下Patch merge的至高境界

“Auto Patch Merge”