GitRoot

 (gitroot.dev)
2 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • GitRoot es una pequeña forja Git que administra repositorios y permisos de acceso con un único binario, y combina issues, tableros, fusión de ramas e interfaz web mediante plugins independientes
  • Almacena en Git todos los datos como archivos normales, no solo el código sino también issues, solicitudes de fusión y tableros, sin depender de una base de datos separada ni de blobs ocultos
  • Controla los cambios con .gitroot/users.yml y permisos de escritura por rama; solo los usuarios autorizados pueden hacer push a la rama predeterminada, que representa el estado actual del repositorio
  • Actualmente está en versión alfa: admite repositorios, usuarios, plugins, comandos Git por SSH y consulta por HTTP, pero no es apto para uso en producción
  • Antes de la 1.0, se propone implementar actualizaciones, permisos por archivo, comandos Git por HTTP, grupos y subgrupos, y estabilizar la API de plugins; por ahora, contribuir requiere entender Git y el flujo del plugin grafter

Una pequeña forja Git para combinar solo las funciones necesarias

  • GitRoot es una pequeña forja Git que se ejecuta con un solo binario y limita sus funciones básicas a la creación de repositorios y la administración de permisos de acceso por repositorio
  • El resto de las funciones queda a cargo de plugins que pueden instalarse de forma independiente entre sí
    • Crear issues, roadmaps, sprints y milestones
    • Mostrar elementos en forma de tablero
    • Revisar y fusionar ramas, algo que GitRoot llama graft
    • Ofrecer datos del repositorio y varias funciones mediante una interfaz web
  • Como los plugins están completamente separados, es posible usar solo tableros sin interfaz web, y también crear plugins propios con las funciones que el proyecto necesite

Un diseño para adaptar la forja a cada proyecto

  • Partiendo de la idea de que cada proyecto necesita una forma de trabajo distinta, está diseñado para que cada proyecto tenga la libertad de modificar su propia forja
  • El entorno que buscan los desarrolladores es el siguiente
    • Guardar código, issues, pull/merge requests y tableros en un solo repositorio
    • Ofrecer funciones necesarias para la promoción y operación del proyecto, como landing pages, traducciones, sistema de tickets y foros
    • Migrar a otra forja de servidor sin scripts de migración ni pérdida de datos o de visualización de colaboradores
  • En cambio, busca evitar complejidades como las siguientes
    • Tener que abrir el navegador para administrar pull/merge requests o issues
    • Una configuración que muestre primero una lista de archivos y directorios a quien llega por primera vez al proyecto
    • Que la forja decida el significado y el flujo de trabajo de sprints, milestones, epics e historias de usuario
    • Una estructura que obligue a pasar por varios menús para configurar un solo permiso de usuario

Autonomía de instalación y operación

  • Busca una distribución sin dependencias ni base de datos, para que los administradores puedan instalarla y mantenerla fácilmente
  • Los administradores deben poder configurar qué acciones están permitidas para cada usuario, y los usuarios deben poder solicitar directamente la creación y el acceso a proyectos y funciones sin usar email ni chat
  • El objetivo es reducir la carga de las actualizaciones y, al mismo tiempo, no entregar los datos de proyectos y usuarios a terceros ni depender de grandes proveedores que podrían cambiar repentinamente sus políticas de operación
  • Es un proyecto aún no terminado y acepta contribuciones externas

Permisos administrados con archivos normales y ramas

  • En lugar de usar una base de datos o blobs ocultos dentro del árbol de Git, almacena todos los datos en archivos normales junto al código
  • En cada repositorio, .gitroot/users.yml especifica las ubicaciones en las que cada usuario puede escribir, y el control de acceso funciona principalmente mediante restricciones de ramas
    • Al principio, solo el propietario puede acceder a la rama predeterminada
    • Si un usuario sin permiso hace push a la rama predeterminada, GitRoot rechaza el cambio
    • Cualquiera puede crear una rama nueva; el usuario que la creó obtiene permiso de escritura sobre esa rama y los demás usuarios no pueden modificarla
    • Si se modifica .gitroot/users.yml o se fusiona una rama en la que un usuario se agregó a sí mismo, ese usuario también puede hacer push a la rama predeterminada
  • Cualquiera puede leer archivos y modificarlos en local o en una rama nueva, pero para reflejar los cambios en la rama predeterminada, que representa el estado actual del repositorio, se requiere la fusión por parte del propietario
  • La configuración de la propia forja también se administra en el repositorio raíz
    • Cuando se agrega un cambio a .gitroot/repositories.yml en la rama predeterminada del repositorio raíz, o se fusiona ese cambio, se crea el repositorio
    • Se puede consultar el funcionamiento detallado en la documentación

Funciones compatibles en la versión alfa

  • Actualmente está en versión alfa, por lo que puede probarse, pero no debe usarse en producción
  • El alcance admitido es el siguiente
    • Crear y eliminar repositorios
    • Procesar comandos Git mediante SSH
    • Administrar ubicaciones de escritura por usuario a nivel de repositorio y rama
    • Instalar plugins y activarlos por repositorio
    • Ejecutar plugins sobre el árbol de trabajo al instalarlos
    • Ejecutar plugins sobre el diff en cada commit después de la instalación
    • Consultar repositorios mediante HTTP

Plan de desarrollo hasta la 1.0

  • Antes de la versión 1.0, se planea implementar las siguientes funciones
    • Actualizaciones de GitRoot y de plugins
    • Administración de permisos de usuario a nivel de archivo
    • Procesar comandos Git mediante HTTP
    • Administración de repositorios con grupos y subgrupos
    • Estabilización de la API de plugins

Self-hosting y proceso de contribución

  • El sitio web de GitRoot es una instancia de GitRoot que aloja el propio código de GitRoot y opera exclusivamente para el proyecto GitRoot
  • Para probarlo en otros proyectos, hay que seguir la documentación de instalación y uso
  • Como GitRoot en sí también es un repositorio de GitRoot, se puede contribuir de la misma manera; el proceso está en la guía de contribución
  • La instancia actual usa el plugin grafter, que integra parte del código en la rama predeterminada, por lo que antes de contribuir hay que entender cómo funciona
  • Como todos los datos, incluidos código, issues y traducciones, se almacenan en Git, para contribuir actualmente hay que saber usar Git
  • A futuro, el objetivo es permitir que cualquiera participe ejecutando git commit y git push directamente desde el navegador

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 일 전
Comentarios de Lobste.rs
  • GitHub no solo era la forge de Git más grande, sino también la más influyente, y se perciben sus huellas incluso en el diseño de Forgejo y GitLab. Con el declive de GitHub, parece haber más margen para la innovación, ya que podrían surgir diversas forges que se aparten del modelo existente.
    • Gitea en el pasado clonó casi 1:1 el frontend de GitHub, y cuando Forgejo hizo un fork de Gitea heredó esa forma tal cual.
  • Soy la persona que creó GitRoot; si tienen preguntas, pueden hacerlas con confianza.
    • Tengo tres dudas. Me pregunto cuál fue el motivo para commitear el CSS minificado: https://gitroot.dev/worktree/app/…
      La causa de que el ancho de la etiqueta <pre> esté limitado a 720px parece ser display:grid en body; si se desactiva, se ensancha como se esperaría. Además, como la URL no contiene información de un commit específico, es difícil que quien envía el enlace y quien lo recibe vean la misma pantalla. Entiendo que es un proyecto para una necesidad personal, y quería comentarlo como puntos que podrían revisarse.
  • @manland, me pregunto si existe alguna política o guía que permita o prohíba contribuciones hechas con LLM.
    • Por ahora no hay una política aparte. Esto se debe a que, salvo dos contribuidores puntuales, escribí directamente el 99.999% del código.
      Personalmente no uso LLM para programar y estoy en contra, pero si alguien usó un LLM y el parche es lo bastante pequeño, no estoy seguro de si lo rechazaría.
      Como el inglés no es mi lengua materna y me cuesta explicar GitRoot, hay rastros de LLM en la comunicación externa. Antes también pedí ayuda en https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 y https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52, pero no vino nadie.
      Me duele tener que usar LLM, pero decidí usarlos lo mínimo posible en vez de no hacer nada. Si en el futuro se forma una comunidad, me gustaría excluirlos por completo; antes de eso, también creo que podrían desaparecer de forma natural por razones económicas. Tengo en la lista de pendientes muchos textos para explicar la filosofía, la seguridad y el futuro, pero termino dudando en escribirlos porque pienso que, al final, un LLM corregirá las frases, arreglará errores tipográficos o traducirá.
  • Me gustó que se aprovechara TinyGo para compilar plugins de Go a WASM.