GitHub Branch 起手式 - 如何保护你的 Branch

许多开发人员常常忽略掉保护 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 设定，并要求团队成员遵循规则。当开发团队养成习惯成为开发文化後，即交付的内容就会具有一定的安全性与品质。

若你喜欢的我的文章，欢迎追踪与分享，谢谢。