Infra Git: Gitea como source of truth + remoto de deploy para feadulta.com #13

New Issue

2026-06-28T19:12:49Z

rafa commented

2026-06-28 19:12:49 +00:00

Labels: area:infra

Contexto

Ahora mismo el repo local de trabajo de Feadulta solo tiene un remoto:

origin -> https://farmer.taild3aaf6.ts.net/git/rafa/feadulta.git

El hosting de feadulta.com permite crear un repositorio Git desde el panel. Además, puede haber trabajo paralelo hecho por varios agentes/personas, por ejemplo Codex y Claude Code.

La pregunta real no es tanto como sincronizar dos repositorios en ambos sentidos, sino cual debe ser la fuente de verdad para evitar divergencias y despliegues incoherentes.

Recomendacion

No montar sincronizacion bidireccional Gitea <-> hosting.

Recomiendo este modelo:

Gitea = source of truth
Repo Git del hosting = remoto de deploy/downstream
Produccion nunca se edita a mano ni desde el panel ni por SFTP salvo emergencia excepcional
Todo cambio entra primero en Gitea mediante rama + revision + merge
El despliegue consiste en empujar main de Gitea al remoto del hosting

En otras palabras: no sincronizar dos repos activos, sino tener un repo principal y un repo de despliegue.

Por que esta opcion es la mejor

1. Evita divergencias silenciosas

Si el repo del hosting y el repo de Gitea aceptan commits independientes, tarde o temprano habra:

cambios hechos solo en produccion
ramas que no contienen lo que realmente esta publicado
merges dificiles o imposibles si alguien toca ficheros distintos en cada lado

Eso empeora mucho si ademas trabajais tu, tu hermana y agentes distintos.

2. Encaja bien con trabajo paralelo

Con dos personas o agentes trabajando a la vez, lo correcto es coordinarse en Gitea:

una issue por cambio
una rama por issue
PR o merge request antes de llegar a main

El hosting debe ser solo el destino final del codigo ya integrado.

3. Permite rollback y trazabilidad

Si produccion sale de commits ya presentes en Gitea, cada deploy corresponde a un commit SHA concreto.

Entonces se puede:

saber exactamente que version esta en produccion
revertir con Git
reconstruir el estado si el hosting falla

Arquitectura sugerida

Flujo base

origin sigue siendo Gitea.
Se crea en el hosting un repo Git para despliegue.
En el clon local se añade un segundo remoto, por ejemplo production.
El trabajo diario va siempre contra origin.
Cuando main este listo, se hace deploy con git push production main.

Regla operativa importante

Nunca hacer commits directamente en el repo del hosting.
Nunca usar el hosting como segundo lugar de colaboracion.
Si hay un hotfix urgente en produccion, se hace primero en una rama de Gitea y luego se despliega ese commit.

Coordinacion contigo + tu hermana + agentes

Reglas minimas

Una sola persona o agente por rama.
No compartir una misma rama entre Codex y Claude.
Nombrado de ramas explicito, por ejemplo:
- codex/issue-XX-...
- claude/issue-YY-...
- rafa/issue-ZZ-...
Merge a main solo cuando el cambio este revisado o al menos entendido.

Para cambios que se pisan

Si dos agentes van a tocar la misma zona, por ejemplo plantilla de portada, scripts de importacion o deploy, conviene:

abrir issue separada por alcance
declarar dependencia entre issues
evitar desarrollo paralelo sobre la misma base si no hay necesidad

Opciones concretas de despliegue

Opcion A: repo del hosting como checkout desplegable

Si el panel del hosting crea un repo conectado a un directorio publicado y permite desplegarlo, usarlo como remoto production.

Ventajas:

Simple
Poco mantenimiento

Riesgo:

Depende de como gestione el panel el checkout y los permisos

Opcion B: repo bare en hosting + hook post-receive

Si el hosting lo permite, esta es la opcion mas limpia tecnicamente:

repo bare en servidor
post-receive que hace checkout o export al docroot

Ventajas:

Mas control
Despliegue reproducible
Mejor separacion entre repo y web publicada

Inconveniente:

Requiere mas control del servidor

Recomendacion practica

Si el panel solo ofrece la opcion sencilla: usar Opcion A
Si el hosting permite hooks o un bare repo real: preferir Opcion B

Pero en ambos casos la regla sigue siendo la misma:

Gitea manda
hosting recibe

Configuracion propuesta

Ejemplo conceptual:

git remote add production
git push production main

Y mantener:

origin -> Gitea
production -> hosting

Que evitar

Evitar estas dos ideas:

Mirror bidireccional automatico entre Gitea y hosting.
- Parece comodo, pero complica conflictos y oculta cual es la verdad.
Editar produccion y luego traer cambios de vuelta.
- Eso rompe el flujo y hace que el estado real dependa del servidor, no del repo.

Plan de implementacion sugerido

Crear el repo Git en el hosting desde el panel.
Añadirlo como remoto production al repo local.
Hacer una primera prueba de push desde una copia controlada del repo.
Verificar si el hosting despliega automaticamente o requiere accion manual.
Documentar el comando exacto de deploy en el repo.
Establecer politica de ramas para trabajo paralelo con Codex y Claude.
Opcional: proteger main en Gitea y exigir PR para cambios sensibles.

Criterios de aceptacion

Existe un remoto de deploy separado para produccion.
origin sigue siendo el unico remoto de colaboracion.
Produccion puede reconstruirse desde commits de Gitea.
El flujo de trabajo evita commits manuales en el hosting.
Hay una convencion clara para ramas paralelas de Codex y Claude.

Decision propuesta

Adoptar desde ya este principio:

Gitea es la fuente unica de verdad; el Git del hosting es solo el destino de despliegue.

Si se acepta, el siguiente paso seria abrir una sub-tarea tecnica para:

crear el remoto production
probar el primer deploy
documentar el procedimiento exacto de publicacion

**Labels:** area:infra ## Contexto Ahora mismo el repo local de trabajo de Feadulta solo tiene un remoto: - origin -> https://farmer.taild3aaf6.ts.net/git/rafa/feadulta.git El hosting de feadulta.com permite crear un repositorio Git desde el panel. Además, puede haber trabajo paralelo hecho por varios agentes/personas, por ejemplo Codex y Claude Code. La pregunta real no es tanto como sincronizar dos repositorios en ambos sentidos, sino cual debe ser la fuente de verdad para evitar divergencias y despliegues incoherentes. ## Recomendacion No montar sincronizacion bidireccional Gitea <-> hosting. Recomiendo este modelo: - Gitea = source of truth - Repo Git del hosting = remoto de deploy/downstream - Produccion nunca se edita a mano ni desde el panel ni por SFTP salvo emergencia excepcional - Todo cambio entra primero en Gitea mediante rama + revision + merge - El despliegue consiste en empujar main de Gitea al remoto del hosting En otras palabras: no sincronizar dos repos activos, sino tener un repo principal y un repo de despliegue. ## Por que esta opcion es la mejor ### 1. Evita divergencias silenciosas Si el repo del hosting y el repo de Gitea aceptan commits independientes, tarde o temprano habra: - cambios hechos solo en produccion - ramas que no contienen lo que realmente esta publicado - merges dificiles o imposibles si alguien toca ficheros distintos en cada lado Eso empeora mucho si ademas trabajais tu, tu hermana y agentes distintos. ### 2. Encaja bien con trabajo paralelo Con dos personas o agentes trabajando a la vez, lo correcto es coordinarse en Gitea: - una issue por cambio - una rama por issue - PR o merge request antes de llegar a main El hosting debe ser solo el destino final del codigo ya integrado. ### 3. Permite rollback y trazabilidad Si produccion sale de commits ya presentes en Gitea, cada deploy corresponde a un commit SHA concreto. Entonces se puede: - saber exactamente que version esta en produccion - revertir con Git - reconstruir el estado si el hosting falla ## Arquitectura sugerida ### Flujo base 1. origin sigue siendo Gitea. 2. Se crea en el hosting un repo Git para despliegue. 3. En el clon local se añade un segundo remoto, por ejemplo production. 4. El trabajo diario va siempre contra origin. 5. Cuando main este listo, se hace deploy con git push production main. ### Regla operativa importante - Nunca hacer commits directamente en el repo del hosting. - Nunca usar el hosting como segundo lugar de colaboracion. - Si hay un hotfix urgente en produccion, se hace primero en una rama de Gitea y luego se despliega ese commit. ## Coordinacion contigo + tu hermana + agentes ### Reglas minimas - Una sola persona o agente por rama. - No compartir una misma rama entre Codex y Claude. - Nombrado de ramas explicito, por ejemplo: - codex/issue-XX-... - claude/issue-YY-... - rafa/issue-ZZ-... - Merge a main solo cuando el cambio este revisado o al menos entendido. ### Para cambios que se pisan Si dos agentes van a tocar la misma zona, por ejemplo plantilla de portada, scripts de importacion o deploy, conviene: - abrir issue separada por alcance - declarar dependencia entre issues - evitar desarrollo paralelo sobre la misma base si no hay necesidad ## Opciones concretas de despliegue ### Opcion A: repo del hosting como checkout desplegable Si el panel del hosting crea un repo conectado a un directorio publicado y permite desplegarlo, usarlo como remoto production. Ventajas: - Simple - Poco mantenimiento Riesgo: - Depende de como gestione el panel el checkout y los permisos ### Opcion B: repo bare en hosting + hook post-receive Si el hosting lo permite, esta es la opcion mas limpia tecnicamente: - repo bare en servidor - post-receive que hace checkout o export al docroot Ventajas: - Mas control - Despliegue reproducible - Mejor separacion entre repo y web publicada Inconveniente: - Requiere mas control del servidor ### Recomendacion practica - Si el panel solo ofrece la opcion sencilla: usar Opcion A - Si el hosting permite hooks o un bare repo real: preferir Opcion B Pero en ambos casos la regla sigue siendo la misma: - Gitea manda - hosting recibe ## Configuracion propuesta Ejemplo conceptual: git remote add production <URL-del-repo-del-hosting> git push production main Y mantener: origin -> Gitea production -> hosting ## Que evitar Evitar estas dos ideas: 1. Mirror bidireccional automatico entre Gitea y hosting. - Parece comodo, pero complica conflictos y oculta cual es la verdad. 2. Editar produccion y luego traer cambios de vuelta. - Eso rompe el flujo y hace que el estado real dependa del servidor, no del repo. ## Plan de implementacion sugerido 1. Crear el repo Git en el hosting desde el panel. 2. Añadirlo como remoto production al repo local. 3. Hacer una primera prueba de push desde una copia controlada del repo. 4. Verificar si el hosting despliega automaticamente o requiere accion manual. 5. Documentar el comando exacto de deploy en el repo. 6. Establecer politica de ramas para trabajo paralelo con Codex y Claude. 7. Opcional: proteger main en Gitea y exigir PR para cambios sensibles. ## Criterios de aceptacion - Existe un remoto de deploy separado para produccion. - origin sigue siendo el unico remoto de colaboracion. - Produccion puede reconstruirse desde commits de Gitea. - El flujo de trabajo evita commits manuales en el hosting. - Hay una convencion clara para ramas paralelas de Codex y Claude. ## Decision propuesta Adoptar desde ya este principio: Gitea es la fuente unica de verdad; el Git del hosting es solo el destino de despliegue. Si se acepta, el siguiente paso seria abrir una sub-tarea tecnica para: - crear el remoto production - probar el primer deploy - documentar el procedimiento exacto de publicacion

rafa commented

2026-06-28 19:31:11 +00:00

Resuelto con approach diferente (2026-06-28)

El plan original contemplaba usar el repo Git del hosting de CDMON como remoto de deploy. Finalmente hemos ido por un camino mejor:

Lo que se hizo:

Servidor dedicado Hetzner contratado (i7-7700, 64 GB, 2× NVMe RAID1, FSN1)
Gitea 1.22 desplegado en ese servidor vía Coolify → https://gitea.feadulta.com
Este repo local archivado y migrado íntegramente al nuevo Gitea (código + 145 issues)

El modelo resultante:

gitea.feadulta.com = source of truth (no el Gitea local de Tailscale)
El servidor Hetzner alojará también el WordPress de feadulta cuando se haga el cutover
El deploy será git push desde Gitea al servidor, sin pasar por CDMON

Los principios del issue (Gitea manda, hosting recibe, nunca editar producción directamente) siguen siendo válidos y se aplicarán cuando se monte el pipeline de deploy en el servidor Hetzner.

## Resuelto con approach diferente (2026-06-28) El plan original contemplaba usar el repo Git del hosting de CDMON como remoto de deploy. Finalmente hemos ido por un camino mejor: **Lo que se hizo:** - Servidor dedicado Hetzner contratado (i7-7700, 64 GB, 2× NVMe RAID1, FSN1) - Gitea 1.22 desplegado en ese servidor vía Coolify → **https://gitea.feadulta.com** - Este repo local archivado y migrado íntegramente al nuevo Gitea (código + 145 issues) **El modelo resultante:** - `gitea.feadulta.com` = source of truth (no el Gitea local de Tailscale) - El servidor Hetzner alojará también el WordPress de feadulta cuando se haga el cutover - El deploy será `git push` desde Gitea al servidor, sin pasar por CDMON Los principios del issue (Gitea manda, hosting recibe, nunca editar producción directamente) siguen siendo válidos y se aplicarán cuando se monte el pipeline de deploy en el servidor Hetzner.

rafa closed this issue

2026-06-28 19:31:11 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rafa/feadulta#13