La resiliencia de repositorios Git se ha convertido en una cuestión cada vez más relevante a medida que GitHub pasó de ser un simple lugar para almacenar código a convertirse en una pieza central del desarrollo de software. Para millones de desarrolladores, hoy representa mucho más que un repositorio: es portafolio, sistema de colaboración, espacio de documentación, plataforma de CI/CD, gestor de incidencias, escaparate profesional y, cada vez más, interfaz para trabajar con agentes de inteligencia artificial. Precisamente por eso, sus recientes problemas de disponibilidad merecen una mirada que vaya más allá del típico comentario de “GitHub se cayó”.
Durante 2026, GitHub ha reportado una sucesión inusual de incidentes; sus propios informes registran 2 incidentes en enero, 6 en febrero, 4 en marzo, 10 en abril, 9 en mayo, 6 en junio y 8 en julio, todos relacionados con degradación del servicio; ahora, en agosto se produjeron además nuevos incidentes que afectaron a GitHub Actions, Pages y Copilot. Además, también reconoce que el tráfico está creciendo rápidamente, impulsado en buena medida por los flujos de desarrollo asistidos por IA y por los agentes capaces de generar y ejecutar tareas de programación a una escala mucho mayor, pero hay una distinción fundamental que suele perderse en el debate: GitHub puede fallar sin que Git falle.
Git es un sistema de control de versiones distribuido y cada clon tradicional contiene gran parte de la historia del repositorio y puede servir como punto de recuperación. El riesgo no está necesariamente en Git, sino en haber construido alrededor de Git una enorme capa de servicios centralizados de la que hemos terminado dependiendo, entonces, la pregunta, no debería ser simplemente “¿debemos abandonar GitHub?”, sino una mucho más madura: ¿tenemos una estrategia para seguir trabajando cuando GitHub no esté disponible?
Resiliencia de repositorios Git: cómo proteger tu código
Hay algo casi paradójico en la historia de GitHub. Git nació con una filosofía distribuida. GitHub, en cambio, construyó sobre Git una experiencia centralizada extraordinariamente cómoda; y funcionó. Funcionó tan bien que durante años dejamos de pensar en la diferencia, porque cuando un desarrollador dice: “Mi proyecto está en GitHub” normalmente no quiere decir únicamente que allí existe una copia de los commits, quiere decir que allí están también: los issues, los pull requests, las discusiones, los releases, los workflows, los artefactos, las acciones automatizadas, los secrets, la documentación, los colaboradores, las integraciones, los webhooks, el historial social del proyecto y, en muchos casos, buena parte de su identidad profesional.
Ese ecosistema es precisamente el gran valor de GitHub, y también es su mayor superficie de dependencia. GitHub se convirtió en una especie de sistema operativo social del desarrollo de software, por eso una interrupción ya no significa simplemente que un servidor esté temporalmente fuera de servicio, puede significar que una cadena completa de trabajo se detenga.
GitHub puede fallar sin que Git falle
Aquí conviene un poco de historia, bajar el volumen del dramatismo y subir el de los datos. GitHub ha reconocido públicamente que durante 2026 ha atravesado problemas relevantes de disponibilidad y que está realizando una transformación importante de su infraestructura. En mayo explicó que el tráfico estaba creciendo con rapidez, en gran parte debido a los flujos de desarrollo asistidos por IA y agentes, y señaló que estaba migrando capacidad hacia Azure, separando servicios y eliminando puntos de fallo compartidos.
En junio informó que el tráfico de determinados componentes del monolito en Azure había alcanzado aproximadamente el 45 % en una región de Estados Unidos, mientras la compañía ralentizaba temporalmente esa migración después de un incidente de estabilidad y en julio se registraron ocho incidentes de disponibilidad, entonces, GitHub reconoció que algunos servicios habían sufrido degradaciones y que estaba realizando inversiones estructurales para mejorar la resiliencia, y durante los primeros días de agosto volvió a aparecer un patrón que resulta especialmente interesante, específicamente el 5 de agosto, GitHub Copilot Cloud Agent sufrió una degradación que afectó al 100 % de los nuevos trabajos enviados durante el incidente, debido a un control de rate limiting aplicado de manera más amplia de lo previsto.
Además, el 6 y 7 de agosto, un problema más importante afectó a GitHub Actions; la incidencia involucró runners, colas de ejecución, webhooks, Pages, Copilot y otros servicios relacionados y se informó que algunas ejecuciones no podían iniciarse, otras sufrían retrasos y determinados eventos de push y pull request no fueron procesados automáticamente.
Y hay otro dato que merece mucha atención, porque en julio, uno de los incidentes de GitHub Actions fue provocado por un servicio interno insuficientemente dimensionado en una infraestructura concreta. GitHub indicó que aproximadamente el 2 % de los workflows se retrasaron durante ese episodio y es aquí que aparece una lección clásica de ingeniería: la arquitectura importa más que el logo, porque no hace falta imaginar un ciberataque cinematográfico para que un sistema global tenga problemas. A veces basta con: capacidad insuficiente, una dependencia interna, un límite de tráfico mal configurado, una regresión, una cola que crece demasiado o un servicio que se convierte en cuello de botella y eso es mucho menos espectacular y obvio, muchísimo más real.
¿La IA está “rompiendo” GitHub?
La respuesta responsable es: está aumentando enormemente la presión sobre la plataforma, pero no toda caída puede atribuirse a la IA. GitHub sí afirma que el desarrollo asistido por IA y los flujos agénticos están impulsando un crecimiento acelerado del tráfico y este fenómeno es importante porque cambia la naturaleza de las operaciones; un desarrollador humano tradicional puede producir una cantidad determinada de cambios al día, por su parte, un agente puede: analizar un repositorio, generar cambios, ejecutar pruebas, crear ramas, abrir pull requests, reaccionar a errores, volver a intentar y crear nuevas iteraciones y hacerlo de forma continua, por ende, la diferencia no es solamente cuantitativa, es arquitectónica.
Estamos pasando de un modelo en el que Git era utilizado principalmente por humanos a otro donde humanos y agentes están interactuando con repositorios, APIs, CI/CD y servicios remotos a una escala mucho mayor. GitHub ha descrito precisamente esta transformación como una razón central para rediseñar y escalar su infraestructura. Sin embargo, sería un error convertir esta situación en una narrativa simplista de: “La IA destruyó GitHub.” Los incidentes recientes tienen causas diferentes, por ejemplo, algunos problemas de Copilot fueron provocados por proveedores de modelos externos; otros fueron errores internos; otros estuvieron relacionados con capacidad, runners, servicios o despliegues y la IA no es necesariamente el enemigo; pero si puede serlo, la dependencia sin estrategia.
Backup offline de repositorios Git
Desde esta perspectiva, la resiliencia de repositorios Git no consiste únicamente en conservar una copia del código y esta es probablemente la parte más importante de todo el debate, GitHub no es Git, Git es Git y parece una obviedad, pero llevamos tantos años pronunciándolos juntos que casi olvidamos la diferencia. Por su parte, Git está diseñado como un sistema distribuido. Un repositorio clonado contiene la historia versionada y puede utilizarse como una fuente de recuperación. La documentación oficial de Git explica que, en los sistemas distribuidos, los clientes mantienen copias completas del repositorio, de modo que otros clones pueden utilizarse para reconstruir un repositorio si un servidor falla; de hecho, GitHub recomienda oficialmente realizar copias mediante:
git clone --mirror https://github.com/usuario/repositorio.gitLenguaje del código: PHP (php)Y, explica que este método permite conservar el historial del repositorio. Para repositorios que utilizan Git LFS también recomienda descargar los objetos correspondientes. Esto cambia completamente la conversación, porque no estamos condenados a una única infraestructura, tenemos la tecnología para construir resiliencia desde hace años. Lo que muchas veces nos falta es la disciplina.
Infraestructura reproducible para recuperar repositorios Git
Aquí está, en mi opinión, la discusión profunda, GitHub es excelente y precisamente porque es excelente, hemos permitido que se convierta en imprescindible. Una organización puede depender simultáneamente de GitHub para: código + colaboración + CI/CD + identidad + automatización + distribución + seguridad + documentación, y eso obvio, es cómodo, pero desde el punto de vista de resiliencia, crea concentración.
En ingeniería se suele hablar de single point of failure, un único punto de fallo, pero existe una variante menos evidente: single platform dependency y no significa necesariamente que todo deje de existir cuando esa plataforma falla, significa que una parte crítica de nuestro flujo deja de funcionar y esa diferencia importa muchísimo.
Ahora, imaginemos algo muy sencillo, tu repositorio está perfectamente intacto, no hay pérdida de datos, no hay ataque, no hay corrupción; pero GitHub Actions deja de procesar tus workflows, ¿qué ocurre?, tu pipeline CI/CD se detiene y no haces deploy, no corren las pruebas, no se publican artefactos y menos se procesan determinadas integraciones, no se ejecutan determinadas automatizaciones.
Ahora pensemos en otro escenario, GitHub funciona, pero tu organización pierde acceso temporalmente, el código sigue allí pero tu equipo no puede trabajar de la misma manera; eso demuestra algo importante: disponibilidad no significa únicamente “¿están mis archivos ahí?” también significa: “¿puedo continuar mi trabajo?”
Seguridad: el problema no es solamente la disponibilidad
Existe otra razón todavía más seria para pensar en resiliencia, la seguridad de la cadena de suministro de software; porque, durante 2026 GitHub ha tenido que reforzar protecciones para GitHub Actions debido a ataques de supply chain en los que credenciales comprometidas podrían utilizarse para introducir workflows maliciosos capaces de robar credenciales y facilitar ataques posteriores y este tema cambia por completo la conversación.
Ya no hablamos simplemente de: “¿dónde está mi código?” la pregunta pasa a ser: “¿qué puede hacer alguien si compromete mi repositorio?” porque un repositorio puede tener acceso indirecto a: credenciales cloud, tokens, registros de paquetes, sistemas de despliegue, bases de datos, APIs, infraestructura o secretos de CI/CD y es por eso que, proteger un repositorio no consiste solamente en hacer private el repositorio. Una estrategia razonable debe incorporar:
- Protección de ramas: GitHub permite exigir revisiones, checks de estado, firmas de commits, historial lineal y otras reglas antes de permitir modificaciones en ramas protegidas.
- Secret scanning: los secretos comprometidos (API keys, contraseñas, tokens y credenciales) pueden permanecer en el historial incluso después de eliminarse del código visible. GitHub dispone de mecanismos para detectarlos a lo largo del historial y recomienda rotar inmediatamente las credenciales expuestas.
- Push protection: el objetivo no debería ser descubrir secretos después del desastre, sino evitar que lleguen al repositorio en primer lugar. GitHub incluye push protection dentro de sus herramientas de seguridad.
- Commits firmados: la firma de commits ayuda a establecer una relación verificable entre un cambio y su autor o identidad criptográfica, y GitHub permite exigir commits firmados en ramas protegidas.
¿Debemos abandonar GitHub?
No necesariamente y aquí creo que conviene resistirse a los titulares fáciles, porque GitHub sigue siendo una plataforma extraordinariamente poderosa y su valor no está únicamente en almacenar Git, sino está en la red de personas que la utiliza, en descubrir proyectos, en colaborar, en encontrar documentación, en abrir una issue y recibir ayuda, en descubrir una librería, en contratar, enseñar, construir reputación y en todo ese tejido social que apareció alrededor del código.
Xataka lo resume precisamente al analizar las recientes críticas: GitHub pasó de ser simplemente alojamiento de repositorios a convertirse en una infraestructura social central para el Open Source y esa parte no se reemplaza con un simple git push por eso mi conclusión no sería: “Adiós GitHub.” sería: “hola, estrategia de resiliencia.”
Alternativas descentralizadas a GitHub para proteger tus repositorios
Hablar de “alternativas descentralizadas” como si todas fueran lo mismo sería un error, porque existen diferentes grados de descentralización.
Hay una vieja regla de ingeniería que sigue siendo extraordinariamente útil: no pongas todos los huevos en una sola cesta. Curiosamente, Git nos lo permite, por eso una arquitectura razonable para un proyecto importante podría ser:
┌──────────────────┐
│ Local repository │
│ Git │
└────────┬─────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌────────────┐
│ GitHub │ │ Codeberg │ │ GitLab / │
│ │ │ │ │ Self-hosted│
└──────────┘ └──────────┘ └────────────┘
│ │ │
└─────────────┼─────────────┘
▼
Backup independienteNo significa que todos tengan que ser utilizados exactamente de esa manera, significa que la copia maestra de nuestro trabajo no debería vivir exclusivamente detrás de una interfaz web. Esta estrategia mejora la resiliencia de repositorios Git porque elimina la dependencia de un único punto de almacenamiento y permite recuperar el proyecto desde diferentes fuentes.
Resiliencia una estrategia práctica
Una estrategia de resiliencia de repositorios Git comienza por recuperar una propiedad que Git ya tenía desde su origen: la distribución.
Nivel 1: Conserva tu repositorio local: trabajar únicamente desde la interfaz web de un proveedor es una mala práctica para proyectos importantes. Tu máquina debe mantener una copia Git y no porque GitHub sea malo, sino porque Git funciona precisamente para permitirte trabajar de forma distribuida.
Nivel 2: Mantén un mirror: un mirror permite conservar referencias y la estructura del repositorio más completamente que un simple clon de trabajo, por ejemplo:
git clone --mirror https://github.com/usuario/proyecto.gitLenguaje del código: PHP (php)Después puedes actualizar periódicamente el mirror y almacenar una copia fuera de GitHub; es decir, GitHub documenta explícitamente esta estrategia como método de backup.
Nivel 3: Utiliza un segundo remoto: aquí aparece una solución extremadamente sencilla y poderosa.
git remote add github https://github.com/usuario/proyecto.git
git remote add codeberg https://codeberg.org/usuario/proyecto.gitLenguaje del código: JavaScript (javascript)Y posteriormente:
git push github main
git push codeberg mainAhora una caída de GitHub no significa que tu repositorio haya dejado de existir, porque también puedes establecer un repositorio secundario en GitLab, Forgejo, Gitea o infraestructura propia.
La regla 3–2–1 también tiene sentido para el código
Una vez escuché, una filosofía clásica de backup 3–2–1 que sigue siendo perfectamente válida y también puede formar parte de una estrategia de resiliencia de repositorios Git:
- 3 copias de los datos.
- 2 medios o ubicaciones diferentes.
- 1 copia fuera del entorno principal.
Podríamos adaptarla al desarrollo:
Copia 1 → repositorio local
Copia 2 → GitHub
Copia 3 → Codeberg / GitLab / servidor propio / backupY añadir una capa adicional para los proyectos realmente críticos:
Git
+ backup offline
+ almacenamiento externo
+ documentación de restauración
+ pruebas periódicas de recuperaciónPorque tener un backup que nunca has probado recuperar es una especie de religión tecnológica; crees que funciona, hasta que llega el domingo a las 2:00 a. m.
El código abierto merece algo mejor que otra jaula
El Open Source nació de una cultura basada en: colaboración, transparencia, distribución, libertad, interoperabilidad y comunidad; pero con el tiempo gran parte de ese ecosistema terminó concentrándose dentro de unas pocas plataformas comerciales. Por ejemplo, Codeberg plantea explícitamente este problema: millones de personas producen software y conocimiento abierto mientras buena parte de ese resultado se concentra en plataformas operadas por organizaciones comerciales.
Y esta crítica no significa que GitHub sea “el villano”, más bien demuestra que la comunidad tecnológica consiguió algo extraordinario: construimos un sistema distribuido de creación y después concentramos su plaza pública y tal vez, ahora estemos entrando en una segunda etapa.
¿Qué debería cambiar un desarrollador?
No creo que todos debamos abandonar GitHub mañana, eso sería poco práctico, pero sí creo que cualquier desarrollador debería hacerse cinco preguntas:
- ¿Tengo el repositorio local?: si la respuesta es no, empieza por ahí.
- ¿Tengo una segunda copia independiente?: si la respuesta es no, tienes una oportunidad enorme de mejorar tu resiliencia con poco esfuerzo.
- ¿Puedo reconstruir el proyecto fuera de GitHub?: aquí comienzan las conversaciones verdaderamente interesantes.
- ¿Mis secretos están separados del repositorio?: nunca confundamos código con credenciales.
- ¿He probado realmente mi recuperación?: porque un backup sin una prueba de restauración es simplemente optimismo almacenado.
¿Y las empresas?
Para una organización, la conversación debe subir de nivel y la resiliencia de repositorios Git debería formar parte del plan de continuidad operativa. GitHub puede formar parte de una arquitectura empresarial excelente, pero debería existir un plan de continuidad operativa y ese plan podría contemplar:
GitHub
↓
Mirror automático
↓
Repositorio secundario
↓
Backup independiente
↓
Infraestructura reproducible
↓
Documentación de recuperación
↓
Prueba periódica de Disaster RecoveryY algo todavía más importante: la infraestructura debe ser reproducible, porque guardar el código no sirve de mucho si nadie puede reconstruir el entorno necesario para ejecutar ese código. La resiliencia no es un producto, es una propiedad del sistema.
Conclusión: no necesitamos un “nuevo GitHub”
Quizás la pregunta equivocada sea: “¿cuál será el próximo GitHub?” tal vez la mejor pregunta sea: “¿por qué necesitamos uno solo?” Una Internet resiliente no debería depender de una única plaza. No porque todas las plataformas tengan que competir hasta desaparecer, sino porque la interoperabilidad es una forma de libertad tecnológica.
Para un desarrollador, una estrategia perfectamente razonable podría ser:
TU PROYECTO
│
▼
Git local
│
┌───────────┴───────────┐
▼ ▼
GitHub Plataforma
principal secundaria
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Codeberg GitLab Forgejo
│
▼
Self-hostedLenguaje del código: PHP (php)Y para proyectos donde la soberanía sea crítica:
Git local
+
Mirror externo
+
Backup offline
+
Infraestructura reproducible
+
Documentación
+
Prueba de recuperaciónNo es glamuroso, no genera miles de estrellas y no queda tan bonito en LinkedIn, pero es funcional, y en ingeniería, después de todo, que funcione sigue siendo una característica bastante revolucionaria.
Hay algo que a veces olvidamos quienes vivimos rodeados de tecnología: un repositorio no contiene solamente archivos, contiene decisiones, errores, aprendizajes, horas de trabajo, ideas que todavía no estaban terminadas, soluciones que quizá nadie había intentado antes, pequeñas victorias y también nuestra historia como desarrolladores.
Por eso proteger un repositorio no debería sentirse como una tarea administrativa, sino es una forma de cuidar el trabajo que hemos construido. Git nació con una idea poderosa: el conocimiento versionado no tiene por qué vivir en un único lugar y quizás el momento actual, nos esté recordando algo que nuestra industria aprendió hace mucho y que, como suele ocurrir, volvimos a olvidar porque una plataforma nos hizo la vida demasiado cómoda.
Personalmente, la resiliencia de repositorios Git no consiste en abandonar GitHub porque no creo que necesitemos decirle adiós; más bien, creo que necesitamos recuperar una pequeña parte de la mentalidad que hizo grande a Git: distribuir.
Distribuir las copias, las capacidades, los riesgos, la confianza y, sobre todo, recuperar la capacidad de mover nuestro trabajo, porque la verdadera soberanía tecnológica no consiste en abandonar todas las plataformas, sino consiste en poder decir: “esta plataforma me ayuda, pero mi trabajo no depende completamente de ella;” ninguna plataforma debería convertirse en el único lugar donde existe nuestro trabajo; en otras palabras: la estrategia debería ser la resiliencia de repositorios Git.
