#持續整合 #code_review #trunk_based
幫自己的功能寫測試呀,弄壞測試就不給他merge, 綠燈代表沒壞,只是 pull 會 conflict 而已,及早發現 conflict 是好事,如果他更久才發 PR, 是不是換他上來發匿名抱怨了?
—
下面一些朋友在講「你們沒用 branch 嗎?」
唉....說得好像 feature branch 才是解方,但實務上通常是飲鴆止渴。
尤其是他們 push 的頻率看起來這麼低的模樣
...
如果 feature branch 是用到像 陸振恩 他們家的 short-lived feature branch,目的是拿來做 PR/MR code review, 1-2天內 merge,還會記得砍掉,那至少避開大部份問題還滿足了 review 的目的。
如果是怕 conflict 開 branch, 那後面還有一堆佈滿詭雷的路等著你踩了。
—
感謝好友 @陸振恩 的補充
short-lived feature branch:
https://trunkbaseddevelopment.com/#scaled-trunk-based-development
補充 Martin Fowler 文章說明:
https://martinfowler.com/articles/branching-patterns.html#Trunk-basedDevelopment
—
不知道怎麼在 legacy code 上寫測試,就找最專業的來教你就對了:
https://tdd.best/courses/unit-testing-gracefully-with-legacy-code-202104/
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...