使用Git进行批准流程？

Question

我在一家受监管的环境中工作，软件更改需要特定人员或角色的具体签署。目前使用Git进行版本控制，并在Git之外跟踪批准。

我想看看是否有办法在Git中进行批准。如果有仅基于GitHub（基于GitHub的分叉和来自分叉的拉取请求或GitHub代码审查等）的解决方案，那也很有趣。

需要的具体元素是：

谁批准了某个内容应该很容易找到（git log）并且可以证明，以等同于Docusign或电子签名的方式。例如，使用代码签名密钥进行签名将起作用。

每个代码段可能需要由一个以上的人批准（可以有项目级别列表，或者根据情况而定）

能够一次批准较大的更改集（拉取请求、分支合并等）非常理想，而不仅仅是单个提交。

能够防止某些操作（合并到主分支/创建发布标签等）除非有正确的批准，这是理想但不是必需的。

我知道Git有一个signed-off-by功能，这可以用于我所描述的吗？

编辑 感谢所有回答...从某些答案的方向来看，似乎我应该澄清一下。我的目标主要是轻松收集有关谁何时批准了什么的信息（以及来自代码审查的更详细信息），而不是自动执行策略（尽管这也很好）。 在这种情况下，所有贡献者都在同一组织内，并且可以假定受信任并（总体上）做正确的事情。只是现在的过程是手动的，非常缓慢且有些容易出错。 为了给您一个想法：对于每个拉取请求，我们创建几个MS Word文档并将它们放在Docusign中进行签名...

- Alex I

---

也可以看看Bitbucket——它具有许多这些控制功能。 - David Aldridge

@DavidAldridge 谢谢，我会的。如果您愿意，您可以将其发布为答案，并可能提供有关其工作原理的更多详细信息。 - Alex I

Answer 1

PullApprove 是一项服务，允许阻止拉取请求直到相关人员进行审查和批准。它仅适用于 Github 存储库，但似乎满足您的所有要求。PullApprove 批准是通过在相应的拉取请求评论线程中留下评论来给出的，因此它将在那里留下记录。

- rlee827

Answer 2

您可以使用GitHub受保护分支来实现部分功能：

受保护的分支：

• 在所需的状态检查通过之前无法将更改合并到其中
• 在所需的审核已获批准之前无法将更改合并到其中

在存储库设置下的分支中配置它们。

但是，GitHub没有直接签署提交的功能，也没有强制执行提交签名的功能。很抱歉。

- Andrew Marshall

---

自从GitHub允许您仅忽略必需的审查并合并您的拉取请求后，我不确定这种方法是否能通过彻底的审核... - Yawar

有趣的是，它似乎只停止了那个人的拒绝阻止它，仍然需要其他人批准。不过我还没有测试过。 - Andrew Marshall

Answer 3

根据您的描述，这似乎是“独裁者和副手”工作流的一个用例：https://git-scm.com/book/it/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow。实际上，Linus Torvalds（“独裁者”）和他信任的“副手”（内核子系统维护者）使用此工作流来实现分层项目结构。因此，可以想象，它不特定于GitHub - 它纯粹基于使用多个git分支的项目，每个分支由负责其维护的一个人维护。

以下是如何满足您的要求：

- 谁批准某事是谁在其分支中拥有它的问题。如果他们拥有它，那意味着他们拉取了它，因此批准了它。 - 对于多个批准（层次结构的级别），第一个批准者拉取并将其发布到其分支上；然后下一个批准者从第一个批准者的分支上拉取并在自己的分支上发布；以此类推。 - 此技术主要与拉取请求（即分支）一起使用，因此此点自动涵盖。 - 您将通过协议“祝福”独裁者的repo作为“主”或规范的repo，任何在那里的内容都会自动被理解为已通过所有必需的批准。祝福的repo维护者只会从副手的repo中拉取，而不会从其他人的repo中拉取，从而自动执行批准流程。

我强烈建议您与您考虑的人员（或角色）一起用纸笔记录下来；只需进行心理联想，一个人对应一个repo分支。

- Yawar

---

你假设所有的“角色”都是程序员，因此能够使用git和编译软件等。 - Ian Ringrose

Answer 4

我有相同的需求并理解您的用例。我的公司也在受监管的环境（医疗设备）中开发软件。我正在探索实施基于Git的签署流程，用于我们使用Git进行版本控制的文档和源代码。以下是我的计划。需要注意的是，这个工作流只适用于整个仓库，但也许您可以考虑如何根据您的需求调整它以适应单个代码段。

• Firstly all people responsible for approving documents should set up GPG signatures on all of their commits. Ideally everyone in the team should do this. This doesn't meant that team members are "signing off" when they make a commit, just that they are signing every commit they make.
• Keep a CHANGELOG.md file in the root of the repository that follows the conventions listed here: https://keepachangelog.com/en/1.0.0/.
• Before each release is made, the CHANGELOG.md entry for that release is drafted in the Unreleased section.

• In addition to the sections that keepachangelog recommend (Added, Changed, Deprecated etc), add a Signed section. This section should be templated with a list of the individuals that need to sign off on the release and which role they are signing off. For instance:

  ### Signed
  
  | Role           | Team Member      | Signed |
  | :------------- | :----------      | :----- |
  | Product Owner  | Joe Placeholder  |        |
  | Technical Lead | Jane Example     |        |
  ...
  

• Prior to the release, each of the people listed in the Signed section reviews the release and when they are happy, adds their initials to the Signed column. E.g.:

  ### Signed
  | Role           | Team Member      | Signed |
  | :------------- | :----------      | :----- |
  | Product Owner  | Joe Placeholder  |        |
  | Technical Lead | Jane Example     | JE     |
  …
  

• The initials don't really prove anything, but do provide a quick human readable checklist of who has and hasn't signed off on a release. However, the team member who added their initials then commits their changes to CHANGELOG.md with a commit message Sign off release vX.X.X. Because every commit is signed with GPG, their is cryptographic proof that the signatory did actually sign off on the release.

• Once the release has been drafted, reviewed and signed by everyone responsible, the repository admin can then bump the version number and tag the release. Bonus points if the admin also signs the tag using their GPG key.

这就是我们将如何实现这个过程的方式。我还考虑了一些其他的方法：

• 显而易见的方法是使用 Github/Gitlab 的 Pull Requests 和受保护分支来防止合并到主分支或“已发布”分支，除非进行审核。

  • 优点：
    • 开发人员已经了解的工作流程，
    • 像 Github 这样的工具得到良好支持，
    • 当需要多个签名时，像 LGTM 这样的工具可以提供帮助。
  • 缺点：
    • 如果您决定切换 Git 工具，则无法在 Github 或 Gitlab 之外移植。
    • 不可能使用 GPG 密钥进行加密签名，尽管登录 Github 是一种等效的证明形式。
    • 没有清楚地表明某人以什么身份签署（例如：产品负责人），需要额外的工作/注释。这是我所在领域的法规要求。
    • 很难看出谁已经签署和谁没有签署，需要大量上下滚动拉取请求评论。

• 我还考虑过使用 GitHub 的 Releases 工具代替 CHANGELOG.md 记录发布说明和人员签名，但没有办法提供签名证明。也无法在 Github 之外移植。

• 使用 @Yawar 提到的“独裁者和中尉”工作流。这对于开源项目看起来很不错，但在私有存储库中工作时，Github 不允许多个相同存储库的分支。因此，如果您使用 Github 私有存储库，则无法实现。可能可以通过在同一存储库中具有不同“中尉”负责每个分支来实现类似的功能。然后，这些“中尉”通过接受其子团队的拉取请求进入其分支，然后向“独裁者”的分支提交拉取请求进行签名。但是：过去尝试过像 Git Flow 这样的复杂分支工作流程非常难以平稳地实现，因此我非常怀疑是否要实现任何比将所有拉取请求集成到单个 Master 分支更复杂的工作流程。

- jamesking