Durante 2026, GitHub ha reportado una sucesi\u00f3n 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<\/strong>, todos relacionados con degradaci\u00f3n del servicio; ahora, en agosto se produjeron adem\u00e1s nuevos incidentes que afectaron a GitHub Actions, Pages y Copilot. Adem\u00e1s, tambi\u00e9n reconoce que el tr\u00e1fico est\u00e1 creciendo r\u00e1pidamente, impulsado en buena medida por los flujos de desarrollo asistidos por IA y por los agentes capaces de generar y ejecutar tareas de programaci\u00f3n a una escala mucho mayor, pero hay una distinci\u00f3n fundamental que suele perderse en el debate: GitHub puede fallar sin que Git falle.<\/em><\/strong><\/p>\n\n\n\n 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\u00f3n. El riesgo no est\u00e1 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\u00eda ser simplemente \u201c\u00bfdebemos abandonar GitHub?\u201d<\/strong>, sino una mucho m\u00e1s madura: \u00bftenemos una estrategia para seguir trabajando cuando GitHub no est\u00e9 disponible?<\/strong><\/p>\n\n\n\n Hay algo casi parad\u00f3jico en la historia de GitHub. Git naci\u00f3 con una filosof\u00eda distribuida. GitHub, en cambio, construy\u00f3 sobre Git una experiencia centralizada extraordinariamente c\u00f3moda; y funcion\u00f3. Funcion\u00f3 tan bien que durante a\u00f1os dejamos de pensar en la diferencia, porque cuando un desarrollador dice: \u201c<\/em>Mi proyecto est\u00e1 en GitHub\u201d<\/em><\/strong> <\/em>normalmente no quiere decir \u00fanicamente que all\u00ed existe una copia de los commits, quiere decir que all\u00ed est\u00e1n tambi\u00e9n: los issues, <\/em>los pull requests, <\/em>las discusiones, los releases, los workflows, los artefactos, las acciones automatizadas, los secrets, la documentaci\u00f3n, los colaboradores, las integraciones, los webhooks, el historial social del proyecto y, en muchos casos, buena parte de su identidad profesional.<\/p>\n\n\n\n Ese ecosistema es precisamente el gran valor de GitHub, y tambi\u00e9n es su mayor superficie de dependencia. GitHub se convirti\u00f3 en una especie de sistema operativo social del desarrollo de software, <\/strong>por eso una interrupci\u00f3n ya no significa simplemente que un servidor est\u00e9 temporalmente fuera de servicio, puede significar que una cadena completa de trabajo se detenga.<\/p>\n\n\n\n Aqu\u00ed conviene un poco de historia, bajar el volumen del dramatismo y subir el de los datos. GitHub ha reconocido p\u00fablicamente que durante 2026 ha atravesado problemas relevantes de disponibilidad y que est\u00e1 realizando una transformaci\u00f3n importante de su infraestructura. En mayo explic\u00f3 que el tr\u00e1fico estaba creciendo con rapidez, en gran parte debido a los flujos de desarrollo asistidos por IA y agentes, y se\u00f1al\u00f3 que estaba migrando capacidad hacia Azure, separando servicios y eliminando puntos de fallo compartidos.<\/p>\n\n\n\n En junio inform\u00f3 que el tr\u00e1fico de determinados componentes del monolito en Azure hab\u00eda alcanzado aproximadamente el 45 % en una regi\u00f3n de Estados Unidos, mientras la compa\u00f1\u00eda ralentizaba temporalmente esa migraci\u00f3n despu\u00e9s de un incidente de estabilidad y en julio se registraron ocho incidentes de disponibilidad, entonces, GitHub reconoci\u00f3 que algunos servicios hab\u00edan sufrido degradaciones y que estaba realizando inversiones estructurales para mejorar la resiliencia, y durante los primeros d\u00edas de agosto volvi\u00f3 a aparecer un patr\u00f3n que resulta especialmente interesante, espec\u00edficamente el 5 de agosto, GitHub Copilot Cloud Agent sufri\u00f3 una degradaci\u00f3n que afect\u00f3 al 100 % de los nuevos trabajos enviados durante el incidente, debido a un control de rate limiting<\/em> aplicado de manera m\u00e1s amplia de lo previsto.<\/p>\n\n\n\n Adem\u00e1s, el 6 y 7 de agosto, un problema m\u00e1s importante afect\u00f3 a GitHub Actions; la incidencia involucr\u00f3 runners, colas de ejecuci\u00f3n, webhooks, Pages, Copilot y otros servicios relacionados y se inform\u00f3 que algunas ejecuciones no pod\u00edan iniciarse, otras sufr\u00edan retrasos y determinados eventos de push<\/em> y pull request<\/em> no fueron procesados autom\u00e1ticamente.<\/p>\n\n\n\n Y hay otro dato que merece mucha atenci\u00f3n, porque en julio, uno de los incidentes de GitHub Actions fue provocado por un servicio interno insuficientemente dimensionado en una infraestructura concreta. GitHub indic\u00f3 que aproximadamente el 2 % de los workflows se retrasaron durante ese episodio y es aqu\u00ed que aparece una lecci\u00f3n cl\u00e1sica de ingenier\u00eda: la arquitectura importa m\u00e1s que el logo, <\/strong>porque no hace falta imaginar un ciberataque cinematogr\u00e1fico para que un sistema global tenga problemas. A veces basta con: capacidad insuficiente, una dependencia interna, un l\u00edmite de tr\u00e1fico mal configurado, una regresi\u00f3n, una cola que crece demasiado o un servicio que se convierte en cuello de botella y eso es mucho menos espectacular y obvio, much\u00edsimo m\u00e1s real.<\/p>\n\n\n\n La respuesta responsable es: est\u00e1 aumentando enormemente la presi\u00f3n sobre la plataforma, pero no toda ca\u00edda puede atribuirse a la IA. <\/em><\/strong>GitHub s\u00ed afirma que el desarrollo asistido por IA y los flujos ag\u00e9nticos<\/a> est\u00e1n impulsando un crecimiento acelerado del tr\u00e1fico y este fen\u00f3meno es importante porque cambia la naturaleza de las operaciones; un desarrollador humano tradicional puede producir una cantidad determinada de cambios al d\u00eda, 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\u00f3nica.<\/p>\n\n\n\n Estamos pasando de un modelo en el que Git era utilizado principalmente por humanos a otro donde humanos y agentes est\u00e1n interactuando con repositorios, APIs, CI\/CD y servicios remotos a una escala mucho mayor<\/strong>. GitHub ha descrito precisamente esta transformaci\u00f3n como una raz\u00f3n central para redise\u00f1ar y escalar su infraestructura. Sin embargo, ser\u00eda un error convertir esta situaci\u00f3n en una narrativa simplista de: \u201cLa IA destruy\u00f3 GitHub.\u201d <\/em>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.<\/strong><\/p>\n\n\n Desde esta perspectiva, la resiliencia de repositorios Git no consiste \u00fanicamente en conservar una copia del c\u00f3digo y esta es probablemente la parte m\u00e1s importante de todo el debate, GitHub no es Git, Git es Git y parece una obviedad, pero llevamos tantos a\u00f1os pronunci\u00e1ndolos juntos que casi olvidamos la diferencia. Por su parte, Git est\u00e1 dise\u00f1ado como un sistema distribuido. Un repositorio clonado contiene la historia versionada y puede utilizarse como una fuente de recuperaci\u00f3n. La documentaci\u00f3n 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:<\/p>\n\n\n Y, explica que este m\u00e9todo permite conservar el historial del repositorio. Para repositorios que utilizan Git LFS tambi\u00e9n recomienda descargar los objetos correspondientes. Esto cambia completamente la conversaci\u00f3n, porque no estamos condenados a una \u00fanica infraestructura, tenemos la tecnolog\u00eda para construir resiliencia desde hace a\u00f1os. <\/strong>Lo que muchas veces nos falta es la disciplina.<\/p>\n\n\n\n Aqu\u00ed est\u00e1, en mi opini\u00f3n, la discusi\u00f3n profunda, GitHub es excelente y precisamente porque es excelente, hemos permitido que se convierta en imprescindible. Una organizaci\u00f3n puede depender simult\u00e1neamente de GitHub para: c\u00f3digo + colaboraci\u00f3n + CI\/CD + identidad + automatizaci\u00f3n + distribuci\u00f3n + seguridad + documentaci\u00f3n, <\/strong>y eso obvio, es c\u00f3modo, pero desde el punto de vista de resiliencia, crea concentraci\u00f3n.<\/p>\n\n\n\n En ingenier\u00eda se suele hablar de single point of failure, <\/em>un \u00fanico punto de fallo, pero existe una variante menos evidente: single platform dependency <\/em><\/strong>y no significa necesariamente que todo deje de existir cuando esa plataforma falla, significa que una parte cr\u00edtica de nuestro flujo deja de funcionar y esa diferencia importa much\u00edsimo.<\/p>\n\n\n\n Ahora, imaginemos algo muy sencillo, tu repositorio est\u00e1 perfectamente intacto, no hay p\u00e9rdida de datos, no hay ataque, no hay corrupci\u00f3n; pero GitHub Actions deja de procesar tus workflows, \u00bfqu\u00e9 ocurre?, <\/em>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.<\/p>\n\n\n\n Ahora pensemos en otro escenario, GitHub funciona, pero tu organizaci\u00f3n pierde acceso temporalmente, el c\u00f3digo sigue all\u00ed pero tu equipo no puede trabajar de la misma manera; eso demuestra algo importante: disponibilidad no significa \u00fanicamente \u201c\u00bfest\u00e1n mis archivos ah\u00ed?\u201d <\/strong>tambi\u00e9n significa: \u201c\u00bfpuedo continuar mi trabajo?\u201d<\/strong><\/p>\n\n\n\n Existe otra raz\u00f3n todav\u00eda m\u00e1s 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<\/em> en los que credenciales comprometidas podr\u00edan utilizarse para introducir workflows maliciosos capaces de robar credenciales y facilitar ataques posteriores y este tema cambia por completo la conversaci\u00f3n.<\/p>\n\n\n\n Ya no hablamos simplemente de: \u201c\u00bfd\u00f3nde est\u00e1 mi c\u00f3digo?\u201d<\/em> la pregunta pasa a ser: \u201c\u00bfqu\u00e9 puede hacer alguien si compromete mi repositorio?\u201d <\/em><\/strong>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<\/em> el repositorio. Una estrategia razonable debe incorporar:<\/p>\n\n\n\n No necesariamente y aqu\u00ed creo que conviene resistirse a los titulares f\u00e1ciles, porque GitHub sigue siendo una plataforma extraordinariamente poderosa y su valor no est\u00e1 \u00fanicamente en almacenar Git, sino est\u00e1 en la red de personas que la utiliza, en descubrir proyectos, en colaborar, en encontrar documentaci\u00f3n, en abrir una issue y recibir ayuda, en descubrir una librer\u00eda, en contratar, ense\u00f1ar, construir reputaci\u00f3n y en todo ese tejido social que apareci\u00f3 alrededor del c\u00f3digo.<\/p>\n\n\n\n Xataka<\/a> lo resume precisamente al analizar las recientes cr\u00edticas: GitHub pas\u00f3 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 Hablar de \u201calternativas descentralizadas\u201d<\/em> como si todas fueran lo mismo ser\u00eda un error, porque existen diferentes grados de descentralizaci\u00f3n.<\/p>\n\n\n Hay una vieja regla de ingenier\u00eda que sigue siendo extraordinariamente \u00fatil: n<\/em>o pongas todos los huevos en una sola cesta. <\/em><\/strong>Curiosamente, Git nos lo permite, por eso una arquitectura razonable para un proyecto importante podr\u00eda ser:<\/p>\n\n\n\n No significa que todos tengan que ser utilizados exactamente de esa manera, significa que la copia maestra de nuestro trabajo no deber\u00eda vivir exclusivamente detr\u00e1s de una interfaz web<\/strong>. Esta estrategia mejora la resiliencia de repositorios Git<\/strong> porque elimina la dependencia de un \u00fanico punto de almacenamiento y permite recuperar el proyecto desde diferentes fuentes.<\/p>\n\n\n\n Una estrategia de resiliencia de repositorios Git<\/strong> comienza por recuperar una propiedad que Git ya ten\u00eda desde su origen: la distribuci\u00f3n.<\/p>\n\n\n\n Nivel 1: Conserva tu repositorio local: <\/em><\/strong>trabajar \u00fanicamente desde la interfaz web de un proveedor es una mala pr\u00e1ctica para proyectos importantes. Tu m\u00e1quina debe mantener una copia Git y no porque GitHub sea malo, sino porque Git funciona precisamente para permitirte trabajar de forma distribuida<\/strong>.<\/p>\n\n\n\n Nivel 2: Mant\u00e9n un mirror: <\/em><\/strong>un mirror permite conservar referencias y la estructura del repositorio m\u00e1s completamente que un simple clon de trabajo, por ejemplo:<\/p>\n\n\n Despu\u00e9s puedes actualizar peri\u00f3dicamente el mirror y almacenar una copia fuera de GitHub; es decir, GitHub documenta expl\u00edcitamente esta estrategia como m\u00e9todo de backup.<\/p>\n\n\n\n Nivel 3: Utiliza un segundo remoto: <\/em><\/strong>aqu\u00ed aparece una soluci\u00f3n extremadamente sencilla y poderosa.<\/p>\n\n\n Y posteriormente:<\/p>\n\n\n Ahora una ca\u00edda de GitHub no significa que tu repositorio haya dejado de existir, porque tambi\u00e9n puedes establecer un repositorio secundario en GitLab, Forgejo, Gitea o infraestructura propia.<\/p>\n\n\n Una vez escuch\u00e9, una filosof\u00eda cl\u00e1sica de backup 3\u20132\u20131<\/strong> que sigue siendo perfectamente v\u00e1lida y tambi\u00e9n puede formar parte de una estrategia de resiliencia de repositorios Git<\/strong>:<\/p>\n\n\n\n Podr\u00edamos adaptarla al desarrollo:<\/p>\n\n\n Y a\u00f1adir una capa adicional para los proyectos realmente cr\u00edticos:<\/p>\n\n\n Porque tener un backup que nunca has probado recuperar es una especie de religi\u00f3n tecnol\u00f3gica; crees que funciona, hasta que llega el domingo a las 2:00 a. m.<\/p>\n\n\n\n El Open Source naci\u00f3 de una cultura basada en: colaboraci\u00f3n, transparencia, distribuci\u00f3n, libertad, interoperabilidad y comunidad; pero con el tiempo gran parte de ese ecosistema termin\u00f3 concentr\u00e1ndose dentro de unas pocas plataformas comerciales. Por ejemplo, Codeberg<\/a> plantea expl\u00edcitamente este problema: millones de personas producen software y conocimiento abierto mientras buena parte de ese resultado se concentra en plataformas operadas por organizaciones comerciales.<\/p>\n\n\n\n Y esta cr\u00edtica no significa que GitHub sea \u201cel villano\u201d, m\u00e1s bien demuestra que la comunidad tecnol\u00f3gica consigui\u00f3 algo extraordinario: construimos un sistema distribuido de creaci\u00f3n y despu\u00e9s concentramos su plaza p\u00fablica <\/strong>y tal vez, ahora estemos entrando en una segunda etapa.<\/p>\n\n\n\n No creo que todos debamos abandonar GitHub ma\u00f1ana, eso ser\u00eda poco pr\u00e1ctico, pero s\u00ed creo que cualquier desarrollador deber\u00eda hacerse cinco preguntas:<\/p>\n\n\n\n Para una organizaci\u00f3n, la conversaci\u00f3n debe subir de nivel y la resiliencia de repositorios Git<\/strong> deber\u00eda formar parte del plan de continuidad operativa. GitHub puede formar parte de una arquitectura empresarial excelente, pero deber\u00eda existir un plan de continuidad operativa <\/strong>y ese plan podr\u00eda contemplar:<\/p>\n\n\n\nResiliencia de repositorios Git: c\u00f3mo proteger tu c\u00f3digo<\/strong><\/h2>\n\n\n\n
GitHub puede fallar sin que Git falle<\/strong><\/h2>\n\n\n\n
\u00bfLa IA est\u00e1 \u201crompiendo\u201d GitHub?<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/1xF_87vBqR4prQ6o545S5mg.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nBackup offline de repositorios Git<\/strong><\/h3>\n\n\n\n
git clone<\/span> --mirror https:\/\/github.com\/usuario\/repositorio.git<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nInfraestructura reproducible para recuperar repositorios Git<\/strong><\/h3>\n\n\n\n
Seguridad: el problema no es solamente la disponibilidad<\/strong><\/h3>\n\n\n\n
\n
\u00bfDebemos abandonar GitHub?<\/strong><\/h2>\n\n\n\n
git push <\/code>por eso mi conclusi\u00f3n no ser\u00eda: \u201cAdi\u00f3s GitHub.\u201d s<\/em><\/strong>er\u00eda: \u201chola, estrategia de resiliencia.\u201d<\/em><\/strong><\/p>\n\n\n\nAlternativas descentralizadas a GitHub para proteger tus repositorios<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/17HhcZ96rbBBj7K1xAGtM5w.png\")
<\/a><\/figure>\n<\/div>\n\n\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2502 Local repository \u2502\n \u2502 Git \u2502\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2502 \u2502 \u2502\n \u25bc \u25bc \u25bc\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2502 GitHub \u2502 \u2502 Codeberg \u2502 \u2502 GitLab \/ \u2502\n \u2502 \u2502 \u2502 \u2502 \u2502 Self-hosted\u2502\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502 \u2502 \u2502\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u25bc\n Backup independiente<\/code><\/pre>\n<\/div>\n\n\n\nResiliencia una estrategia pr\u00e1ctica<\/strong><\/h3>\n\n\n\n
git clone<\/span> --mirror https:\/\/github.com\/usuario\/proyecto.git<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\ngit remote add github https:\/\/github.com\/usuario\/proyecto.git<\/span>\ngit remote add codeberg https:\/\/codeberg.org\/usuario\/proyecto.git<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\ngit push github main\ngit push codeberg main<\/code><\/span><\/pre>\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/1RaIN8jNgBrNI9PBsB4AYlg.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nLa regla 3\u20132\u20131 tambi\u00e9n tiene sentido para el c\u00f3digo<\/em><\/strong><\/h4>\n\n\n\n
\n
Copia 1 \u2192 repositorio local\nCopia 2 \u2192 GitHub\nCopia 3 \u2192 Codeberg \/ GitLab \/ servidor propio \/ backup<\/code><\/span><\/pre>\n\n\nGit\n+ backup offline\n+ almacenamiento externo\n+ documentaci\u00f3n de restauraci\u00f3n\n+ pruebas peri\u00f3dicas de recuperaci\u00f3n<\/code><\/span><\/pre>\n\n\nEl c\u00f3digo abierto merece algo mejor que otra jaula<\/strong><\/h3>\n\n\n\n
\u00bfQu\u00e9 deber\u00eda cambiar un desarrollador?<\/strong><\/h2>\n\n\n\n
\n
\u00bfY las empresas?<\/strong><\/h3>\n\n\n\n
GitHub\n\u2193\nMirror autom\u00e1tico\n\u2193\nRepositorio secundario\n\u2193\nBackup independiente\n\u2193\nInfraestructura reproducible\n\u2193\nDocumentaci\u00f3n de recuperaci\u00f3n\n\u2193\nPrueba peri\u00f3dica de Disaster Recovery<\/code><\/pre>\n<\/div>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/1sJostVYJx1y7bELNZ_hfOA.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n