flow
flow 就是開發的流程或計劃，很多年前有人提出 git flow 後來又有 github flow, gitlab flow 等等，
其實不管是什麼樣的開發流程，主要就是可以讓團隊認可並且可以堅持照這個方針去做就是個好流程。
我們這邊不評斷哪個 flow 比較好，能被提出來的相信都有他存在的價值與觀點。
git flow
在之前的文章我們已經提過一些開發的方式，或者說比較安全妥當的開發流程。
這裡介紹一下多年前就被提出來的 git flow 吧。
一個專案需要分成多個分支並且確立每個分支的作用，否則讓大家隨便 commit 整個專案遲早都會亂七八糟的。
根據 git flow 的建議，主要的分支有 master、develop、hotfix、 release 以及 feature 這五種分支。
各種分支負責不同的功能。其中 master 以及 develop 這兩個分支又被稱做長期分支，
因為他們無時無刻都會存在於整個專案當中，其餘的分支是有可能在特定任務結束後被刪除的。
我們習慣把 develop 縮寫為 dev 這樣比較簡潔。
master 分支
主要是⽤來放穩定、隨時可上線的版本。 這個分支的來源只能從別的分支合併過來，例如 release 或 hotfix.
開發者不會直接 commit 到這個分支，也不應該這樣做。 這也是我們之前常提到的主分支或主幹道。
因為是穩定版本，所以通常也會在這個分支上的 commit 上加入版本號標籤(tag)。
Dev 分支
dev 分支主要是所有開發的基礎分支,當要新增功能的時候，所有的 feature 分支都是從這個分支切出去的。
而 feature 分支的功能完成後，也都會合併回來這個 dev 分支。
所以一般說來，經常寫新 code 作業的分支是在 feature 內，寫好後就要併回去 dev 裡，
然後確定沒問題且需要上正式版才從 release 合併 dev 分支做最後測試。
hotfix 分支
當線上產品發生緊急問題的時候，會從 master 分支開一個 hotfix 分支出來進行修復，
hotfix 分支修復完成之後，會合併回 master 分支，也同時會合併一份到 dev 分支去。
所以 hotfix 就是在修 bug 的分支。
如果不併到 dev 分支，等 dev 的功能完成合併到 feature 又合併到 master 去的話，那個 bug 又會再次出現了。
而不從 dev 直接切分支出來修 bug 的原因是 dev 的分支可能還沒測試完或尚在開發中，硬要從這邊切分支出來修 bug 再合併回 master 完全只會造成更大的災難而已。
release 分支
當認為 dev 分支夠成熟了，就可以把 dev 分支合併到 release 分支，
在這邊進行算是上線前的最後測試。 測試完成後， release 分支將會同時合併到 master 以及 dev 這兩個分支上。
master 分支是上線版本，而合併回 dev 分支的目的是因為可能在 release 分支上還會測到並修正一些問題，
所以需要跟 dev 分支同步，免得之後的版本又再度出現同樣的問題。
feature 分支
當要開始新增功能的時候，就是使用 feature 分支的時候了。
feature 分支都是從 dev 分支開出來的，完成之後會再併回 dev 分支。
簡單版
對小系統或只有一兩個人維運的專案來說，上面可能分工分得太細，當然這樣是很保險沒錯，
但小系統這樣分可能意義不大，因為維護的人就那兩個，修 bug 或開發功能測試都是同一個人在做而已，
目前公司的內部系統大概就是四個分支，主分支就不用說了，大家都不應該去動他，就像我們堅持不應該在正式環境寫 code 一樣。
dev 分支用來開發新功能，可能每個人有一個自己的 dev 分支，開發完後測試沒問題就會合併到 master
再次測試沒問題才會推上正式系統。
另外有個修 bug 的 debug 分支，當有問題時會從 master 開這個分支來修 bug,
修好就會合回去 master 如果跟 dev 有關也會合到 dev 去。
最後有個分支 test 是用來測試一些東西的，例如一些小功能，或者一些程式片斷不確定效果的都會在這個分支測試，
所以這個分支是很亂的，他不會去合併別的分支，也通常不會被合併。
結語
各位伙伴，這是 git 系列文章的最後一篇，謝謝大家這三個月來的支持，
很高興可以在百忙之中堅持寫完這一系列的文章，沒想到寫著寫著就寫了 35 篇，用了三個月把 git 再學好一點，
這不是 git 的全部，但常用的指令都已經有所介紹。
原本的想法只是希望自己能更熟悉 git 在工作上能更方便的進行專案，就當作筆記一篇篇放上來，也紀錄了我學習的過程。
希望你們也跟我一樣有所收穫。
