受保护分支的最佳实践

GitHub Comments

分支保护是一组强大的配置选项的一部分,这些选项使存储库管理员能够通过防止意外删除分支、强制执行代码审查、并且在合并拉取请求之前需要成功的自动检查。

这些选项提供了一种提高代码质量的有效方法,而不会对有效协作造成人为障碍。找到正确的设置组合以达到预期的效果非常重要。

本文将探讨最佳实践,以帮助您在不影响协作的情况下维护健康的代码库。您将了解何时以及如何使用必需的状态检查、分支限制、必需的审查等。

组织的分支保护

对存储库具有写入权限的协作者对其所有文件和历史记录具有完全写入权限。虽然这有利于打开协作之门,但并不总是可取的:例如,协作者可能会意外删除重要分支或通过强制推送不兼容的更改来覆盖其提交历史记录。另一种常见情况是协作者通过添加未经测试的工作来引入错误。

GitHub 提供了许多工具来实现无摩擦的协作,并帮助您保持存储库的良好状态,而不会因不必要的障碍而使您的开发工作流程乱七八糟。

保护这个分支

受保护的分支是一个安全网,旨在保护您的代码免受灾难性行为的影响,而不是特定的人。

您可以选择任何存储库中的任何分支,通过启用此设置,您将确保以下保护措施:

  • 分支不能被意外或故意删除
  • 分支提交历史不能用一组替代更改覆盖(强制推送)

这适用于命令行用户以及 GitHub Web UI。

**请注意:**具有写入权限的协作者将提交推送到受保护分支的顶部,无论是直接还是通过合并拉取请求而没有合并冲突,都不受此设置的影响。这是因为合并拉取请求实际上相当于将其提交推送到目标分支。

启用分支保护以有效防止强制推送,例如以防止重写提交历史。选中页面底部的包括管理员复选框,以将此设置也应用于组织和存储库管理员。

在主分支或任何用于持续协作的分支上启用分支保护。随意跳过旨在最终合并和删除的“进行中”样式分支。

如果有必要强制推送提交到分支,请暂时禁用分支保护。有时这可能是不可避免的:在这种情况下,我们建议采取所有必要的预防措施并通知合作者。

期望分支保护以防止推送不改变提交历史的提交。如果您想禁用直接推送到分支,请改用设置 Require pull request review before merging

分支限制

通过启用选项限制可以推送到此分支的团队或个人并在列表中指定他们的姓名,可以完全限制可以推送到分支的团队或个人。默认情况下,所有被授予存储库写入权限的协作者都能够推送到受保护的分支。通过明确指定允许的协作者,您将缩小可以推送到分支的现有协作者的列表。

何时以及如何使用分支限制

了解使用此选项的含义非常重要,尤其是与其他选项结合使用时。我们来看一个常见的场景:

我想阻止某人将他们的本地更改直接推送到远程分支;同时我不想阻止他们的拉取请求被合并。

限制谁可以推送到此分支旨在排除用户或团队使用任何方法推送到重要分支,包括将他们自己的拉取请求合并到目标分支。正如我们在本文中已经看到的,合并拉取请求实际上与将提交推送到分支相同。通过启用此设置,您可以阻止用户将提交推送到分支,同时仍允许他们打开拉取请求。

这将阻止他们合并自己的拉取请求,并要求只有受限制列表中的人才能继续合并操作。

如果您想明确限制对一组特定协作者的推送权限,请创建一个由存储库维护者组成的“维护者”团队。这允许您简单地将团队添加到列表中,而不必单独输入每个维护者。当您准备好将协作者提升到维护者团队时,维护起来也少了一件事情!

使用此选项作为绕过基于拉取请求的工作流的方法,这些机器人或其他应用程序需要被授予直接推送到分支的权限。

如果您的目标是确保更改需要在协作者合并他们自己的工作之前获得批准,请启用分支限制。在合并之前使用 Require pull request review ,而不是让维护人员不必合并每个单独的 pull request。

合并前需要通过状态检查

如果您使用将构建状态发送回 GitHub(例如 CircleCI、Travis 或 Jenkins)的持续集成系统测试您的代码,在允许合并拉取请求之前,您可以通过要求在分支上传递一个或多个状态检查来避免损坏的代码。

连接到您的存储库的每个 CI 系统都将在此处列出,您可以单独指定所需的系统。

让我们来看看以下内容:

我想防止合并拉取请求,除非所有测试都通过并且没有人应该能够直接推送到 master。

可以通过在 master 上启用分支保护、在合并之前打开 Require status checks to pass 以及根据需要指定执行测试套件的工具来实现上述目的。为避免直接推送,只需在合并前启用“需要拉取请求审查”(更多内容见下文)。

另一个非常常见的请求是:

如果在打开拉取请求后 master 上发生了一些变化,我希望我的 CI 检查再次运行。

通过在合并之前启用要求分支保持最新状态,您可以确保针对目标分支的最新状态运行检查。如果目标分支上的代码在拉取请求打开后发生了更改,则会出现一条消息,指示这些更改需要在合并之前向上游合并到拉取请求分支中。集成更改后,将触发新构建,状态检查将更新以反映最新状态。

使用复选框包括管理员以确保这适用于所有协作者。

在合并之前将必需的检查与需要拉取请求审查结合使用,以实现基于拉取请求的有效协作工作流

需要代码所有者的审查

存储库管理员可以使用的另一个重要工具是需要代码所有者的审查。让我们回顾一下以下情况:

我想确保我们的设计团队审查所有涉及 CSS 文件(例如 *.css)的更改;在合并之前,至少需要一位管理员批准拉取请求。

存储库管理员可以使用 CODEOWNERS文件准确定义需要审核项目的人员和团队。当拉取请求更改任何拥有的文件时,这项新功能会自动根据代码所有者分配审阅者,使用与 .gitignore 文件相同的语法。

使用 CODEOWNERS 文件确保对代码库特定区域的更改始终由最专业的人员进行审核。

结论

在本文中,我们看到了分支保护如何在不妨碍协作的情况下提高团队生产力,同时还为希望执行正确的协作策略以保护其软件开发工作流的存储库和组织管理员提供了极大的灵活性。