使用 Issues, PR 模板組織專案工作流
Github Issues, Pull requests 與開發工作流之間的關係
當多個人一起開發一個沒有被完善管理的 Github 專案時,常常會遇到下列場景:「這個 PR 解決了哪些問題呀?問題被紀錄在哪裡啊?」、「功能 A 被修好了,但功能 B 卻冒出了新的 Bug」、「你問的這個問題我已經在修了耶」。在一個沒有完善管理的專案中工作,由於缺乏有效的規劃、控制和溝通,常常在解決問題的過程中製造新的問題。因此多數有經驗的開發者都會在專案創建初期訂定好協作開發的工作流,像是 Issues, PRs 的內容格式、 branch 名稱的命名原則、分支間 merge 的規範等等,讓所有的協作者以相同的規則、風格做工作記錄,可以大大提升團隊合作的效率。
我在前公司實習時,前公司走 Github Flow 的開發流程,以 Issues 紀錄需要被解決的問題,並規定每個 PR 都必須詳細描述提交的變動解決了什麼問題、用什麼方法如何解決、是否經過測試,且必須關聯到待解議題的 issue 編號。即便獨立開發時不需 要考慮協作問題,使用這套工作流依然能幫助我清楚追蹤每個變動的目的是什麼、做了什麼修改、是否經過測試,如果出現問題,可以透過紀錄輕鬆追溯變更歷史,找出問題的根源,因此我自己在開發個人專案時也很喜歡用這樣的方式來管理我的專案。
以下總結獨立開發或團隊開發時使用工作流的好處:
- 清晰的開發紀錄: 透過 Issues 和 PR 的描述,可以清楚追蹤每個變動的目的是什麼、做了什麼修改、是否經過測試,以及與哪些議題相關。
- 易於追蹤: 可以幫助開發者輕鬆追蹤每個問題的狀態和進度,以及哪些 PR 解決了這個問題。
- 易於協作: 團隊開發中,清楚的紀錄可以幫助團隊成員了解彼此的進度,並在必要時提供協助。
- 可追溯性: 如果出現問題,可以透過紀錄輕鬆追溯變更歷史,找出問題的根源。
為何需要 Github Issues, Pull requests 模板?
善用 Github Issues 和 Pull requests 的模板功能,可以幫助你更有效率地組織專案工作流。模板可以提供結構和一致性,幫助你更有效地跟踪問題和程式碼變更請求。它們還可以確保所有參與者都提供所需的信息。