git logo from Wikimedia

軟體產品的開發、營運到維護是個失序到有序、複雜到規律的過程。其誕生需要動輒團隊中各種角色：產品經理/營運、UI/UX 設計師、各種工程師、QA 測試人員；還得歷經從需求確認、user story、規格定義、wireframe 設計、prototype 設計、功能開發、反覆測試、正式上線等流程。

而版本控制的完整度、細緻度及嚴謹度，會直接影響維護產品的效能與成本。由於操作型的技術文章已經很多，本篇筆記將聚焦 「如何建立良好的版本控制習慣」。

為何版本控制很重要？

以學生時期的小組報告為例，如果你看到組員報告修改完後長這樣，會做何感想？

鬆散版本控制的後果

如果放到產品開發中，想必會是公司的災難吧！相對而言，若有優異的版本控制，能帶來以下三點好處：

易於長期維護

產品長期營運的過程中，每次的更新升級可能就牽涉許多檔案，就算有良好的程式架構及檔案分工，難免會遇上修改而產生的衝突。此時，若有版本控制的協助：短期而言，能透過快速切換版本，還原問題尚未產生時的環境；長期而論，還能透過版本紀錄來釐清 Bug 產生的原因，已進行全面修復。

促進團隊協作

對於正式營運的網站及軟體，隨意暫停及更新維護可能都是成千上百萬的損失；從成長面來看，產品優化的速度也是競爭力的指標之一。如果能在不影響現有版本穩定運作的前提下，同時進行優化、更新、修錯，想必能大幅提高營運效能。

而版本控制洽能透過「分支 (branch)」和「合併 (merge)」達到上述目的。

掌握產品全貌

閱讀詳細記錄的產品開發史，能夠協助開發者快速掌握產品全貌。對個人而言，能夠鍛鍊扎實的產品思維、累積良好開發習慣、在開放原始碼的業界中也易於傳播。對團隊而言，無論在哪個階段加入，都能快速上手和銜接。

git init 前要做的事

就像航機出發前，機長必定會先確陣航線、方向等無誤後，才會起飛前往目的地。在多數情況，版本控制中最重要的往往是動手開發前的準備。

take off from Unsplash

思考並描繪開發流程

在開始敲鍵盤前，我會先思考專案的開發歷程，並列下所有預計要做的小任務，幫助自己能按部就班、有效地逐一解決問題。

以課程中一個我蠻喜歡又有趣的小專案「幹話產生器」為例，可能就有以下步驟：

1. 用 Express 初始化專案
2. 引入前端框架來組裝頁面
3. 建立生成幹話的演算法
4. 整合演算法和 app 以實踐功能
5. 新增 README.md 文件

嘗試事先撰寫 commit message

完成之後可以嘗試轉換成 commit message。這部分沒有標準答案，我的可能也還有很大的改善空間。主要想表達的是，透過事前的文字演練，在還沒開始寫程式碼前，我們就能大致掌握開發的進度。

1. feat: project init
include Express to buildup server

2. feat: include packages to build pretty UI fast
- Handlebars
- Bootstrap
- Font Awesome

3. feat: build algorithm in generate_nonsense.js
- define tasks for different roles and nonsense phrases
- start generating task and phrase of nonsense for selected role
- return the generated nonsense

4. feat: realize the generateNonsense function in app
- Use generateNonsense() and Body-Parser in app.js
- Show nonsense in view
- Keep the content in form
- Return error message

5. docs: add README.md

git commit 風格標準推薦

我們知道刻意練習的原則之一，就是找卓越大師來模仿，試圖縮小與他們的差距，就能有感地看見自己的進步。以下彙整兩個讓我受益良多的經驗原則。

from Conventional Commits

淬練自經驗的 good commit 原則

1. 用一行空白行分隔標題與內容
2. 限制標題最多只有 50 字元
3. 標題開頭要大寫
4. 標題不以句點結尾
5. 以祈使句撰寫標題
6. 內文每行最多 72 字
7. 用內文解釋 what 以及 why vs. how

原則摘錄自：

• Commit Message Guidelines
• 如何寫一個 Git Commit Message

標準化的 conventional commits

在開頭加上 type：

• feat: 新增/修改功能 (feature)。
• fix: 修補 bug (bug fix)。
• docs: 文件 (documentation)。
• style: 格式 (不影響程式碼運行的變動 white-space, formatting, missing semi colons, etc)。
• refactor: 重構 (既不是新增功能，也不是修補 bug 的程式碼變動)。
• perf: 改善效能 (A code change that improves performance)。
• test: 增加測試 (when adding missing tests)。
• chore: 建構程序或輔助工具的變動 (maintain)。
• revert: 撤銷回覆先前的 commit 例如：revert: type(scope): > - subject (回覆版本：xxxx)。

內容摘錄自：

• Conventional Commits
• Git Commit Message 這樣寫會更好，替專案引入規範與範例

git add . 刻意練習到成為習慣

當我們在個人學習階段時可能對版本控制仍感困惑，這時可以試圖想像一下曾經體驗過的粗糙交接，就算幸運的沒遇過，看到下圖也能明白，如果接手一個職責不明、歷史紀錄缺漏的專案，內心應該也是五味雜陳吧？

冰山一角的交接任務 edit from jwgecko

如果在學習的過程中倍感興奮，證明你很適合走上這條路，那未來我們勢必有機會成為工程師，用未來看現在的自己，是否會發現學會「版本控制」超重要！

接下來就開始搭配圖形介面的 git 軟體，不斷 git add 大量刻意練習吧，以養成習慣為目標前進！

閱讀更多

關於本系列更多內容及導讀，請閱讀作者於 Medium 個人專欄 【無限賽局玩家 Infinite Gamer | Publication – 】 上的文章 《用 JavaScript 打造全端產品的入門學習筆記》系列指南。