雖然使用了 Git 作為版本管理工具，但每個人對於分支的認知可能不同，故造成每次 commit 到不同分支之後，要合併要回哪個分支可能會有歧義，這時就可參考一些已存在的 Workflow 規範，只要團隊遵守這樣的 branch 的 commit 和 merge 規則，就可以有一致性。每個 Workflow 規範都不太一樣，常見有: Git Flow、GitHub Flow、GitLab flow ，主要都是希望就算 Project 越來越大協作人員越來越多，也能有效管理 Git Branch，那這邊會以 GitHub Flow 為主要說明，但也會筆記分析了解其他不同策略的優缺點。
用 Git 來做版本管理時，偶爾會需要撤銷某些操作，但對於已經推上遠端 Github / Gitlab repository 的程式碼，並且該分支已經有多人協作的時候，如果要修正的話其實有蠻多需要注意的事情呢 ; 再來 Git 是有蠻多功能和一些命令的，有時不常用的話也會忘記或者錯估使用場景。在開始筆記之前先把一些名詞定義好，一般來說 Git 的操作會涉及到幾個區域 ：
- 硬碟區 disk : 檔案存放的一般資料夾，也會被稱為 workspace
- 暫存區 staging : 保存
git add紀錄的地方，也被稱為 index- 本地端 git local : 保存
git commit紀錄的地方，也被稱為 repository- 遠端 git remote :
git push的倉儲，如 Github、Gitlab 等等而各個之間狀態變化的簡單關係如下圖所示 :
現今應用程式發展迅速， app 的更新也變得越來越頻繁，在微服務、DevOps、Cloud-native 的迭代過程中，最終都需要上線。上線就需要部署；需要部署就意味著有修改；修改則意味著有風險，要如何在盡量不影響 user 的前提下，讓 app 升版呢 ? 這時就有一些部屬策略可以考慮。對於 Deployment Strategies 有一些基本的專有名詞和觀念，例如 :
- Recreate
- Rolling
- Blue-Green
- Canary
對於應該使用哪種 Deployment Strategy 、它們的工作原理、優缺點等等，以下會做些基本介紹。
