La reconstrucción de Git de GitHub a escala de agentes separa las lecturas del repositorio de la coordinación de escrituras

GitHub está reconstruyendo la arquitectura de almacenamiento que sustenta su servicio Git para adaptarla a un modelo de desarrollo en el que personas, sistemas de CI y agentes de software pueden escribir simultáneamente en los mismos repositorios. La última publicación de ingeniería de la compañía describe un diseño que desplaza los datos persistentes de los repositorios hacia Azure Blob Storage, permite escalar la capacidad de lectura de forma independiente y limita la coordinación de escrituras: pasa del nivel del repositorio a las referencias individuales de Git que realmente necesitan mantener un orden.

Se trata de un cambio de infraestructura importante, pero no de una función nueva que los usuarios puedan activar. GitHub presenta el trabajo como una reconstrucción en curso, realizada mientras la plataforma sigue operativa. Según la publicación posterior, la compañía ya ha trasladado a Azure copias del 99,99999 % de sus repositorios, mientras que los casos límite restantes requieren cambios en el protocolo de escritura. Las publicaciones también informan de mejoras internas de rendimiento, pero no ofrecen suficientes detalles de las pruebas como para interpretar esas cifras como una garantía de capacidad para una empresa concreta o una flota determinada de agentes.

Por eso, para los equipos de plataforma la pregunta inmediata no es si un repositorio será de pronto 35 veces más rápido. La cuestión es cómo diseñar cargas de desarrollo automatizadas que no dependan de convertir cada punto de control en un push, de que todas las ramas compartan la misma referencia muy solicitada ni de que cada trabajo de CI vuelva a clonar los mismos datos una y otra vez.

Qué está cambiando GitHub

La arquitectura existente de GitHub, descrita por la compañía en su serie de ingeniería como Spokes, mantiene copias completas de los repositorios en nodos de almacenamiento y utiliza coordinación basada en quórum para las escrituras. Ese diseño proporciona durabilidad y coherencia, pero acopla varias tareas distintas. El mismo conjunto general de réplicas participa en la durabilidad de las escrituras, atiende las lecturas de Git y ejecuta labores de mantenimiento como la compactación y la recolección de basura.

Ese acoplamiento se vuelve más costoso cuando la actividad aumenta en varias direcciones a la vez. Un agente puede crear commits o puntos de control con mucha más frecuencia que un desarrollador humano. Una flota grande de agentes puede crear numerosas ramas dentro de un repositorio. CI puede multiplicar las lecturas desde la punta de una rama después de cada cambio. Las colas de merge y la automatización de lanzamientos pueden concentrar después las escrituras en un número reducido de referencias.

El rediseño de GitHub sigue dos principios relacionados: coordinar solo lo que deba coordinarse y separar el almacenamiento persistente del procesamiento que atiende las solicitudes.

El primer principio se aplica a la actualización de referencias dentro de un Git push. Un repositorio Git contiene objetos inmutables identificados por su contenido, junto con referencias mutables, como punteros a ramas y etiquetas. La actualización de la referencia es la parte que necesita orden: una vez que un cliente observa un valor más reciente para una referencia, las lecturas posteriores no deberían devolver un valor anterior. Muchas otras operaciones relacionadas con un push —como almacenar objetos, validar la conectividad, analizar secretos y realizar tareas de mantenimiento— pueden ejecutarse de forma concurrente o trasladarse fuera de la ruta estrecha de confirmación.

El segundo principio cambia la forma de utilizar las copias de los repositorios. En lugar de exigir que cada trabajador que atiende lecturas sea también una réplica persistente completa, GitHub describe un modelo en el que Azure Blob Storage actúa como fuente persistente y trabajadores ligeros proporcionan capacidad de lectura en caché. Si un trabajador falla, el resultado se parece más a la pérdida de una caché o de capacidad de cómputo que a la pérdida de la copia autorizada del repositorio. Se pueden añadir trabajadores para absorber picos de lecturas sin sumar automáticamente el mismo coste a cada escritura.

La arquitectura se está introduciendo de forma gradual. Las publicaciones de GitHub describen las réplicas virtuales, los trabajadores respaldados por almacenamiento, la serialización por referencia y el mantenimiento en segundo plano como partes de una migración, no como un único lanzamiento de producto ya terminado.

Por qué las cargas de trabajo con agentes dejaron al descubierto el cuello de botella anterior

El cambio suele presentarse como una historia de «infraestructura de IA», pero la presión subyacente es más concreta: el desarrollo de software con alta concurrencia produce una distribución distinta de las operaciones de Git.

Un desarrollador humano puede trabajar durante varios minutos antes de crear un commit y enviar una rama. Un agente automatizado puede guardar un punto de control después de cada tarea, ejecutar pruebas, revisar archivos y repetir el ciclo. Por tanto, miles de agentes trabajando en un mismo código base pueden generar muchas escrituras, lecturas, intentos de merge y actualizaciones de estado simultáneos. Para que esto sea relevante, los agentes no tienen que ser autónomos en el sentido amplio. Un bucle de programación basado en scripts y conectado a un modelo puede ejercer la misma presión sobre la infraestructura si realiza operaciones frecuentes sobre el repositorio.

GitHub afirma que la actividad mensual de Git creció de 218,2 mil millones de eventos en septiembre de 2025 a 473,3 mil millones en agosto de 2026. La empresa también informa de 7,38 mil millones de commits en septiembre, 3,35 mil millones de pushes mensuales, un crecimiento de casi cuatro veces en los merges de pull requests y 3,26 mil millones de ejecuciones de GitHub Actions durante ese mes. Estas cifras describen la actividad total de la plataforma, no una medición limpia de la actividad causada únicamente por agentes. Incluyen el trabajo habitual de los desarrolladores, CI, automatización y el crecimiento de clientes. Aun así, muestran por qué se está reconsiderando un servicio de repositorios diseñado para un nivel de concurrencia menor.

La presión no se limita a las escrituras. Un repositorio con una gran población de agentes o procesos de CI puede recibir una ráfaga de fetches, clones, consultas de estado y operaciones de pull request después de cada actualización de rama. Si la capacidad de lectura está vinculada a las mismas réplicas completas que participan en el quórum de escritura, escalar las lecturas puede encarecer las escrituras. Si un repositorio necesita muchas réplicas adicionales para absorber un pico de lecturas, esas réplicas pueden aumentar el trabajo de coordinación y mantenimiento aunque el patrón de escritura no haya cambiado.

La reconstrucción busca romper ese bucle de retroalimentación. Los trabajadores de lectura pueden escalar según la demanda, mientras que el estado persistente del repositorio y las actualizaciones ordenadas de las referencias permanecen en una capa separada. Esto no hace que todas las operaciones de Git sean baratas ni elimina la necesidad de mantener la consistencia. Cambia el punto en el que el sistema consume su presupuesto de coordinación.

La coordinación por referencia es el detalle de diseño importante

El detalle técnico más útil de la explicación más reciente de GitHub es el paso de una coordinación para todo el repositorio a una serialización por referencia.

Con un bloqueo para todo el repositorio o una ruta de escritura serializada equivalente, dos pushes pueden interferir aunque actualicen ramas no relacionadas. Un push a feature/alice espera detrás de un push a feature/bob porque el repositorio es la unidad en la que el sistema coordina la actualización. Este enfoque es sencillo de entender, pero su rendimiento está limitado por la réplica más lenta, los viajes de ida y vuelta de red necesarios para alcanzar el quórum y la cantidad de escrituras que pueden atravesar la cola compartida.

La serialización por referencia reduce el ámbito del conflicto. Las actualizaciones de una misma rama aún deben ordenarse. Dos force-pushes a la misma referencia no pueden tratarse como independientes porque su estado final depende del orden y de las políticas aplicadas. En cambio, las actualizaciones de ramas distintas pueden avanzar en paralelo si no infringen las reglas de consistencia de Git ni la gobernanza del repositorio.

GitHub afirma que las pruebas internas del nuevo enfoque mostraron que las escrituras en referencias distintas alcanzaban aproximadamente entre tres y cuatro veces más rendimiento, con menor latencia, en el escenario de migración descrito por la empresa. El resultado es más específico que la cifra general de «hasta 35 veces más rendimiento de escritura» citada en la publicación anterior sobre la arquitectura, pero ambas cifras siguen siendo mediciones internas. El material publicado no especifica lo suficiente sobre el tamaño del repositorio, la concurrencia, la combinación de cargas de trabajo, el hardware de referencia, los percentiles de latencia ni el despliegue en producción como para que un equipo externo pueda convertirlas directamente en una fórmula de dimensionamiento.

Esta diferencia importa para la planificación de ingeniería. Un repositorio con miles de ramas independientes y de corta duración puede beneficiarse de una menor contención. Una carga de trabajo en la que miles de trabajadores actualizan una única rama compartida, una única etiqueta de lanzamiento o una única cola de merge sigue teniendo una referencia caliente. La coordinación por referencia limita la contención entre operaciones no relacionadas; no convierte un único flujo ordenado en algo paralelizable de forma infinita.

Almacenamiento persistente y escalado de lecturas

El modelo de objetos direccionados por contenido de Git ofrece la posibilidad de separar los datos inmutables del estado mutable de las referencias. Una vez almacenado y validado un objeto, su identidad se deriva de su contenido. La parte cambiante del repositorio es comparativamente pequeña: las referencias se mueven y el sistema debe garantizar que los clientes vean un orden coherente con esos movimientos.

GitHub describe Azure Blob Storage como la capa duradera para los datos de los repositorios e introduce una réplica de escritura virtual que transmite las escrituras entrantes al almacenamiento de objetos. La escritura no se confirma hasta que los datos son duraderos en esa capa. Después, unas réplicas de lectura ligeras pueden calentar las cachés desde el almacenamiento de objetos y atender el tráfico de lectura sin incorporarse al quórum de escritura de la misma manera que una réplica duradera completa.

El beneficio no consiste simplemente en que «el almacenamiento en la nube es más rápido». El almacenamiento de objetos y la capacidad de cómputo que atiende las solicitudes pueden aprovisionarse y recuperarse de forma distinta. Se puede añadir un trabajador de lectura cuando una versión, una distribución de CI o una flota de agentes genera demanda. Si falla un trabajador de lectura, puede sustituirse y volver a llenar su caché. El mantenimiento del almacenamiento puede realizarse mediante trabajadores separados, en lugar de competir directamente con las descargas y los envíos activos en las mismas máquinas.

Hay contrapartidas. Un trabajador de lectura recién creado puede empezar con la caché vacía. La reconciliación desde el almacenamiento duradero debe ser correcta ante actualizaciones simultáneas. Algunas lecturas pueden necesitar un estado de referencias más reciente que otras, por lo que la sincronización en segundo plano por sí sola podría no ser suficiente. GitHub afirma que los pasos posteriores trasladarán más reconciliación a la ruta de solicitud, de modo que una réplica pueda obtener el estado de referencia y los datos que hayan cambiado desde la última vez que se puso al día.

Esto significa que la arquitectura desplaza el problema en lugar de eliminarlo. En vez de pedir a cada réplica completa que participe en todas las operaciones, el sistema debe gestionar la frescura de las cachés, el estado duradero de las referencias, la recuperación, la compactación y los límites entre la atención de solicitudes y el mantenimiento. El diseño resulta atractivo porque esas responsabilidades pueden escalarse de forma independiente, pero la independencia también exige reglas de consistencia explícitas y una observabilidad sólida.

La cifra de «35 veces» requiere una lectura cuidadosa

La publicación anterior de GitHub afirma que la arquitectura reconstruida ha alcanzado hasta 35 veces más rendimiento de escritura en pruebas internas. Es una señal útil sobre la dirección del trabajo, pero no constituye una promesa de que el repositorio de un cliente vaya a experimentar una mejora de 35 veces.

La publicación pública no describe la configuración de la prueba con suficiente detalle para determinar dónde se aplica la cifra. No indica el tamaño del repositorio, el número de referencias, el nivel de concurrencia, la distribución de las escrituras, la proporción entre lecturas y escrituras, el sistema de referencia, la distribución de latencias, las condiciones de fallo ni si la prueba reproduce tráfico de producción. Tampoco afirma que todos los repositorios hayan migrado a la nueva ruta ni que la medición represente un límite de servicio disponible de forma general.

La misma cautela se aplica a las estadísticas de actividad de la empresa. El rápido crecimiento de los envíos y las confirmaciones demuestra la presión sobre la plataforma, pero no prueba que los agentes hayan causado todo el aumento. Tampoco muestra que un mayor número de operaciones de Git produzca proporcionalmente más software útil. Un número elevado de puntos de control automatizados puede representar trabajo paralelo productivo, cambios innecesarios, reintentos repetidos o una combinación de los tres.

La conclusión operativa es sencilla: no dimensione una plataforma de agentes multiplicando la concurrencia actual por la cifra destacada de la prueba. Considere la prueba como evidencia de que GitHub está abordando un cuello de botella estructural y mida después su propia carga mediante la latencia de los envíos, los envíos rechazados o reintentados, los límites de frecuencia de la API, el tiempo en cola, la distribución de CI y el tiempo hasta la fusión.

Qué significa esto ahora para los equipos de ingeniería

Los usuarios no necesitan reescribir sus flujos de trabajo habituales de Git debido al anuncio. El objetivo declarado de GitHub es conservar las ramas, las revisiones, las fusiones, el historial, la protección de ramas, las revisiones obligatorias, los registros de auditoría, la visibilidad de los repositorios y otros controles mientras cambia el backend que los sirve.

Aun así, los equipos que ejecutan automatización de gran volumen deberían revisar el diseño de sus cargas de trabajo. La revisión resulta útil incluso si la migración de GitHub termina eliminando buena parte de la presión actual, porque reduce el trabajo desperdiciado y facilita la recuperación ante fallos.

Reduzca la frecuencia innecesaria de los envíos

Un agente no necesita enviar cada punto de control intermedio a una rama remota compartida. Mantenga los puntos de control locales durante una tarea siempre que sea posible y envíe después hitos significativos o un lote acotado de cambios. La frecuencia adecuada depende de los requisitos de recuperación y del coste de perder el trabajo local, pero una política que convierta cada llamada a una herramienta en un envío remoto genera tráfico de escritura evitable.

Para los trabajos de larga duración, conserva los puntos de control locales o externos por separado de la actualización de la rama si el equipo necesita una recuperación detallada. Así, el requisito de recuperación duradera queda separado de la referencia de Git que deben consumir otros desarrolladores y sistemas.

Evita crear una única referencia saturada

Miles de ramas independientes aún pueden converger en una rama protegida, una etiqueta de lanzamiento o una cola de combinación. Identifica las referencias que reciben la mayor tasa de escrituras y los flujos de trabajo que se serializan en ellas. Un repositorio puede ofrecer un paralelismo excelente entre ramas y, aun así, mantener una referencia compartida como cuello de botella práctico.

Usa colas de combinación y lotes controlados cuando mejoren el orden, pero supervisa la antigüedad de la cola y el comportamiento de los reintentos. Una cola que recalcula o revalida repetidamente el mismo conjunto amplio de cambios puede trasladar la presión de las escrituras de Git a CI, las API de solicitudes de incorporación de cambios o la infraestructura de pruebas.

Haz que las lecturas de CI sean deliberadas

La automatización con muchas lecturas puede sobrecargar un repositorio incluso cuando el volumen de envíos es moderado. Prefiere clones superficiales o parciales cuando el flujo de trabajo lo permita, reutiliza las cachés del repositorio, evita repetir clones completos para entradas idénticas y distribuye la expansión cuando una versión o actualización de rama active muchos trabajos a la vez.

La guía de repositorios de GitHub recomienda mantenerse dentro de límites operativos como un tamaño de envío de 2 GB, un techo recomendado de 15 operaciones por segundo para las lecturas de Git por repositorio y seis envíos por minuto por repositorio como tasa de envío recomendada. Estos valores no sustituyen la planificación de capacidad ni describen todas las configuraciones de API o empresariales, pero recuerdan que un repositorio es un límite de servicio compartido. Los clientes automatizados deberían tratar los límites publicados como parámetros de diseño, en lugar de descubrirlos mediante la limitación de tráfico.

Evita que los reintentos amplifiquen un incidente

Un error al enviar o recuperar cambios puede hacer que una gran flota de automatización reintente la operación al mismo tiempo. Usa un retroceso exponencial con aleatoriedad, limita el número de reintentos, distingue los errores transitorios de transporte de los fallos de políticas y registra el ID de la operación original o el rango de commits para que un reintento no genere trabajo duplicado.

Una política de reintentos también debería respetar la revisión humana. Si un flujo de trabajo espera la actualización de una rama protegida, reintentar a ciegas puede inundar la misma referencia mientras un operador investiga. El retroceso es un control de fiabilidad, no solo un ajuste de rendimiento del cliente.

Conserva la gobernanza mientras aumentas la automatización

GitHub afirma que la nueva infraestructura pretende conservar las protecciones de ramas, las revisiones obligatorias, los registros de auditoría y la visibilidad de los repositorios. Las organizaciones deberían verificar que sus propios flujos de trabajo con agentes dependan explícitamente de esos controles. Una ruta de escritura más rápida no sustituye las reglas de aprobación, el análisis de secretos, los commits firmados cuando sean obligatorios, la protección de entornos ni las comprobaciones de despliegue.

Los agentes deberían recibir únicamente los permisos de repositorio y entorno necesarios para su tarea. Separa el acceso a la generación de código de la autoridad para combinar cambios, las credenciales de despliegue y los datos de producción. Si un agente puede crear ramas, pero no actualizar la rama predeterminada protegida sin una revisión, las mejoras de escalabilidad de la plataforma aumentan el rendimiento sin eliminar silenciosamente el punto de decisión humano.

Lo que aún se desconoce

Varias preguntas importantes siguen abiertas en la descripción pública de GitHub.

La empresa no ha publicado un calendario completo de despliegue para la nueva arquitectura. Tampoco ha explicado cuántos repositorios de producción reciben servicio del modelo de lectura respaldado por almacenamiento, qué cargas de trabajo cumplen los requisitos ni cuándo deberían los clientes esperar cambios observables en los límites y la latencia.

Las afirmaciones de los benchmarks también necesitan más contexto. Los lectores externos necesitan definiciones de las cargas de trabajo, tamaños de los repositorios, niveles de concurrencia, latencias p50 y p99, comportamiento ante fallos y comparaciones con la ruta existente. Sin esos detalles, «hasta» es una señal útil para ingeniería, pero no una garantía para la planificación.

La coherencia durante el calentamiento de la caché es otro aspecto que conviene vigilar. Un trabajador que restaura el estado desde el almacenamiento de objetos no debe devolver valores obsoletos de referencias de una forma que vulnere las expectativas de Git. El sistema también debe gestionar la compactación, la recolección de basura, las escrituras interrumpidas, los retrasos entre regiones y la recuperación ante fallos parciales sin convertir el mantenimiento en un nuevo cuello de botella del servicio.

Por último, la relación entre la actividad de los agentes y el crecimiento registrado de la plataforma sigue estando parcialmente sin medir. Las estadísticas de GitHub combinan desarrolladores humanos, automatización convencional, CI y flujos de trabajo con agentes. Eso basta para justificar un trabajo de arquitectura, pero no para concluir que todas las organizaciones tendrán el mismo patrón de concurrencia.

Lectura práctica del anuncio

GitHub está respondiendo a un cambio real en la forma de desarrollar software: más operaciones sobre repositorios, más ramas concurrentes, más lecturas automatizadas y mayor presión sobre los puntos de integración compartidos. La respuesta de la compañía consiste en reducir la coordinación innecesaria, separar el almacenamiento duradero de la capacidad de servicio y, cuando sea posible, hacer que la capacidad de lectura sea independiente del quórum de escritura.

Para los clientes, la lección inmediata es mantener la disciplina sobre las cargas de trabajo. Evita que el estado intermedio de los agentes se convierta en tráfico remoto de Git, identifica las referencias más solicitadas, controla la expansión de CI, almacena en caché las lecturas repetidas y aplica reintentos moderados. Sigue haciendo cumplir los límites de revisión y despliegue aunque la automatización sea cada vez más capaz.

La arquitectura podría dar finalmente a GitHub un margen de crecimiento considerable, pero los benchmarks publicados no eliminan la necesidad de medir las cargas de trabajo reales. La pregunta útil para un equipo de plataforma no es si GitHub ha anunciado un multiplicador elevado. Es qué parte del ciclo de desarrollo del equipo está actualmente serializada, si esa serialización es necesaria y qué ocurrirá cuando llegue el próximo aumento repentino de trabajo automatizado.