En este artículo
git-ai: fusiones concurrentes de agentes y verificación
git-ai, publicado como feder-cr/git-ai y denominado gitai, es un backend de control de versiones para agentes de programación que trabajan simultáneamente. Traslada las operaciones del repositorio a un servidor y agrupa los cambios que llegan a una misma rama. La pregunta más útil para decidir su adopción es si el equipo puede reducir la espera de integración y conservar pruebas sobre la revisión exacta que publica.
Generar un parche, aceptarlo en una rama y demostrar que el producto resultante funciona son acontecimientos distintos. gitai proporciona mecanismos para el paso intermedio y para comprobar determinados resultados. El proceso de ingeniería todavía debe conectarlos.
Revisión de fuentes: , commit 6b0ab81e6e37. El README revisado identifica gitai como versión 0.3.0. Este artículo analiza documentación y código fuente; no describe un despliegue de Wavect ni un benchmark de rendimiento ejecutado de forma independiente. Los casos de evaluación que aparecen más adelante son nuestras recomendaciones.
¿Qué es feder-cr/git-ai y qué relación tiene con Scion?
El README del proyecto en el commit revisado lo presenta como una implementación independiente con licencia MIT, inspirada en el diseño de control de versiones que Anthropic hizo público. Parte del servidor Gitaly de GitLab. Los nombres de los ejecutables y de la configuración conservan graft, y los repositorios Git convencionales siguen siendo la base.
El artículo técnico de Anthropic sobre Scion describe infraestructura para la escala excepcional de su propio repositorio y sus agentes. gitai es otro proyecto. Los ahorros de infraestructura publicados para Scion no se pueden trasladar a gitai, e instalar gitai no instala el sistema interno de Anthropic.
| Nombre | Función principal | Decisión correspondiente |
|---|---|---|
| feder-cr/git-ai, o gitai | Operaciones del repositorio en el servidor e integración concurrente de cambios; su CLI se llama graft | ¿Cómo deben entrar los cambios terminados por los agentes en una rama con mucha actividad? |
| git-ai-project/git-ai | Atribución de código generado por IA, según su repositorio independiente | ¿Qué código procede de una herramienta de IA? |
| Graft para contexto de repositorios | Mapas del repositorio que aportan contexto al agente, analizados en nuestra evaluación de los mapas de repositorio de Graft | ¿Cómo encuentra un agente el código relevante? |
Comprueba el propietario del repositorio antes de seguir instrucciones de instalación. Compartir nombres no hace que sus comandos o integraciones sean intercambiables.
¿Qué cuello de botella resuelve la integración concurrente?
Landing significa integrar un cambio propuesto en una rama de destino. No significa desplegarlo. Cuando muchos agentes terminan a la vez, cada uno puede preparar su cambio sobre un extremo de rama que otro agente actualiza primero. Reconstruir y reintentar esa integración una y otra vez puede convertirse en una carga de trabajo propia.
La guía de implementación del landing explica la agrupación por lotes: un canal reúne solicitudes dirigidas a una misma rama de un repositorio dentro de un proceso del servidor, las integra sobre una revisión acumulada y publica los cambios aceptados mediante una actualización de referencia compare-and-swap. Esa actualización solo tiene éxito si la referencia anterior sigue coincidiendo con la esperada.
Sigue habiendo planificación y una cola interna. La diferencia está en cómo se coordinan las actualizaciones que compiten. La agrupación se aplica a solicitudes independientes compatibles con este modo; la documentación excluye expresamente el modo integrado con GitLab. Además, cada canal pertenece a un proceso, por lo que añadir nodos de servidor no crea un único canal compartido entre todos ellos.
| Problema observado | Primera investigación útil |
|---|---|
| Los agentes sobrescriben archivos locales o necesitan dependencias incompatibles | Aislamiento del espacio de trabajo y del entorno de ejecución. Empieza por nuestra guía de worktrees y Jujutsu. |
| Tareas compatibles necesitan una misma aplicación en ejecución para recibir feedback | Composición local y responsabilidad sobre las ramas, tratadas en nuestra guía del espacio de trabajo compartido de GitButler. |
| Los cambios terminados compiten repetidamente por actualizar una rama del servidor | Mide los reintentos de integración, la contención y la latencia. Este es el escenario relevante para evaluar gitai. |
| El código se fusiona sin conflictos de texto, pero rompe el comportamiento del producto | Mejora las pruebas de comportamiento, las comprobaciones de dependencias y la evidencia de publicación. Actualizar referencias más deprisa no demuestra que el resultado sea correcto. |
¿Cómo verifica gitai las resoluciones de conflictos de fusión generadas por IA?
Una resolución de conflictos generada por un modelo es una propuesta hasta que la verificación configurada pasa sobre el árbol que realmente se integraría. El protocolo de resolución separa el servidor de un comando o servicio HTTP opcional que resuelve los conflictos. La resolución debe habilitarse y solicitarse. Ese componente puede utilizar reglas deterministas o un modelo.
Para el contenido generado por un modelo, el operador debe configurar y habilitar verify.command. Si la comprobación no pasa, quien hizo la solicitud recibe un paquete de conflictos que puede incluir el contenido propuesto. Las resoluciones mediante reglas deterministas pueden integrarse sin esta verificación; al activar la comprobación, también se verifican esas resoluciones. Un comando personalizado que llame a un LLM debe identificarse como basado en un modelo. Clasificarlo como regla falsearía su origen.
El detalle decisivo de la implementación es la identidad del candidato. El código de integración compara el identificador del objeto árbol verificado con el del árbol fusionado real. Si una actualización concurrente cambia ese candidato, un resultado positivo anterior no puede autorizar sin más el árbol diferente.
Considera un cambio de facturación hipotético. El agente A renombra una función que calcula el total. El agente B añade un parámetro de impuestos a la función anterior. El componente de resolución puede producir código plausible y perder por el camino el cálculo del impuesto. Un verificador útil incluye una aserción sobre el total con impuestos. La compilación por sí sola podría no detectar el error. Si después otro cambio altera el redondeo, el árbol combinado resultante necesita evidencia correspondiente a ese estado.
Las pruebas de verificación del repositorio cubren casos como fallos del verificador, tiempos de espera agotados, candidatos modificados y reutilización cuando el árbol no cambia. Aportan evidencia útil sobre la implementación. Las hemos inspeccionado; no hemos ejecutado la suite de este proyecto. Que un comando configurado termine con éxito solo demuestra aquello que comprueba.
¿Una fusión sin conflictos pasa automáticamente por las mismas pruebas?
No. La verificación del componente de resolución no es una suite universal para todos los cambios aceptados. En la ruta ordinaria de integración revisada, los avances directos y las integraciones sin conflictos no invocan el verificador de resolución de conflictos. Las demás políticas configuradas siguen siendo aplicables.
Un conflicto de texto y un conflicto de comportamiento son distintos. Un agente puede modificar la autorización predeterminada y otro añadir un endpoint en un archivo diferente. Git podría combinar ambos cambios sin conflictos de texto, aunque el endpoint resultante tenga un comportamiento de acceso incorrecto.
Para un equipo que evalúa gitai, esto cambia la pregunta de aceptación. Averigua qué rutas ejecutan las comprobaciones obligatorias: cambios ordinarios sin conflictos, resoluciones deterministas, resoluciones de modelos y resoluciones aportadas manualmente. Una demostración satisfactoria de un conflicto resuelto con IA no permite deducir que todas las rutas estén cubiertas.
¿Qué comprueba graft-verify después de integrar los cambios?
La herramienta independiente graft-verify observa las actualizaciones de la rama, materializa una revisión y ejecuta el comando de pruebas del operador. Si pasa, avanza una referencia verde, por defecto refs/graft/green/<branch>. La bisección y la reversión automáticas requieren activación explícita mediante una configuración independiente; están deshabilitadas por defecto.
Esto crea dos posiciones relevantes: la rama de integración puede seguir avanzando mientras la referencia verde identifica una revisión comprobada. Para publicar, recomendamos seleccionar una revisión explícitamente verificada y vincular el artefacto de compilación a ella. Leer una referencia verde y después compilar el último estado de main descartaría precisamente la distinción que aporta el verificador.
| Etapa | Registro | Qué demuestra |
|---|---|---|
| Propuesta del agente | Revisión base, commit enviado y actor | El cambio solicitado y sus supuestos iniciales |
| Verificación de la resolución | Identificador del árbol candidato, comando y resultado | La comprobación configurada pasó para ese candidato de resolución de conflictos |
| Integración aceptada | Revisión integrada devuelta y actualización de la rama | El cambio fue aceptado en el repositorio |
| Verificación posterior a la fusión | Revisión comprobada, resultado de las pruebas y referencia verde | Las comprobaciones seleccionadas pasaron para esa revisión integrada |
| Publicación | Revisión elegida, hash del artefacto y aprobación de publicación | El proceso de entrega utiliza el artefacto construido a partir del estado aprobado |
La última fila es el compromiso que proponemos para el proceso de entrega, no una función automática de despliegue de gitai. La misma distinción se aplica a la recuperación: revertir código no deshace un pago, un correo enviado ni una migración destructiva de base de datos.
Un detalle de la integración con CI merece atención: graft-verify --once puede terminar con estado cero tanto cuando un lote se omite como cuando pasa las pruebas. Lee su resultado JSON, incluidos passed, skipped y el tip comprobado. Que el proceso termine correctamente no basta como evidencia para publicar.
¿Es gitai más rápido que GitHub o que Git convencional?
El benchmark de integración publicado no demuestra esa comparación. La documentación del benchmark compara la agrupación por lotes activada y desactivada en el mismo servidor. La carga destacada consiste en 50 agentes que envían cinco cambios cada uno a una misma rama, con un 20 % de conflictos deliberados.
Sin un componente de resolución, la carga agrupada integra 200 de los 250 cambios. Los 50 restantes son conflictos previstos. Un componente determinista puede resolver los conflictos construidos para la demostración, pero eso no mide si un LLM conserva comportamientos arbitrarios de una aplicación.
Además, el README y el documento del benchmark muestran intervalos distintos de rendimiento y latencia en el commit revisado. Por eso no deducimos de ellos un multiplicador de velocidad para el titular. La conclusión respaldada es más limitada: agrupar las solicitudes puede reducir los reintentos que compiten entre sí en esta carga sintética.
Para tu propia comparación, mide el tiempo desde que un cambio está terminado hasta que se obtiene una revisión verificada, junto con los fallos, la intervención humana y el coste operativo. Incluye la suite de pruebas real y un solapamiento de archivos representativo. Aceptar más commits por minuto solo resulta útil si la verificación y la recuperación mantienen el ritmo.
¿Qué debe comprobar un equipo que aloja gitai respecto a permisos y exposición del código?
El modelo de seguridad de agentes proporciona identidades por agente y políticas sobre referencias. El token compartido sigue siendo una credencial del operador. En la implementación revisada, la herramienta de verificación posterior graft-verify utiliza esa credencial y los agentes no pueden acceder directamente al espacio de nombres reservado refs/graft/. Diseña una integración controlada con el proceso de publicación, en vez de entregar a todos los agentes de programación la autoridad de esa herramienta.
Alojar el repositorio en tu infraestructura no determina adónde envía código el componente de resolución. Un servicio externo habilitado puede recibir el contenido permitido de los archivos en conflicto. Decide qué rutas y proveedores pueden utilizarse, teniendo en cuenta el código fuente que contenga datos personales o credenciales. El comportamiento documentado de los patrones glob importa: *.env no cubre recursivamente los archivos .env de carpetas anidadas. El componente de resolución no descubre ni oculta automáticamente todos los secretos.
La implementación del verificador previo a la integración ejecuta un comando configurado sobre el contenido del repositorio. Trata ese contenido como entrada ejecutable procedente de los agentes y del componente de resolución. Un entorno reducido no es un sandbox: aísla el ejecutor, elimina las credenciales innecesarias, restringe la red y limita los recursos. La salida de las pruebas también puede revelar datos, por lo que restringir la red no basta.
¿Adoptar gitai implica sustituir el alojamiento de código actual?
Empieza por definir qué sistema es responsable de la rama y cuál gestiona la revisión, la CI y la publicación. El backend del repositorio es solo una parte de una plataforma de desarrollo. Nuestro análisis de migración del alojamiento de código trata la decisión más amplia sobre la plataforma; este artículo se centra en aceptar y comprobar cambios de agentes.
La documentación del subsistema de revisión identifica un límite importante: registrar una revisión aprobada todavía no convierte esa aprobación en una comprobación obligatoria antes de integrar. Si el proceso exige una aprobación independiente, verifica por separado que se imponga.
La documentación del núcleo de almacenamiento distingue el modo opcional de observación, shadow, del almacenamiento autoritativo. Describe SQLite para un nodo y PostgreSQL con almacenamiento de objetos compartido para varios nodos. Los repositorios Git locales siguen necesitando materializar datos y disponer de espacio en disco. Trasladar la fuente de verdad merece, por tanto, su propio ejercicio de recuperación.
Parte de la documentación general va por detrás de los detalles recientes de la implementación. Por ejemplo, la documentación actual de almacenamiento describe una recolección opcional de paquetes no utilizados, y el árbol incluye pruebas de almacenamiento con varios nodos. Ninguno de esos hechos permite asumir que se haya validado el backend cloud elegido, tus escenarios de fallo o tu carga de producción. Fija una revisión y verifica la ruta de despliegue que realmente utilizarás.
¿Cómo evaluar gitai antes de trasladar una rama de producción?
Utiliza un repositorio desechable, tareas de agentes representativas y casos de fallo explícitos. Mantén el despliegue desconectado mientras determinas qué se acepta, comprueba y recupera. Empieza con el proceso Git actual como referencia de comparación; hay que medir un cuello de botella de integración antes de convertirlo en una razón para operar otro servicio.
El inicio rápido del proyecto requiere Linux o macOS, Git, make, la CLI de OpenSSL, Go 1.26, una cadena de herramientas de C, Meson y Ninja. Estos comandos fijan el código fuente revisado aquí y después ejecutan su ejemplo. No los hemos ejecutado como parte de este artículo:
git clone https://github.com/feder-cr/git-ai.git
cd git-ai
git checkout --detach 6b0ab81e6e3766824920ec18e17593fe8db714fd
make build
examples/graft/quickstart.shEl servidor y los agentes del ejemplo de inicio rápido demuestran un flujo de trabajo. No acreditan un modelo de permisos para producción, un rendimiento representativo ni un plan de recuperación probado.
| Caso que se debe probar | Evidencia que se debe recoger |
|---|---|
| Varios cambios sin conflictos apuntan a una misma rama | Qué cambios se integran, reintentos, solicitudes rechazadas y latencia, incluidos los intentos fallidos |
| Una resolución del modelo incumple una aserción de comportamiento | El candidato sigue siendo una propuesta y la rama no acepta automáticamente esa resolución |
| El destino avanza durante la verificación | El candidato modificado se comprueba de nuevo; un resultado positivo obsoleto no lo autoriza |
| Una regla determinista resuelve un conflicto | Se entiende la diferencia entre desactivar y activar la verificación, y el comportamiento coincide con la política prevista |
| Una integración sin conflictos incumple una regla del producto | Las pruebas posteriores seleccionadas detectan el problema y la revisión fallida no entra en la ruta de publicación |
| El verificador omite un lote, agota el tiempo o encuentra una prueba inestable | La integración con el proceso de publicación distingue esos resultados de un éxito y evita una reversión injustificada |
| Un agente solicita una rama prohibida o una referencia reservada | Rechazo por permisos, atribución correcta del actor y separación de la autoridad del operador |
| Un servidor se reinicia o pierde la caché local del repositorio | Recuperación de la referencia y los objetos esperados, tiempo de recuperación medido y conservación de la evidencia de verificación |
Compara el tiempo hasta una entrega verificada, la intervención de los revisores, las regresiones y el coste operativo total. Añade el crecimiento en disco y el tiempo de recuperación si pruebas el almacenamiento autoritativo. Define los límites aceptables antes del ensayo, para que una demostración más rápida no cambie silenciosamente la definición de éxito.
El trabajo de implementación práctica de IA de Wavect puede ayudar al equipo a definir esta evaluación y sus criterios de publicación. Nuestro caso de estudio de Hyperstate AI describe otro trabajo de ingeniería, no un despliegue de gitai. Utiliza la lista de verificación de calidad de software antes del lanzamiento para concretar las pruebas de comportamiento, o comenta un cuello de botella de integración de agentes concurrentes con ejemplos recientes de reintentos e integraciones fallidas.
Verificación de fusiones con gitai: preguntas frecuentes
¿Es feder-cr/git-ai la herramienta de atribución de código de IA?
No. feder-cr/git-ai es un backend de control de versiones para agentes de programación, con una CLI llamada graft. git-ai-project/git-ai es un proyecto independiente para rastrear código generado por IA. Comprueba el propietario del repositorio antes de seguir instrucciones de instalación.
¿Es gitai una versión oficial de código abierto de Anthropic Scion?
No. Es un proyecto independiente inspirado en ideas de Scion descritas públicamente. La implementación interna de Anthropic y sus resultados de infraestructura no son versiones de gitai ni garantías de su rendimiento.
¿Puede gitai resolver automáticamente un conflicto de fusión con contenido generado por IA?
Admite un componente de resolución opcional. Las resoluciones generadas por modelos requieren una verificación configurada y habilitada que pase sobre el árbol exacto que se integraría. De lo contrario, siguen siendo propuestas. Las resoluciones mediante reglas deterministas tienen valores predeterminados diferentes.
¿Comprueba verify.command todas las fusiones sin conflictos?
No. En el commit revisado, el verificador de resolución de conflictos no es una barrera universal de pruebas para las integraciones sin conflictos. Define comprobaciones para esos cambios por separado y utiliza evidencia vinculada a una revisión verificada en el proceso de publicación.
¿Revierte graft-verify automáticamente los commits que fallan?
Solo cuando se activa explícitamente la reversión automática. Por defecto, se notifican los fallos y la referencia verde permanece en su posición anterior. Revertir el código tampoco deshace efectos externos, como una migración de base de datos.
¿Un código de salida cero de graft-verify demuestra que la revisión pasó las pruebas?
No. Una ejecución única puede terminar correctamente cuando se omite un lote. Inspecciona el resultado estructurado e identifica la revisión comprobada antes de tratar el resultado como evidencia para publicar.
¿Debería un equipo pequeño sustituir Git worktrees por gitai?
Abordan capas distintas. Los worktrees separan las copias de trabajo locales. Evalúa gitai cuando una contención medida en la integración del servidor justifique el servicio adicional y la conexión con las verificaciones. Tener unas pocas tareas paralelas no demuestra por sí solo esa necesidad.