簡單的開發 Git Flow

不知道有沒有人遇到過做好的 feature A、B、C 都依序上了測試機，PM 卻說只要把 feature C 先上正式機的情況，這時候如果你的開發分支沒有管理好的話，就會非常 🥺

只有兩條主線

一般來說專案都會有正式跟測試環境，比較常見會分由 master & demo 等等分支來做開發。
假設你的 feature 或 issue 分支都是從 demo 開出來的，做完後又直接 merge 回 demo，那就有極大的機會遇到上面的窘境。

轉換 Base Branch

當然，你可以直接從 master 開 feature 分支來解決這個問題。
或在比較大型的專案，也可以多一個分支 staging 來當作開 branch 的 base，另外跟 PM 爭取多開一個上正式機前的測試環境，方便我們或 PM 測試每次上版的內容。

Branch

通常可以由以下幾個主要的 branch 來做版本控管。

• master / production：正式環境：正式發佈出去的版本。
• staging / stage：上正式機前的測試環境：可以把它當作開分支的基底，基本上內容要跟 master 的內容保持一致。
• demo / develop：測試環境：會包含最多的功能開發以及 bug 修復。

不同的專案，可能還會有 pre-prod 等等更多的分支

開發流程

1. 當 issue 被 assign 過來

可以從 staging 開新的分支： issue/#1、issue/#2，開發完成 merge 進 demo 請 PM 測試。

2. 確定要上正式機

當一個或多個 issue 確定要上到正式機，再將他們合進 staging。

這時候如果有多一個上版前的測試環境就可以請 PM 測試。

3. release 新的版號

如果測試都沒有問題，那就接著 release 新的版號吧！

這時候會產生一個 tag 可以用來當作版控。

git checkout -b release/版號
yarn release

記得也要把 tag 推上遠端喔

4. 發 MR 給 master

可以把 CHANGELOG.md 貼到 MR 的描述裡紀錄這次更版的變動。

5. Merge

完成 merge 之後記得把 release branch 也 merge 回 staging 讓版號也回我們的 branch base

上正式機的 issue branch 也記得可以刪除，讓專案的分支保持乾淨喔

commit

另外，可以養成在 commit message 後面養成 reference 回 issue 的習慣，方便之後的追蹤跟維護喔。