行前說明

倒數三天啦～～
緊接著昨天未完待續的，來看看各分支存在的意義及用途吧

Main

這可是不陌生的分支，預設分支或我會稱之為主幹線，
開發者不會直接commit到這個分支，會在其他分支上進行開發，並且測試完畢無誤，才會合併過來的。主幹線必須是穩定以及隨時可上線，可以說是最終結果或是給客戶的產品版本。

Develop

這個分支，比較像是Main 替身，是所有開發的基礎分支，當要新增功能時，會新增 Feature 分支出去，開發完後再合併回 Develop。（都先給替身，測試無誤最終再給 Main ）

Feature

新增功能，從 Develop 分支切出去，使用 Feature 分支，完成之後會再併回 Develop 分支。由於多人協作開發不同功能，所以會出現很多 Feature 分支也是很理所當然
ex: Feature/canvas , Feature/payment , Feature/question-search...

這裡就會像是，前面文章提到的那種樣子

第8晚 Git 常用指令-上

Release

當所有功能都完整後陸續合併到 Develop在上線提交進入Main前，
我們需要總測試，並開一個Release 分支，而且 Release 開出來，就只能修bug，不能開新功能。
來自網上大大忠言

一旦Release開出來，就只能修bug，不能開新功能。
一旦Release開出來，就只能修bug，不能開新功能。
一旦Release開出來，就只能修bug，不能開新功能。
當然在過程中發現有壞掉有狀況，我們需要的是開分支出去修繕 -> Hotfix

Hotfix

很單純非常單純，保持原則，只處理bug，不新增功能
而且是在main發現錯誤才開出來的！出問題需要修正就是切分支出去，修正後不要忽略，記得也要回給 Develop 分支修正。
如果是Release出問題不需要特地開 Hotfix ，回去 Develop 處理就好

小結

進行專案開發 情境總結
Main , Develop , Feature , Release , Hotfix

1. 從 Main 主幹線切出去處理各自手上功能
2. 很多 Feature 分支是正常的，但完成後要快點合併去 Develop ，不要有流浪的惡習
3. 開發完畢後在正式上線前先從 Develop 切一個 Release 分支，來當作提交前的熱身檢查線
4. 若不幸上線後發生錯誤，立即切一個緊急修繕分支 Hotfix，並且要回給 Develop，（Main 跟 Develop ，必須保持良好狀態無壞掉功能，以免影響後續開發。）

Hmmm第一次協作專案時沒顧慮太多，所以只有分類兩種分支（輕量化？
Feature , Main 當初為了修復還取了 fix/email , fix/canvas這種分支XD
，推出這種法則的大神依照個人經驗，發明了 gitflow 這工作法則。目的是要用簡單的流程解決工作上的問題，真的是甚好甚好。

來自網上大大忠言
自己手上開發的功能，開發測試完就一定要趕快merge回主線，並且結束這個branch。
記住，無論何時，都要讓流浪在外的feature branch越少越好，branch生命週期越短越好。
這件事情對幫助develop的穩定度有莫大的好處。

參考文獻

Kuma老師的軟體工程教室