本篇文章只是要探索一下 git 工作流程，這篇文章只會使用 git 有關的內容，因為我對其他版控生態不熟。

我自己在工作上常使用的 git-flow 是 production base，然後有另一大主分枝 staging，然後透過 PR Merge 的方式 commit 到這兩大分枝，由於這一大流程遇到了大規模重構，所以 production 版本跟 staging 相差甚遠，每次發特定功能的 PR 都必須要幫 staging, production 各 merge 一版。

在考慮使用不同的工作流之前，還是得先考慮一些問題:
1. 團隊之後規模是否會變大，如果會，這個流程適用未來嗎?
2. 現在選用的工作流，要是有個工作 commit 錯誤，是否容易恢復或修正?
3. 這個工作流程是否會給團隊帶來任何不必要的負擔?

集中工作流

集中工作流是最常見的工作流，就等於只有一個 branch ，大家都共用這個 branch，如果有 A, B 兩人在工作，則 A 做 git push 之後，如果 B 也要 push，則需要先 pull 下來才能 push，假設兩個人正好都在改同個檔案，則需要先協調讓某個人先 push 上去，另一個人 pull 下來解決衝突。

延伸閱讀還可以參考 rebase [1]。

我在做小型遊戲開發的時候會採用這樣的模式，主要是覺得在 Unity 開發遊戲時，很多時候腳本不同步會造成場景控制的麻煩，倒不如統一，並時常討論 pull 城式下來。

工作流就會像這樣，每次的藍箭頭回去都是 merge。

功能分支工作流

功能分支工作流，是希望每一個功能都能開出分支，分支也會有管理者 (或採用 Code Review)，A, B, C… 很多人都要開發工作，每個人根據自己工作的主題開出一個 branch (這個 branch 要從某個主線開出去) ，最後完成工作後發出 PR 合併請求。

根據自己工作主題開出 branch:

git checkout -b feat/your-feature main

這個意思是基於 main branch 開出一個 feat/your-feature 的分支。

開發工作流就會像這樣，開出很多分枝，最後合併。 (要節省 branch 了話， feat 合併之後就可以把 branch 砍了。)

事實上這就是目前我工作上使用的工作流，雖然現在都是分別 staging, production 分開開發，但是最終是需要讓 staging 合併到 production 的。

假設你的版本跟 develop 現流版本差異太大，可能需要時常拉 merge 才能讓你發 PR 時不需要一次解決一大堆衝突問題，不過這是一個雙面刃，假設你像我一樣需要同時 PR 到 production 跟 staging，staging 的 commit 中如果有某些暫時不可以推送上去的功能，則使用 merge 會造成合併困擾 (則需要用 cherry-pick 處理等，但也要注意此方法會讓你的版控變得很難看)

Gitflow 工作流

Gitflow 工作流是分出主要分支跟開發分支 (現在你有 Main, Develop 兩個分支)，每當要開發一個功能時，就開一個 branch: Feature (功能)，等到功能完成時，發 PR 到 develop 上測試 (而不是直接合併到 main)。

等到累積到一定程度的功能後 (或是有週期性的發布時間) ， 就要進入準備發佈階段，此時會將 develop 分支再開一個分支 release/0.0.1 這樣的名稱出來，然後再合併到主分支。

合併流程就會像上圖，並請參考下圖解釋紅色就是從 develop 分支一路開出 release 再合併到 main:

參考 [2]，gitflow 有 cli 工具可以處理這件事情。

這與上一小節的流程不一樣，例如我的工作上不會特別做 release 分支出來合併到 main 。

Forking 工作流

Forking 工作流，就是讓每個人各自去 Fork Repo 到自己的 Repo 工作，也就是說你的 Repo 其實是獨立的，等到開發完功能再發 PR 上去主專案，這個工作流程正是 GitHub 做其他專案貢獻的方式。

References:
[1] https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow
[2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
[3] https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch01.html
[4] https://www.gitkraken.com/learn/git/git-flow
[5] https://medium.com/i-think-so-i-live/git%E4%B8%8A%E7%9A%84%E4%B8%89%E7%A8%AE%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B-10f4f915167e