4

现在我们有 Codacy 监控 DEV 分支，根据推荐的做法，每当我们做某事时，我们都会创建一个 DEV 的个人分支，处理它，然后重新合并。事情是，如果 Codacy 发现问题，我们有从 DEV 分支出来，修改，然后重新合并。同时，DEV 有这个有缺陷的代码，所以我们必须撤消那个合并，等等等等。如果你惊慌失措，因为海外的家伙很快就会上线！

想到三个可接受的解决方案，可能更多：

  • 配置 Codacy 以在提交后审查受监控分支的所有分支
  • 我们倾向于一致地命名我们的分支，因此可以指定正则表达式
  • 如果存在待处理的 Codacy 问题，配置 GitHub 和/或 Codacy 以防止拉取受监控的分支

这些有可能吗？

4

2 回答 2

3

在 /settings/branches 下，您可以为 DEV 定义“分支保护规则”并根据需要设置 Codacy 状态。在您处理好问题之前，您将无法合并 PR。

于 2019-07-08T10:30:29.887 回答
1

如所讨论，遵循以下方法

您应该DEV通过使其成为受保护的分支来限制任何推送。不允许直接提交，只能通过拉取请求提交才能合并。同样，您可以强制通过密码检查以允许合并

请参阅下面的示例设置

Github 设置

7月12日更新：

很多观点都在评论中澄清了，所以添加这些解释来回答

开发人员 1 -> 提交到 DEV_1 分支 -> 提出拉取请求 #1 以将 DEV_1 合并到 DEV 开发人员 2 -> 提交到 DEV_2 分支 -> 提出拉取请求 #2 以将 DEV_2 合并到 DEV

PR #1 和 PR#2 不能合并，因为我们已经指定密码状态检查必​​须通过。

Codacy 的此状态检查将执行您想要执行的所有测试。一旦 Codacy 测试通过，它将更新 PR 并根据 Codacy 结果的状态启用合并

Codacy 测试不过是提交后检查。Github 不允许预先提交钩子。Gitlab 确实允许您使用 pre-commit 钩子，但在使用 Github 时最好在 PR 上使用 post-commit 钩子

后挂钩

于 2019-07-08T10:57:12.903 回答