許多開發人員常常忽略掉保護 Branch 的重要性，因為平時只依據分支策略或團隊規範，遵循建立分支 > 修改程式 > Pull Request > Merge 流程進行工作，而忽略掉保護 Branch 的重要性。但實際上，建立 Repo 與 Branch 後第一件重要的事情其實是是先設定 policy，才能避免安全威脅與錯誤操作。

Branch 常見的的威脅與風險

1. 植入惡意程式碼
相較於公司內部環境，public repo 因為能接受團隊以外的人提交貢獻 (pull request)，面對植入惡意程式碼風險較高，但還是不得不謹慎。有時候設定必須最少的審核人員同意後才能合併，不僅止於是做 Code Review，也是進一步確保沒有惡意程式的植入。另一方面，若有時間過於長久的 pull request，建議取消後請團隊成員重發。一來是隨著專案不斷的發展，陳舊的修改並不符合現狀，二來多少也能降低植入惡意程式碼的機率。

2. 敏感資料 (密碼、個人資料、驗證資訊、Key...等)
確保敏感資訊不被加入至任何的 Branch，常見許多藉由掃描 public 專案取得資料庫連線資訊或其他敏感資料。除了在 commit code 之前謹慎不要隨意加入敏感資料，在 Action 透過 GitHub Secret Scanning 也能找出敏感資訊，避免外洩，這個後續我們再討論。

3. 不符合分支策略或團隊規範的工作流程
當遭遇到某些特殊的情況，也有可能團隊成員誤按，不小心將重要 Main(Master) Branch 或 Release Branch 任意修改、合併或刪除，這會是一場災難。雖然正常情況下，透過 Git 的機制是可以挽救回來，但因失誤造成的人力、時間成本損失很不值得。所以再建立 Repo 之後，首要的工作其實是設定 Branch Policy。

如何保護你的 Branch

在 Repo 畫面，點選右上角 Settings

點選 Branches，可以看見右邊設定 Default Branch 與 Protection rules，我們點選 右邊 Add Rule

上方可以設定 Branch name pattern (採用fnmatch pattern，參考資料：fnmatch pattern)，符合 pattern 的 branch name 則會啟用下列規範。

正常情況下，我們會設定合併前需要 pull request、最少同意人數、以及 owner 進行 Code review

另外，Require status checks to pass before merging 與 Require signed commits 也是我們常建議的選項。確保通過狀態檢查與要求最新的分支，才能進行合併動作。signed commits 選項也能確保安全，但我們後續再討論。

理所當然，盡可能不要允許 force push 與 delete 特定 branch，避免悲劇發生。

Rule 越多可能造成不便利，但若能避免安全問題與錯誤操作，平實的謹慎是值得的

完成後，點選下方 Create 按鈕，輸入密碼後即生效。

閱讀完此篇文章，你應該對於保護 Branch 有基本的認識 (這也是 DevSecOps 左移安全的一環)。希望讀者也能養成好的習慣，在一個新的專案開始之際，就先做好 rule 設定，並要求團隊成員遵循規則。當開發團隊養成習慣成為開發文化後，即交付的內容就會具有一定的安全性與品質。

若你喜歡的我的文章，歡迎追蹤與分享，謝謝。