¿Usando git para el process de aprobación?

Trabajo en un entorno regulado donde los cambios de software requieren aprobaciones específicas por parte de personas o roles específicos. Actualmente, esto está usando git para control de versiones y seguimiento de aprobaciones fuera de git.

Me gustaría ver si hay una forma de hacer aprobaciones en git. Si hay una solución que es github-only (basada en github forking y pull requests de forks, o github code reviews, etc.) también sería interesante.

Los elementos específicos necesarios son:

  • Quien aprobó algo debe ser fácil de descubrir (logging de git) y demostrable, de una manera equivalente a un documento o firma electrónica. La firma con una key de firma de código, por ejemplo, funcionaría.

  • Cada pieza de código puede necesitar ser aprobada por más de una persona (podría haber una list por proyecto, o caso por caso)

  • Es muy conveniente poder aprobar un set de cambios más grande (request de extracción, fusión de twig, etc.) a la vez en lugar de solo una confirmación.

  • Es deseable, pero no esencial, poder evitar algunas acciones (combinar para dominar / hacer una label de lanzamiento, etc.) a less que se cuente con las aprobaciones correctas.

Sé que el git tiene una function firmada, ¿se puede usar esto para lo que describí?

EDITAR Gracias por todas las respuestas … Por la dirección de algunos de ellos, parece que debería aclarar un poco. Mi objective principal es recostackr fácilmente información sobre quién aprobó qué y cuándo (y también información más detallada de las revisiones de códigos), en lugar de aplicar políticas automáticamente (aunque eso también es bueno). En este caso, todos los contribuyentes están dentro de la misma organización y se puede suponer que son confiables y (en general) hacen las cosas correctas. Es solo que el process ahora es manual, muy lento y algo propenso a errores. Para que te hagas una idea: por cada request de extracción, creamos un par de documentos de MS Word y los colocamos en Docusign para firmas …

PullApprove es un service que permite que las requestes de extracción se bloqueen hasta que sean revisadas y aprobadas por las personas relevantes. Solo funciona para repositorys Github, pero parece satisfacer todos sus requisitos. Las aprobaciones de PullApprove se dan dejando un comentario en el hilo de comentarios correspondiente a la request de extracción, por lo que dejará un logging allí.

Puede usar las twigs protegidas de GitHub para lograr parte de esto:

Una twig protegida:

  • No se pueden combinar los cambios hasta que se completen las verificaciones de estado requeridas
  • No se pueden fusionar los cambios hasta que se aprueben las revisiones requeridas

Configúrelos en la configuration del repository bajo sucursales .

Pero no hay una function directa para firmar commits en GitHub, y desafortunadamente, no hay nada que haga cumplir que los commit están firmados.

Según lo que describe, esto suena como un caso de uso para el flujo de trabajo de "dictador y teniente": https://git-scm.com/book/it/v2/distribuido-Git-Distributed-Workflows#Dictator-and-Lieutenants- Flujo de trabajo

Este flujo de trabajo lo utilizan Linus Torvalds (el "dictador") y sus "tenientes" de confianza (los mantenedores del subsistema kernel) para implementar una estructura de proyecto jerárquica. Como se puede imaginar, no es específico de GitHub: se basa exclusivamente en el uso de múltiples githeads del proyecto, cada tenedor mantenido por una persona responsable de él.

Así es cómo funcionaría con sus requisitos:

  • Quien aprobó algo es una cuestión de quién lo tiene en su tenedor. Si lo tienen, eso significa que lo sacaron y, por lo tanto, lo aprobaron.

  • Para aprobaciones múltiples (niveles de la jerarquía), el primer aprobador lo extrae y lo publica en su fork; luego, el siguiente autorizador saca de la horquilla del primer aprobador y lo publica en su propio tenedor; y así.

  • Esta técnica se usa principalmente con requestes de extracción (es decir, twigs), por lo que este punto se cubre automáticamente.

  • Usted, de común acuerdo, 'bendeciría' el repository del dictador como el 'maestro' o el repository canónico y se entendería automáticamente que todo lo que haya aprobado todas las aprobaciones requeridas. El bendito mantenedor de repo solo sacaría del repository de los tenientes y de nadie más, por lo tanto aplicando automáticamente el process de aprobaciones.

Te recomiendo encarecidamente papel y lápiz con las personas (o roles) que tienes en mente; solo haga la asociación mental de que una persona corresponde a una bifurcación del repository.