Repositorio Git corporativo

Desde hace un tiempo me he dado cuenta de una cosa bastante básica, pero que durante años he ido resolviendo «a ojo»: en WordPress acabas acumulando mucho software pequeño. Plugins mínimos, mu-plugins, snippets envueltos en un tema hijo, un «parche» que nació para un cliente y que ahora vive en tres instalaciones… y, cuando quieres acordarte, la pregunta ya no es «¿dónde está el ZIP?», sino «¿cuál era el ZIP bueno?».

Ahí es donde tener un repositorio Git corporativo deja de ser un capricho y se convierte en un hábito sano. En el caso de ROBOTSTXT, con Forgejo: un Git «de casa», con interfaz, permisos, issues, releases y todo lo necesario, pero sin obligarnos a publicar nada en GitHub cuando no toca.

WordPress genera software pequeño… pero crítico

En el día a día, muchas piezas que creamos para WordPress no son «proyectos open source» ni lo van a ser:

Un plugin de 200 líneas que integra un CRM concreto para un cliente.
Un tema hijo que solo existe para un multisite de una marca.
Un mu-plugin que hace una redirección rara por una campaña y luego se queda «por si acaso».
Un mini-plugin de rendimiento para un hosting específico.

Son piezas pequeñas, sí. Pero suelen ser las que más duele perder. Porque no están en Packagist, ni tienen pipeline, ni «equipo de producto». Están en tu carpeta de proyectos, en una copia de seguridad, en un correo, en un Slack… o en la memoria de alguien.

Un Git corporativo pone orden a eso de una forma muy simple: historia, autoría y una URL estable.

Forgejo como «Git de empresa»

Aquí entra el primer motivo de peso: no todo debe ser público.

Muchas de estas piezas:

Tienen lógica específica de negocio.
Incluyen endpoints, estructuras internas o dependencias que no interesa exponer.
Están hechas a medida y forman parte del servicio al cliente.

Pero a la vez hay un matiz importante: el cliente debe poder acceder a su software.

Con un Forgejo corporativo podemos:

Tener repos privados por cliente o por proyecto / organización.
Dar acceso a personas concretas del cliente (lectura o contribución).
Mantener el histórico con tags, ramas y releases.
Documentar mínimamente (README, changelog, instrucciones de despliegue).

Y lo mejor: todo esto sin «inventarnos» un sistema paralelo de almacenamiento. Nada de carpetas compartidas, nada de «te paso el ZIP por Drive».

Historización: el día que agradeces cada commit

La palabra fea aquí es «historización», pero el beneficio es precioso: saber qué cambió, cuándo y por qué.

En plugins de cliente, especialmente, esto te salva en situaciones muy típicas:

Desde la última actualización, el checkout falla.
¿Qué tocamos cuando añadimos el campo nuevo?
Necesito volver a la versión anterior porque el proveedor cambió la API.
Esto antes funcionaba… creo.

Con Git, incluso en proyectos pequeños, tienes:

Un timeline de cambios.
La posibilidad de revertir.
Comparar versiones sin volverte loco.
Un lugar donde dejar notas técnicas que no se pierdan.

Y si encima lo acompañas de releases con un ZIP generado (manual -esto es lo que yo prefiero, la verdad- o automáticamente), ya tienes el círculo cerrado.

Distribución privada

En WordPress hay una tensión curiosa: los plugins suelen instalarse y actualizarse de forma muy «humana» (sube ZIP o dale a actualizar…), pero cuando gestionas varios sitios, eso no escala.

Tener esos plugins en Forgejo permite crear un flujo mucho más razonable:

Repositorio como fuente de verdad.
Releases etiquetadas (v1.2.3, v1.2.4…).
Artefactos (ZIP del plugin/tema) asociados a cada release.
Un canal claro para que el cliente descargue lo que toca.

No es solo comodidad: es reducir riesgo.

Nuestros plugins públicos y Git como sistema de actualización

Aquí está la parte bonita: el Git corporativo no solo sirve para lo privado. También sirve para lo público, especialmente si te interesa controlar el ciclo de vida sin depender de plataformas externas.

En el caso de nuestros plugins públicos de ROBOTSTXT, tenerlos en Forgejo abre una puerta muy práctica:

El repo es el origen del código.
Las releases sirven como «versiones oficiales».
Y podemos usar ese Git como base para un sistema de actualización automática.

Esto, llevado con calma, te permite algo muy WordPress (y muy útil): que el plugin se actualice sin pasar necesariamente por WordPress.org, pero manteniendo un flujo parecido al que el usuario ya entiende.

Además, a nivel interno, te da:

Un único sitio donde vivirán issues, roadmap y cambios.
Separación clara entre «código» y «distribución».
Capacidad de automatizar builds y zips cuando etiquetas una versión.

Lo que cambia de verdad cuando lo adoptas

Lo curioso es que montar Forgejo (o cualquier Git interno) puede parecer «infra», pero el impacto es más cultural que técnico.

Cambia esto:

De «¿dónde está el plugin?» a «está en su repo».
De «creo que era este zip» a «es la release v1.3.2».
De «lo hice yo en su día» a «está documentado y versionado».
De «te lo paso por correo» a «tienes acceso».

Y, sinceramente, reduce discusiones tontas. Que no es poco.

Menos épica, más oficio

No es una revolución. No es «DevOps» con humo. Es oficio: tratar incluso el software pequeño como software.

Forgejo se suele percibir como la opción «más código abierto» porque nació como fork comunitario de Gitea y, desde que es hard fork, prioriza una gobernanza más transparente y orientada a la comunidad. Además, su cambio a licencia GPLv3+ refuerza el enfoque copyleft: si alguien redistribuye versiones modificadas, tiene que mantenerlas abiertas bajo las mismas condiciones, lo que reduce el riesgo de que el ecosistema acabe girando hacia variantes cerradas.

Forgejo nos encaja porque nos permite mantener lo privado en privado, dar acceso a quien toca (incluido el cliente), y a la vez usar el mismo «hogar» para piezas públicas como ROBOTSTXT, con un flujo de releases y actualización que podemos controlar.

Y lo mejor es que, una vez lo tienes, te preguntas por qué has tardado tanto en hacerlo. Yo, al menos, me lo he preguntado más de una vez… unos con más acierto, otros no tanto.