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

發表迴響