如何保护 GitHub 项目免受未经审查的代码影响并强制推行代码审查文化

在这篇博文中，我将向您展示一种保护 GitHub 仓库免受未经审查代码的随机推送或推送到master/main分支的方法。我坚信通过拉取请求部署功能并进行代码审查是可行的。我不会讨论分支和拉取请求工作流程的好坏，我的观点是，对于一个想要学习的团队来说，拉取请求和代码审查是必不可少的。所以，如果您不同意这篇文章，那么它不适合您，因为它强制所有团队成员使用它。

代码审查是一种依赖于文化的实践。这种文化没有自我，渴望持续学习、分享和团队合作。除了学习代码之外，代码审查还能提升你的沟通软技能，因为你需要清晰、专业地表达，但又不能太过苛刻，这也能体现你是否是一位优秀的导师。

本文将重点介绍通过代码审查实践实现拉取请求的3个步骤：

• 理论上的工作流程
• 设置你的项目
• 创建拉取请求模板

理论上的工作流程

1.在 GitHub 上创建一个新分支master并使用分支的标准命名约定：

• feature/name-of-the-feature
• fix/name-of-the-fix

尝试对每个feature/都执行此操作fix，以避免创建非常大的拉取请求，这将耗费审阅者大量的时间。

2.完成工作后，提交并推送代码到您的feature/fix分支，并创建拉取请求以将该分支合并到master其他分支。

3. 指定专人负责代码审查。这样做的目的是互相学习，确保代码符合所有标准，代码风格得到尊重，当然还要确保代码没有任何 Bug。

4. 如果代码审查人员提出任何问题/建议/修复/更改请求，该人员将在 GitHub 上提交更改请求，并附上清晰的注释，然后流程重新开始。所有注释都必须得到解决，审查人员才能接受拉取请求（无论是更改还是仅回答问题）。

5.代码审查成功后，会将分支合并到master分支中，并自动删除feature/分支。fix

设置你的项目

1.创建CODEOWNERS文件

代码所有者文件定义了负责存储库中代码的个人或团队。当有人打开修改其拥有代码的拉取请求时，代码所有者会被自动请求审核。要使用文件，请在存储库的、或目录中CODEOWNERS创建一个名为 的新文件，该文件位于您想要添加代码所有者的分支中。我是个简单的人，所以我总是把所有内容都放在 中。您可以为不同的分支分配不同的代码所有者。实际上，未经代码所有者批准，任何人都无法批准拉取请求。这将保护开发人员免于尝试合并无人批准的拉取请求。CODEOWNERSrootdocs/.github/root

示例CODEOWNERS文件：

* @marioloncarek

2.管理用户角色

在 GitHub 仓库中，转到Settings选项卡，然后Manage access从左侧菜单中进行选择。在这里，您可以定义哪些用户可以访问您的仓库以及他们的角色。始终至少设置一名管理员，所有其他开发人员都应拥有写入权限。实际上，管理员可以覆盖本文中的所有内容，并使用其权限在主分支上进行更改或强制合并而无需审核。这对于修补程序可能很有帮助。

3.配置分支保护设置

在 GitHub 存储库中，转到Settings选项卡，然后Branches从左侧菜单中进行选择。Branch protection rules单击下方的Add rule。

这将打开分支保护配置。在下面Branch name pattern写下你的主分支名称（可能是master）或你想要保护的任何其他分支。根据下图配置所有选项：

此配置将：

• 合并前需要审查拉取请求
• 需要代码所有者的审查
• 限制谁可以驳回拉取请求评审
• 合并前需要通过状态检查
• 要求分支在合并之前保持最新
• 合并前需要对话解决
• 限制谁可以推送到匹配的分支
• 禁止所有具有推送权限的用户强制推送
• 禁止具有推送权限的用户删除匹配的分支

创建pull_request_template.md文件

当您将拉取请求模板添加到存储库时，项目贡献者将自动在拉取请求正文中看到该模板的内容。

为了使您的拉取请求模板在存储库的根目录中可见，请命名拉取请求模板pull_request_template.md并将其放入root存储库中。

现在，当贡献者创建新的拉取请求时，他们将看到模板，该模板将使拉取请求更加标准化，并且可以通过清单提醒贡献者有关项目重要内容（如标准、代码样式、构建流程等）。

示例pull_request_template.md文件：

## Description

Please include a summary of the change or which issue is fixed.

## Type of change

- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

## Area of change

- [ ] Frontend
- [ ] Backend

## General checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I ran `npm run format`/`yarn format` before commit
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation where needed
- [ ] My changes generate no new warnings
- [ ] I have checked my code and corrected any misspellings
- [ ] I have updated `master` and merged to my branch before submitting pull request
- [ ] My pull request generate no conflicts with `master` branch
- [ ] I requested code review from other team members

## Frontend checklist:

- [ ] I followed guidelines for `HTML`/`LIQUID`, `SCSS`, `JAVASCRIPT` from readme
- [ ] My `Javascript` generate no new console errors  
- [ ] I tested my code cross browsers
- [ ] My slice is pixel perfect for both desktop and mobile according to design
- [ ] I conducted basic QA to assure all features are working
- [ ] I tested responsive for mobile and tablet resolutions

## Backend checklist:

- [ ] I tested admin by manually adding content from zero
- [ ] I followed guidelines for naming admin fields
- [ ] I created easy to use admin experience which is self-explanatory
- [ ] I added description to admin fields in hard-to-understand areas
- [ ] I followed guidelines for naming `php`/`liquid` variables
- [ ] I conducted basic QA to assure all features are working

结论

这三个设置步骤将为代码库提供强有力的保护，防止未经审查的代码被推送或直接推送到主分支。这将迫使团队遵守规则并维护代码审查文化。

强制人们遵守规则并不总是那么容易，但根据文章中给出的建议，您可以快速自动化这些规则，以确保每个人都遵守规则。

您如何看待上述规则？您还有其他建议来改善团队的工作流程吗？