Growth, 讀書心得, 軟體開發

Pull Request 總是過不了? 10 個小訣竅讓你的 PR 更容易通過!

Pull Request (PR)是Github flow或Gitlab flow開發流程中最常發生的動作!
但發 Pull Request 容易,讓PR通過卻很難!團隊每個成員都有自己的任務,少有人能瞭解其他人任務或是設計架構...
怎麼樣才是好PR?如何讓你的PR更容易通過(approval),進而避免你的PR“臭酸“呢?
分享10個小訣竅,大家一塊來試試!

 

 

怎麼樣才是好的 PR(pull request)?

本文其實只是個讀書小心得
10 個發 PR 的小訣竅其實和寫好程式有 87 成像
  1. 確保每個 PR 小而美
  2. 任務單一化
  3. 程式單行寬度不太可寬 ( 視團隊而定 )
  4. 避免在功能變動的 PR 裡做個人化修改。搭配上述 (1)、(2)
  5. 運作正常,不能有 "在我的電腦是正常" 的情形
  6. 確保所有 Test 通過
  7. 當然,為你的功能加上 Test
  8. 完整的文字說明
  9. 貼心的 PR 內文
  10. 良好的 commit 習慣

 


 

呼應上面的 PR 訣竅
就現實面來講~ 我實際工作時的心得

  1. 〝儘可能〞 切割 PR,也可以分階段 ( phase 1, 2, 3...) 上 PR
  2. 同上,而且小 PR 變動檔案下,隊友幫忙 CodeReview 的意願也高
  3. 團隊 Code Style 的問題
  4. 呼應 (1)、 (2),修改 Code Style 、修正空白、換行這類... 建議另開 PR 處理
  5. 你修改或新增的功能要確保執行正常,至少自己要執行過一次!
  6. 依 Project 本身的測試覆蓋率決定...
  7. Just do it!
  8. 程式即文章,配合 Code Style 去寫程式吧
  9. 什麼是貼心的 PR 呢?很多時候 PR 的內文只會註記改了什麼、加了什麼功能...
    對於其它人來說… 除了通靈、瞎猜之外,很難理解你想做什麼、修改了什麼.
    試著為〝變動〞的功能截圖、紅線劃出重點,提供測試帳號、資料,都能幫助 PR 更快被閱讀、通過!👍
    簡單說;PR 內的文件要簡單扼要的說明 why, what, how,讓 code review 的隊友更能瞭解你想修改的項目和目的.
  10. 不要亂發 commit, 不要亂寫 commit, 不要沒寫 commit,簡單說,就是不要偷懶,善用 git rebase

 


 

bad git commit in the pull request
一個不好的例子; commit message 不夠清楚且 commit 數過多

 
 

引用原文:10 tips for better Pull Requests by Mark Seemann

One Comment

發表迴響