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 成像

確保每個 PR 小而美
任務單一化
程式單行寬度不太可寬 ( 視團隊而定 )
避免在功能變動的 PR 裡做個人化修改。搭配上述 (1)、(2)
運作正常，不能有 “在我的電腦是正常” 的情形
確保所有 Test 通過
當然，為你的功能加上 Test
完整的文字說明
貼心的 PR 內文
良好的 commit 習慣

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

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