Git 學習筆記 - 如何使用 Git 做版本控制

在前端的路途上，因為技術觀念尚不扎實，常常都是先做了再說，因此時常會遇到「咦？這個觀念不是跟我平常在用的 XXX 一樣嗎？」的情況，這次要討論的主題 Git Flow 正是其中之一。

什麼是 Git Flow？

版本控管很重要，你知道，我知道，獨眼龍也知道，但實際上到底該如何執行版本控管？理論觀念不知如何落實到實踐，應該是許多人共同的苦惱吧（至少我是啦）。

先前已經認識 Git Flow 這個詞，只是一直沒有去正視它，最近因緣際會又與開發者朋友聊起，才認真去看了一下這到底是什麼東西。

一看之下才發覺，欸，這不就是我平常在做版控的流程嗎？不過，我做的是簡易版。

我的 Git Flow

在公司裡與我相關的專案，都會盡量導入這套習慣，大致會有下列幾種 Git 分支：

`master`

容許合併：develop
用途：發佈正式版本

`develop`

容許合併：feat/、fix/
用途：用來做整合測試使用

`feat/xxx`

容許合併：無
用途：開發新功能，須從 master 開出分支，開發完後合併進 develop

`fix/xxx`

容許合併：無
用途：修復 issue，因現行產品幾乎沒有發生需要緊急修復的狀況，通常產生 issue 都會安排時程來修復，因此不會直接合併進 master，而是會併入 develop，跟著下一次的版本更新上線

與 Vincent Driessen 的 Git Flow，差別在於 hotfix 的合併規則不同，且沒有一個 release 分支。了解了這些差異後，我認為並不需要特別去修改符合到 Git Flow 規範，畢竟理論規範是一套「理想」的情況，但若一味追求 100% 符合的話，反而會造成時間或資源的浪費。

舉個例子來說，我會使用 UML 做系統分析並製作開發規劃文件，以方便跟同事討論系統的活動流程、使用者行為、類別等，但若我連開發一個小功能都需要畫出完整的 UML 圖，那無異是多此一舉，因為就算不畫得很完整，只要足以溝通，讓開發者都明白要怎麼開發，那不就夠了嗎！

剛剛好就好的人生哲學，套用到專案控管上也是說得通的。

持續精進，追求幸福 coding

目前因時常一人開發，為求盡快上線，commit 就亂打（~~心態糟~~），雖說暫時不會發生問題，但這樣下去只會留下難以查閱的紀錄，不是很好的習慣。

在讀完 Kuma 老師的這篇文章後，非常認同使用 git flow 的目的，就是利用簡單明確的 工作流程，讓專案不管在開發、測試、部署、維護階段都能以最小的代價，在問題發生的前期就解決，也就是一種 風險控制 手段。

開發者會導入一堆有的沒的套件、工作流程，不就是為了培養好習慣，讓開發更順利，生活更幸福嗎？既然如此，持續不斷地改善工作流程，才是讓生活愈來愈美好的關鍵。

參考資料：