從我自己的部落格談起：個人專案的版本控制與追蹤心法

---

我們是專案的主人

有別於參與某個團隊或企業的開發，在個人專案上，我們不只是開發者而已，這個軟體或產品要有哪些功能、要做到多進階、各功能間誰要更優先開發，一切都是由我們自己規劃和決定。這樣聽起來似乎沒什麼問題，但如果沒有一個工具來錨定我們最初的目標與功能，就很容易在開發的細節裡迷航，耗費過多心力，導致上線之日遙遙無期。

身為軟體工程師，相信大家都有類似的經驗。例如我想寫一個首頁，好不容易做出了一個介面，接著覺得應該要再加上一些動畫，再來突然發現有個芝麻般小的 bug，使勁全力的想要去解決……繞了一圈回來後，發現首頁還是沒有做完。

我們換個角度想，身為開發者，最痛恨的莫過於需求頻繁變更。那為什麼當我們集「專案經理」與「開發者」於一身時，反而對自己隨意變更需求的行為如此寬容呢？我們在開發時，如果沒有一個明確的目標和界線，很容易就會無限上綱，在開發的過程中，否定已實作的內容，同時又希望疊加新的內容上去，這確實就是一種需求變更了對吧！而且是最討厭的那種。

既然有機會全權控制自己的專案，那我們也別讓自己成為開發者最討厭的 project manager。

專案管理工具其實唾手可得

講到專案管理工具，應該很多人腦中會浮現那個 J 開頭的夢魘。但其實我們不需要那麼複雜的，我們需要的只是一個能紀錄每個功能（以下稱 ticket）的內容、範圍、狀態，並能做一些筆記的工具就好。而 GitHub 或遠端程式碼倉庫像是 GitLab、Gitea，就都有內建專案管理工具。我們甚至不需要自己撰寫那些 workflows，ticket 和 PR 之間就已經有很好的連動了。

以這個部落格網站為例，我在自己架設的 Gitea（基本上與 GitHub 差異不大），透過 Project 追蹤各個 ticket 或是 issue 的狀態。當我在開發的過程中，發現有什麼可以額外加強的部分，我並不會在同一張 ticket 完成，而是會到這邊再開一張 ticket。這樣可以確保我不會忘記我想做的事情，同時能夠專心的完成現在正在做的功能，而不受影響。

搭配 Milestone 與 PR 做版本控制

GitHub 上除了有 project，能將多個 ticket 或 issue 集中在一起管理之外，還能透過 milestone 設定每個版本的目標，在開 ticket 與發 PR 時，將他們跟 milestone 連結在一起。如此一來，在開發時更能夠有一個一個階段的目標，再也不會有以下哀嚎了！

到底做到何時能上線？接下來還能再做什麼？

舉例來說，我在開發前就已經先規劃好，我打算在每一個版本新增哪些功能。如果要完整的開發完所有部落格該有的功能才上線，那我想我在上線前那意志就會被磨耗殆盡了。因此我規劃先將最核心的功能，也就是文章瀏覽實作出來就上線，至於文章搜尋、內容管理後台、SEO……等功能，他們雖然都很重要，但都可以在後續的版本慢慢補上。

再來你可能會問，對於獨立開發的專案，既然只有自己一個人、也沒有人幫忙 review，還有必要發 PR 嗎？我的答案是肯定的。多這一個步驟，就是給自己一個煞車和反思的機會，能有效降低犯錯機率。在寫 PR description 時，可以讓我們再一次檢視自己這次的變更有沒有符合一開始定義的範圍，這也是避免我們又走回隨意變更需求的路。

現在甚至可以串上 LLM 幫忙 review PR 呢！

另一方面，我們也能將 PR 與 ticket 做連結，當我們想回顧某問題該怎麼解時，就能直接回頭去查 PR。而且 PR 也像是資料夾，將過於細碎的 commit 組合起來，透過 squash merge，讓專案的 commit history 不再雜亂不堪。

道理我都懂，但沒時間去做？

很多專案管理方法與流程看起來都會花費額外的時間，但是這只是表象。用機會成本的來看，當我們去遵循這些流程，付出的成本是這些動動手指的時間、整理 PR description 的時間。相反地，如果不去做這些，成本則是開發過程中的不確定性，軟體上線時的範圍不確定、需要花費的時間不確定、最後能不能順利上線可能也不確定。

正式因為時間有限，我們沒辦法承擔太多的不確定。導入這些看似繁瑣的流程，付出的成本是可預期的幾分鐘；而不這樣做的成本，卻是無法估計的開發黑洞。