GitLab: ¿hay alguna manera de asignar un estado / comentario a una twig?

Estoy planeando usar GitLab para administrar repositorys de Git (principalmente kernels de Linux de varios proveedores de hardware).

Actualmente, estoy usando Gitolite para administrar usuarios en el server de Git y MediaWiki para tener lo que se llama una "tabla de ramificación"; en otras palabras, una tabla donde informan los usuarios únicos:

  • nombre de la sucursal (por ejemplo, xboard-feat-i2c2)
  • mantenedor de twig
  • descripción breve de la sucursal (por ejemplo, "se inició a partir de la versión 2.0.0, twig de function para implementar el controller i2c2 en el hostboard personalizado X")
  • estado de la twig (WIP, testing, listo para combinar, abortado)
  • bifurque información más larga (por ejemplo, "para crear esta twig debe cambiar esto y hacer eso (con respecto a la instrucción pnetworkingeterminada). Actualmente tenemos un problema con esto …" y así sucesivamente). En esta sección también suelo escribir references al banco de testings / suite de testings utilizada para probar este software específico.

El principal problema aquí es que la tabla anterior se crea manualmente y, a veces, los usuarios olvidan agregar twigs o cambiarles el nombre.

Me pregunto si hay un lugar en GitLab (o una herramienta similar) para insert esta información.

Actualmente estoy planificando forzar al usuario a crear un file README (o un BRANCHREADME, para evitar conflictos) en la raíz del repository, como se explica aquí con toda la información requerida, y me pregunto si hay alguna manera de crear una página nueva en Proyecto GitLab para mostrar todas las informaciones README para las diferentes twigs.

Hemos recorrido un largo path desde "poner lo que todos hacen en un file grande que siempre olvidan mantener". Lo que estás haciendo parece networkingundante con un rastreador de problemas y un sistema de request de extracción. GitLab tiene esos, así que vamos a usarlos.

  • Haz un problema para cada tarea.
    • Nombra el problema después de la tarea, algo legible por humanos.
    • Ponga la descripción de la tarea y cualquier otra información en el problema.
    • Asigne el mantenedor de twig al problema.
  • Cree una sucursal para esa tarea usando el número del problema. git branch issue/123
    • Si desea utilizar un esquema de nombres más elegante, ponga el nombre de la sucursal en el problema (lo recomendaría en contra, manténgalo simple).
  • Use el sistema de comentarios de problemas para cualquier discusión sobre la sucursal / tarea.
  • Use tags de problemas para cualquier estado o información de categoría.
  • Cuando esté listo para fusionarse, realice una request de extracción.
    • Siga el process normal de request de extracción.
  • Cuando se fusiona …
    • Eliminar la twig.
    • Cierra el problema

Esto aprovecha la buena integración del rastreador de problemas de GitLab con el código. Los problemas se pueden search, tienen conversaciones adjuntas, se les puede hacer reference en compromisos (y viceversa) y se archivan después de que se cierran. El esquema de nombres de sucursales es simple y permite a los desarrolladores futuros rastrear fácilmente una antigua twig hasta su historial de desarrollo (el nombre de la twig permanece en la fusión después de la eliminación, así que asegúrese de que siempre git merge --no-ff ).

Mi solución a mis propios problemas, después de trabajar todos los días durante un par de años con GitLab para gestionar muchos proyectos, es la siguiente:

  • crear un problema para todo (error, nueva function ecc). Describe el problema / idea y no cómo la estás resolviendo
  • cuando comience a trabajar cree un nuevo MR (esto se puede hacer con el button en el problema). Esto genera una twig de trabajo y el MR (como WIP)
  • explica lo que estás haciendo en el MR
  • una vez que el trabajo esté terminado, elimine la WIP del título y, o bien:
  • fusionar el MR y eliminar la twig
  • o: cierra el MR y elimina la twig si no es útil.

Tenga en count que, incluso si cierra el MR y elimina la sucursal, el compromiso permanecerá allí (incluso si no es accesible "directamente" a través de git), por lo que no perderá nada de su trabajo.

También puede usar el mismo flujo de trabajo cuando "reelabora" una twig: no quiero perderme la implementación original (porque puedo agregar errores / problema durante la repetición) así que: – crear una nueva twig, con un sufijo de revisión ( ej. -v1 , -v2 y así sucesivamente) – cree un nuevo MR para esta twig, anote lo que su revisión / revisión – comente el MR original o el nuevo (en realidad no importa) con una reference al otro MR (para que estén "vinculados"): cierre el MR original y elimine su twig

Esto me permite tener un bajo número de twigs abiertas por proyecto (normalmente están fusionadas o cerradas) pero tengo documentation sobre el trabajo realizado y nunca pierdo ni un solo compromiso.