Cómo usar VARIOS AGENTES de IA en PARALELO 🚀: Claude Code + Codex + Git Worktrees

Vídeo em Espanhol, publicado pelo canal NR Labs.

Sobre este contenido: El resumen, los puntos principales y los temas que aparecen a continuación se generan automáticamente a partir de la transcripción del vídeo. Reflejan el contenido, las opiniones, afirmaciones y predicciones presentadas en el vídeo y no representan una posición, validación o verificación de hechos por parte de IA Dots.

Resumen del vídeo

El video explica cómo utilizar Git Worktrees para permitir que múltiples agentes de inteligencia artificial trabajen en paralelo sobre el mismo proyecto sin que sus modificaciones entren en conflicto o interfieran entre sí en los mismos archivos locales.

Puntos principales

• Abrir múltiples agentes de IA sobre el mismo proyecto y la misma carpeta local genera problemas porque todos modifican los mismos archivos simultáneamente.
• Git Worktrees permite crear múltiples carpetas físicas conectadas al mismo repositorio y al mismo historial de commits, pero con directorios separados.
• El uso de Worktrees posibilita que diferentes agentes, como Claude Code y Codex, operen en paralelo sobre ramas aisladas sin interferir en el trabajo de los demás.
• Tras finalizar las modificaciones en las carpetas de trabajo aisladas, los cambios se pueden fusionar (merge) en la rama principal local antes de subirlos a GitHub.
• Se demostró un caso práctico donde un agente implementó mejoras de rendimiento de video y otro agente actualizó información y componentes de la interfaz en paralelo.

Temas

Git WorktreesAgentes de IAControl de versionesDesarrollo paraleloClaude CodeCodexRamas de Git

Transcripción del vídeo

Texto de los subtítulos disponibles; puede contener errores.

Últimamente, solo estoy programando con agentes de IA y apareció un problema bastante obvio. Si abro tres agentes independientes sobre un mismo proyecto, los tres están tocando los mismos archivos. Uno cambia algo, el otro refactoriza un archivo mientras el primero todavía está trabajando sobre él y cuando querés realmente trabajar en paralelo con varios agentes, se empieza a volver un quilombo. Así que hoy quiero mostrarte cómo estoy resolviendo esto con una herramienta de Git que existe hace años, pero [resoplido] que con los agentes de IA se volvió muchísimo más interesante, Git Worktrees. Al final del video vamos a tener a Cloud Code y a Code trabajando sobre la landing de NR Labs, cada uno completamente aislado. Y después voy a poner un modelo chino barato contra uno Frontier con exactamente el mismo prompt para comparar los resultados. Pero para que Worktree tenga sentido y no sea simplemente copiar y pegar comandos, primero tenemos que entender rápidamente qué es lo que hace Git por debajo. Voy a empezar directamente con la landing de NR Labs, la cual está construida en Astro y acá tengo el código en GitHub, que está, bueno, esta es la versión de producción. Acá, bueno, podemos ver un poco de la landing. Para este video voy a clonar eh mi repositorio en una carpeta nueva, bueno, para [música] no trabajar sobre mi entorno habitual, así que vamos a crear una carpeta nueva. [risas] Vamos a abrir una terminal y un Git Clone y ya tengo copiado el el link de mi repositorio. [resoplido] Bueno, acá vemos que este comando Git Clone nos está diciendo que nos está clonando nuestro repositorio dentro de la carpeta Landing NR Labs, que es el nombre del repo, y no solamente nos trae los archivos, sino que también nos trae el historial [música] de Git, es el historial de los cambios que se fueron haciendo sobre el paso del tiempo. Bueno, esta carpeta que estamos viendo, landing NR Labs, es mi working tree, sería como mi espacio físico de trabajo, que está eh asociado al repositorio en GitHub. Estos son los archivos físicos sobre los que trabajo yo, si me pusiera a trabajar en Visual Studio Code, como también [música] son los archivos sobre los que trabaja eh Cloud Code, Open Code o CodeX, pero por detrás de esto está trabajando Git, que lo que hace es gestionar eh el historial de cambios. Entonces, todo lo que nosotros vamos haciendo en el working tree, Git también lo está controlando por detrás mediante los commits, [música] las ramas. Por ejemplo, si yo ejecuto Git branch -b, bueno, acá nos dice eh que estamos en la rama main localmente, y acá aparece otra en color azul eh origin main, que esto genera mucha confusión a veces, sino que esto es eh la referencia que tiene eh nuestro Git local, el estado del proyecto en el repositorio de GitHub contra lo que tenemos nosotros acá localmente. Acá nos dice que eh main está en el commit [música] E52442E, o sea, está en este cambio, y origin main también está en ese mismo commit. ¿Qué quiere decir esto? Bueno, quiere decir que aún todavía no hicimos ningún cambio dentro de este eh dentro de esta carpeta local. Por ejemplo, si yo me vengo eh a Visual Studio Code, bueno, ya estamos dentro de landing NR Labs, y yo, por ejemplo, hago un cambio en source, en components landing y vengo acá y agrego una nueva, un nuevo valor dentro de la capa de la interfaz. Luego vengo y hago un git commit. [música] Y main local pasaría a apuntar al nuevo commit que tendría lógicamente otro ID y nos diría que está un commit adelantado respecto a origin main. Osea que van a quedar eh los dos desfasados. Si vemos acá en GitHub, estamos en main, que sería básicamente la rama principal, la de producción eh y acá vemos que el último commit fue hace dos meses y [música] tiene 30 commits, osea tiene 30 cambios, uno por encima del otro. Cuando uno empieza a programar, empieza con nada, cuando va agregando archivos sería el primer commit hasta que llega a este ejemplo, el último caso, el commit [música] 30. Bueno, por defecto [música] repasamos que la primera vez que clonamos un repositorio [resoplido] siempre estamos parados en la rama main. Para explicarlo rápidamente, una rama, una forma que tiene Git de llevar el control de cambios. Cuando por ejemplo nosotros nos ponemos a desarrollar una nueva funcionalidad, no sé, por ejemplo, un nuevo fuder para nuestro sitio web, nosotros podríamos crear una nueva rama y lo que hace básicamente es todos los cambios que se hagan en la carpeta local a partir de ese momento en el que estamos en una nueva rama, se van guardando dentro de ella. Eh yo en mi caso, lo que quiero, vamos a la primera prueba que vamos a hacer, ven acá el efecto de, como este video incrustado en en el inicio de mi página, eh, como que hay que [risas] dar muchas vueltas a la ruedita [música] y se siente un poco como un poco laguiado o, por así decir, eh, no se siente fluido, entonces lo primero que quiero mejorar es eso. [música] Así que lo que podríamos hacer es crear una nueva rama donde todos los cambios que yo haga para mejorar esto queden dentro de esa rama que la vamos a llamar, por ejemplo, [resoplido] Bueno, entonces, la carpeta del proyecto, Git switch -c, que es, eh, de create, para crear la rama, o sea, que en un mismo comando vamos a crear la rama y vamos a cambiar automáticamente. Mejora video, por ejemplo. [música] Entonces, automáticamente vemos que nos dice, eh, cambiaste a la nueva rama, eh, mejora video. ¿Qué pasa con las ramas? Si nosotros vemos, eh, dentro de una misma carpeta local, podemos tener [música] diferentes versiones de nuestro código. Tenemos main que [música] tiene 30 commits, pero yo los cambios que empiezo a hacer ahora los puedo publicar en la rama que acabamos [carraspeo] de crear, mejora video. [música] Entonces, cuando nosotros, eh, hagamos, subamos estos cambios a nuestro repositorio, no se van a publicar en main, sino que se van a publicar en la nueva rama que creamos localmente. Esta rama, siempre recuerden que lo que nosotros hacemos en nuestra terminal, lo que sea todo local, primero lo estamos haciendo dentro de la carpeta física. Todavía no subimos nada a GitHub. Bueno, supongamos que quiero cambiar algo en mi código, pero quiero que el historial de cambios eh siga eh cuidando lo que hay en main, o sea, no quiero modificar lo que hay en main ni agregarle cambios ni commits, que Git conserve y cuide lo que ya teníamos hasta estos 30 commits [música] y entonces creamos la rama nueva, que todos los cambios que hagamos a partir de ahora todos van a quedarse almacenados en mejora video. Pero hay un problema y es que más allá de que Git sí se esté la separación eh de lo que hay entre una rama y otra y que no se van a mezclar los cambios que hagamos de un lado u del otro, siempre estamos trabajando sobre la misma carpeta local. Y sí, es la magia de Git, o sea, nosotros podemos tener dos versiones de un mismo proyecto eh dentro de una carpeta y cuando estamos parados en una rama vemos una versión y cuando estamos parados en otra rama vemos la otra versión. Para que nos demos cuenta de esto, pero por ejemplo, yo puedo venir acá a Visual Studio Code. [música] Por ejemplo, yo eh vengo acá y creo un archivo nuevo, creo un archivo MD como para probar, creo un claude [música] MD. Pongo esto es un archivo de prueba. Bueno. Guardamos y si nos vamos eh acá al al repo, nosotros, eh, perdón, a la terminal, hacemos un Git status [música] y fíjate que, eh, nos dice, en la rama mejora video, eh, hay archivos que no están trackeados, o sea, que todavía no los subimos al historial de de Git, eh, así que lo que tendremos que hacer, eh, lo primero es, eh, hacer un add de los cambios. Vamos a poner Git add para que se agregue todo, porque lo único que cambiamos fue el cloud md. Ponemos punto y ahora hacemos un Git status de nuevo y me dice nuevo archivo cloud md, entonces, eh, los cambios tienen que ser commiteados, entonces hacemos Git commit guión m y vamos a poner cloud md md en el comentario, fuera. Apretamos un enter y ahí nos dice que, eh, ya se hizo el commit nuevo en, con este, bueno, con este código, pero si ustedes ven acá, prestan atención a la izquierda donde está el cloud md, vamos a, eh, yo lo que voy a hacer es, eh, volver a cambiar de vuelta, si nos vamos acá a la carpeta vamos a ver que el cloud md ya está creado también, pero yo me voy a la terminal y voy a hacer Git switch para cambiar de rama y voy a hacer main. Y si se dan cuenta, el archivo desapareció, cloud md desapareció, acá a la izquierda también no lo tenemos más. Y acá en la carpeta tampoco lo tenemos. Y esto es no es porque se haya eliminado el archivo, sino porque en nuestra carpeta local, nosotros teníamos main, que era lo que nos vino de fábrica del repositorio, eh, perdón, eh, la rama mejora video, que es donde habíamos hecho, eh, el cloud md. Y nosotros, eh, al haber hecho un commit acá, [música] cambio uno en la rama dos, quedamos en el cómic 31, que el cómic 31 hm, era mejora vídeo, bueno, eh, el cómic de la Cloud MD prueba con este ID. Pero cuando nosotros hicimos Git switch, cambiamos de vuelta a la rama main y volvimos al cambio al cómic 30. [música] Vamos de vuelta, si pongo Git switch mejora vídeo, de vuelta vemos que el Cloud MD aparece acá al costado. Bueno, ahora que entendimos un poco cómo funciona Git, entran los agentes. [música] Bueno, yo acá en este en este proyecto puedo abrir todos los agentes que quiera, por ejemplo, puedo abrir Open Cloud. Abro otra terminal y abro un Cloud Code. [música] Y me voy a Code y puedo hacer tranquilamente lo mismo. Pero fíjate en algo, los tres están parados, en este caso, [música] eh, sobre la misma ruta eh, física, sobre los mismos archivos locales. [música] Entonces, ¿qué problema tendríamos? Nosotros la limitación que tiene Git en este caso es que en nuestra computadora no podemos estar en dos ramas en paralelo al mismo tiempo, [música] con los mismos archivos. Sí, podríamos crear dos carpetas por separado, entonces el problema de que los tres agentes estén trabajando sobre los mismos archivos es que si, si por ejemplo Cloud Code modifica alguno de los archivos de este proyecto, CodeX tranquilamente podría haber estado referenciando el archivo ese que [música] Cloud está modificando y CodeX ya tiene una versión desactualizada del archivo y tranquilamente podría intentar realizar algunos cambios en los que no está teniendo en cuenta la implementación ni la lógica que está elaborando Cloud Code. Entonces, el gran problema es ese, no podemos ni siquiera [música] eh tener dos Cloud Code abierto al mismo tiempo en el mismo proyecto, en el la misma rama de Git, porque por más que sean el mismo agente, si los estamos trabajando de formas independientes, los dos agentes pueden estar haciendo cambios sin tener en cuenta lo que está haciendo el otro. Para que se entienda conceptualmente, no importa que yo les esté diciendo que hagan cambios de forma independiente, sino que los tres agentes están trabajando en la misma mesa de trabajo. Esto es una representación sencilla [música] pero si nosotros tenemos tres carpinteros trabajando sobre la misma mesa de trabajo, de alguna forma u otra se pueden estar molestando, ya sea o por cómo dejan las herramientas o porque uno necesita. Entonces, algo similar pasa eh con las cuestiones del código. Nosotros tenemos que entender el código como piezas que arman a a un producto o a un artefacto entero. Entonces, si quiero que todo esté en armonía, que cada agente pueda hacer los cambios que quiera, [música] pero de forma aislada, sin romper lo que está haciendo el otro, también necesitamos una carpeta distinta por cada agente. [música] Y eso es exactamente lo que hace Git Worktrees. [música] Un Worktree, básicamente, me permite decirle a Git, "Además de mi carpeta principal, dame otra carpeta física del mismo repositorio para que yo pueda trabajar de forma aislada en otras ramas y en los mismos archivos sin preocuparme por lo que pase en la carpeta principal. No estoy clonando Git, no estoy clonando el repositorio dos veces, no se confundan, ni creando dos proyectos independientes. Comparten el historial, los commits. ¿Qué quiere decir esto? [música] Que lo que hagamos en esta carpeta después se va a comparar con lo que había en nuestro repositorio principal y en nuestro Git [música] local. Las dos carpetas comparten el mismo repositorio, o sea, que lo que hay en main, en carpeta local dos, también se compara con origin main, pero la ventaja de esto es que nosotros tenemos los mismos archivos, pero por dos pero en dos directorios separados. Y ahí sí podemos pedirle a Cloud Code, a Codex [música] o a Open Code que hagan los cambios que quieran, que modifiquen lo que quieran, total cada uno tiene su propia mesa de trabajo en la que puede modificar, romper o hacer y no tiene que preocuparse porque está molestando en el trabajo que está haciendo el otro agente. Vamos a hacerlo manual para entender un poco cómo funciona, pero quiero aclararles que los agentes de IA ya, con la capacidad que tienen, ya hace bastante tiempo, eh esto lo pueden automatizar, es más, Codex ya lo hace automáticamente a los worktrees, cuando hace cambios, etcétera, después mergea eh al main local o a la rama local de la carpeta principal. [música] Bueno, vamos a tirar un clear. Lo primero que vamos a hacer, vamos a ver si nuestro nuestro repo, eh bueno, estamos en main. [música] Ya estamos en main y quiero ver si nuestro repositorio está eh anivelado a origin main. Eh bueno, acá nos dice que no, pero porque esto es eh unos archivos que se crean automáticamente eh como es al momento de de abrir alguna instancia de Cloud Code o de Open Code. [música] Así que no nos vamos a preocupar. Estamos exactamente nivelados a origin main. Eh voy a crear eh un work tree eh esta mejora que queremos realizar en el desempeño del video que está insertado acá en el inicio de mi página. Armar el comando para crear el Git work tree, específicamente con el nombre de la tarea que vamos a hacer y vamos a crear una rama, el work tree. Como nosotros vemos, acá tenemos eh landing en NR Labs, que es eh básicamente el la carpeta principal que [música] clonamos desde el repositorio. Abrimos una terminal dentro de esta carpeta y vamos a crear un work tree, que si se acuerdan yo había dicho que working tree era la carpeta esta donde la donde están los archivos físicos y Git work tree es básicamente crear una nueva carpeta del repositorio con archivos físicos, pero que no es el hilo de trabajo principal, sino que es una nueva un nuevo hilo de un nuevo working tree. Entonces, hacemos Git work [música] tree add. Vamos a crear eh esta carpeta por fuera de la carpeta principal, sino vamos a tener una copia de este repo de esta carpeta dentro de la carpeta y no queremos eso. Entonces, tenemos que poner eh dos puntos [música] y vamos a poner NR Labs landing video performance. [música] Y vamos a con guion B crear una nueva rama dentro de ese working tree. A esa rama le vamos a poner mejora vídeo. Okay, bueno, ya nos dijo que creó el working tree, nos vamos para atrás y vemos que acá está en el Relapse Landing Video Performance y vemos que es [música] un calco de la otra carpeta. Pero las dos carpetas literalmente están compartiendo el mismo historial de cambios, nada más que al nosotros también crear una rama nueva, todos los cambios que hagamos acá los estamos haciendo de forma separada de lo que hay en main, que es hacia donde apunta esta carpeta. Para compararlo rápido, hacemos, abrimos una terminal y hacemos Git eh status [música] y dice, bueno, nuestra nuestra rama es main y si yo me voy a la otra carpeta abro en terminal, hago un Git status y vemos nuestra rama es mejor, mejora vídeo. Bueno, nosotros entonces ahora podemos tener un agente trabajando en main con un working tree por separado, podemos tener trabajando un agente en el vídeo performance, que está en la rama mejora vídeo y también podemos tener eh la cantidad de agentes que queramos con la cantidad de de working trees que queramos crear. [música] Entonces, nosotros creamos un working tree acá, vamos a a replicar el comando y vamos a crear eh un nuevo working tree, vamos a ponerle otro nombre en el Relapse eh mejora [resoplido] information, como para mejorar la el la información que tengo en la landing, que creo que tengo bastante información que está desactualizada. Ponemos mejora información en la rama, o sea, vamos a crear un working tree, [música] un espacio físico en nuestra carpeta, que va a estar en la rama eh mejora información. [música] Bueno, vemos que se creó y ahora podemos abrir un agente [música] en cada working tree, todos los cambios que se hagan en cada working tree los vamos luego a fusionar eh [música] con, bueno, la carpeta local principal en main y después los vamos a llevar al repositorio de GitHub, o sea, que vamos a tener tres agentes en paralelo trabajando sobre el mismo proyecto, ninguno se va a pisar, cada uno va a hacer los cambios que tenga que hacer, después fusionamos todo y como resultado vamos a subir los cambios al repo. [música] Bueno, entonces para el video performance quiero usar Cloud Code, porque creo que lo siento un poquito mejor que Codex. [música] Ahora que estamos acá en Cloud Code, lo primero que le voy a pedir a Cloud es necesito que identifiques el video que está [música] insertado en secuencia de imágenes en el inicio de la home de mi proyecto [grito ahogado] y logres una optimización [música] en la fluidez. Cuando hablamos de optimización en la fluidez hablamos de esto, de que sea un poco más fluido y no haya que escrolear tanto con el mouse. Vamos a inspeccionar esto para ver cómo se ve en mobile. En mobile se ve mejor porque es otro video también. No, pero en mobile se ve muchísimo mejor. [música] Vamos a indicarle que em la idea es ni calidad ni ninguna parte [música] del mismo, me refiero al video, pero la fluidez debería mejorar entre sí por lo menos un 30% [música] en escritorio. Bueno, esto le pedimos a Cloud Code [música] y ahora automáticamente nos vamos a mejora de información. Abrimos una terminal, perdón, abrimos una terminal no, nos vamos a Codex. Y vamos a agregar un nuevo proyecto. Nuevo proyecto, le ponemos el nombre en Codex que sería mejora información en el Relaps. [música] Ponemos añadir. Escritorio, bueno, proyectos [música] y nos vamos a la carpeta al proyecto física, al working tree, eh mejora de información. Ponemos crear proyecto, marcar la carpeta como de confianza. Vamos eh a identificar qué es lo que quiero mejorar de la landing en cuanto a la información. Bueno, plantillas de N8N, esto [música] lo quitamos definitivamente. Es como que plantillas es muy básico, en el plantilla de N8N eso lo agregó la IA porque quiso. Le voy a decir, quita lo de y agrega agentes [música] de IA em para atención al cliente. Y bueno, y vamos a pedirle también que la portada del vídeo de YouTube [música] se vea y también [música] que en la sección en la portada de cada card de los vídeos se visualice la portada de YouTube, me refiero a la captura que te adjunto con comentarios. Bueno entonces vamos a sacarle una captura. [música] Creo que acá no está bien, vamos un poquito más abajo, ahí. [música] Capturar, la pegamos y vamos a agregarle un comentario. Para agregar comentarios adjuntamos la imagen, ponemos comentar, podemos agrandar la imagen acá. [música] Acá se debería poder visualizar la captura de los vídeos que están dentro de cada sección. No, que te redirija redirija al [música] enlace. El enlace está dentro de la card. Vídeo lógicamente. Aquí lo mismo, otro ejemplo. Bueno, esto lo achicamos, vamos a poner sol en muy alto y vamos a ponerlo en fast para que haga los cambios rápidos. [música] [música] Bueno, lo interesante acá del work de los work trees [música] es que los cambios que está haciendo Codex los está haciendo en la carpeta en el relax mejor information, mientras que los cambios que está haciendo [música] Low Code Los está haciendo en la carpeta en el relax landing vídeo performance. Eh, o sea, son mismos proyectos, mismo repositorio, mismo historial de Git, pero los archivos físicos no son los mismos. Bueno, vamos a esperar que terminen los cambios. Bueno, cada uno sigue trabajando lógicamente. Recursos y vamos a ver acá Claude. Bueno, Claude ya terminó. Así que vamos a ver. [resoplido] Me hice. Listo, bajé, listo, bajé el salto entre frames en escritorio de unos 28 píxeles de scroll. Vamos a ver qué fue lo que hizo eh realmente. Vamos a ver el Git status primero para comprobar que [música] están separados básicamente. [música] Vemos que estamos en la rama mejora de vídeo y bueno, acá los archivos modificados y los archivos que todavía no están traqueados. Hacemos un Git diff. Para hacer el Git diff es mostrarnos la parte del proyecto eh que fue modificada. [música] Eh bueno, los archivos eliminados, las líneas eliminadas, los nuevos eh Y las nuevas las nuevas adiciones, eh, bueno esto [música] podemos ir viendo todo de esta forma. [música] [música] Así que para ver simplemente cómo quedaron los cambios y compararlos con lo que tenemos hoy en día en producción, hacemos un npm run dev. Esperamos que compile. Una vez que compila, vamos a poder cargar la página. Y bueno, [carraspeo] perdón pero creo que lo arruinó Claude. Se ve lentísimo. Y no sé qué error me tiró. [música] Esto está haciendo un fail. [música] Eh, y encima me dice, "Se ha producido un error al Ah, vos sabés que el el problema que está pasando acá [música] es que Codeci y Claude se están peleando por el mismo puerto. [música] Antes de de volver a iterar con Claude, vamos a ver los cambios que hizo Codex, lo mismo en el npm run dev. Bueno, y vemos inventario, producto en desarrollo para hacer visible el depósito de tu pyme sin cambiar tu sistema de gestión. Ver producto y nos lleva a la landing de inventario. Agentes de IA para atención al cliente, atención conversacional con integraciones eh para WooCommerce, Mercado Libre, Shopify, Tienda Nube, conexión con tu ERP, con tu stock y pedidos, generación de comprobantes. Respecto a desarrollos a medida, consultar proyecto, Power BI y más gente y una gente más a los KPIs de tu tablero para consultar los datos de tu negocio, consultas en lenguaje natural, indicadores y métricas de Power BI, respuestas con contexto de negocio. Muy bueno, hablamos esto que iba al que antes. Y bueno, acá le cambié el comentario que le pedimos. Eh vamos a laboratorio y acá vemos cómo le sumó las portadas a a [música] a los videos. Si ponemos ver transmisión, vamos a la página donde tenemos toda la info del video. Eh así que bueno, la verdad que esto también me gustó. Bueno, vamos a cerrar esto y vamos de vuelta a probar los cambios de Claude. [música] npm run dev. Y bueno, vemos como que, o sea, sinceramente el efecto se siente horrible. [música] No parece que haya mejorado. Bueno, y y para aclarar otra cosa, si vemos los cambios que yo le pedí a Codex, no están en el directorio de Claude, eso es lo que queríamos lograr, básicamente. Como tampoco acá en laboratorio, ven que sigue igual que antes. Bueno, a ver, vamos a ver el efecto del video. Le cuesta, le cuesta compilar a la primera. Bueno, el efecto del video de main funciona perfecto. Vamos a cortar la ejecución, cerramos, vamos de vuelta a video performance, npm run dev. Compila abrimos. [música] Y vamos a ver que no, que acá en, en lo que hizo Claude realmente no hay una mejora, sino que hay una peor, un, un, un deterioro y encima Bueno, mientras tanto vamos a ver lo que hizo Codex. A desplegar lo que hizo Codex. [música] Bueno, esto tiene que seguir igual, está bien, eh, vamos al laboratorio. Y bueno, el efecto ese que había, eh, volvió a estar. [música] Ahí me gusta cómo quedó, vamos a fusionar ya los cambios de este worktree y esta rama en main y luego vamos a pushearlas al repositorio. Vamos preguntarle si ya hizo los commits a Codex. Hice cuatro commits en locales en mejor información. Bueno, entonces ya tenemos hechos los commits. Bueno, mientras Claude va mejorando eso, eh yo lo que voy a hacer es los cambios ya de de Codex los voy a merchear. Entonces, [música] hacemos Git switch main. Bueno, me está diciendo que eh main está siendo usado por otro work tree. Entonces, vamos directamente a merchear. Vamos a hacer Git merge y vamos a poner mejora información. [música] Acá nos pide como un mensaje para merchear la rama. Vamos a ponerle mejora. Bueno, acá eh estamos mercheando. Le damos un escape y hacemos un WQ para confirmar los cambios [música] y se mercheó. Entonces, ya tenemos todos los cambios [música] de lo que hicimos en mejora de información mercheados en nuestra [música] carpeta principal, la local, la que era la copia de main. Entonces, vamos a tener los cuatro commits de diferencia respecto a Origin main. Para ver eso, vamos a hacer un Git status [música] y dice tu rama está adelantada de origin main, que es el main de GitHub, [música] cinco commits. Entonces, nosotros ya todo lo que hicimos en la carpeta local, en el work tree, [música] mejor la información, ya lo fusionamos en la carpeta donde teníamos apuntando a main. Bueno, ahora que estamos en main, mientras Cloud está por detrás probando el scroll, Git work tree list.

Assistir ao vídeo original no YouTube

Assuntos: Agentes de IA. Publicado no YouTube em 2026-10-21.

Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.

Sobre git worktree

git worktree es el comando de Git para administrar varios árboles de trabajo conectados al mismo repositorio, lo que permite tener más de una rama abierta a la vez en carpetas distintas. Según la documentación oficial, el árbol creado con git init o git clone es el "worktree principal", y cada carpeta extra creada con git worktree add es un "worktree vinculado". En su forma más simple, git worktree add ../hotfix crea una rama nueva llamada hotfix y la abre en la carpeta ../hotfix; para trabajar en una rama que ya existe se usa git worktree add <carpeta> <rama>.

Por defecto, Git no deja crear un worktree con una rama que ya está abierta en otro worktree, salvo que se use la opción --force. Otros subcomandos útiles son git worktree list, que muestra cada carpeta con su commit y su rama; git worktree remove, para borrar un worktree vinculado cuando ya no se necesita; git worktree prune, que limpia los datos administrativos de worktrees que ya no existen; y git worktree lock, que evita que se limpie un worktree guardado, por ejemplo, en un disco externo o una carpeta de red. Git es un sistema de control de versiones distribuido creado por Linus Torvalds en 2005, distribuido bajo la licencia GPL versión 2 y mantenido por Junio C. Hamano, según el Wikidata.

Ficha técnica

• Comando: git worktree
• Función: Varios árboles de trabajo conectados al mismo repositorio
• Crear: git worktree add <carpeta> [<rama>]
• Listar: git worktree list
• Quitar y limpiar: git worktree remove · git worktree prune
• Proteger: git worktree lock / unlock
• Restricción por defecto: Una misma rama no puede estar abierta en dos worktrees (salvo con --force)
• Git: Creado por Linus Torvalds (2005), licencia GPL v2

Lee también

• 🤖 Orca ADE: ¡Tus Agentes de IA Trabajando en EQUIPO! | Demo Real.
• Taller de Skills para Agentes de IA desde cero: Claude Code, OpenCode, Codex, Cursor, VS Code...
• Así es un día real programando con agentes de IA y Claude Code (con cifras)

---

Fuentes y referencias: Documentación oficial de Git – git-worktree (en inglés) · Wikidata – Git (Q186055) · video del canal NR Labs en YouTube.