También en: English, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano, हिन्दी · Todas las guías en español
Aviso: construimos Carbon Forge en 100monkeys.ai, así que lee esto como el relato de quien lo fabrica. Esta guía la redactó uno de nuestros agentes de IA a partir de la documentación pública, sobre todo los pasos 6 a 8 de Working in lanes y la página Lanes del catálogo, y la revisó la empresa; esta versión en español es una traducción de la guía original en inglés. Cada llamada es el propio ejemplo de la documentación, y las citas van en inglés con la traducción al lado. Donde la documentación deja una pregunta abierta, la última sección lo dice.
Paso 1. Entiende qué cuenta como conflicto
Una lane es un conjunto de parches sobre el trunk, y cada lectura en ella compone el trunk tal como está ahora con esos parches. Un parche está en conflicto "when it no longer applies to the trunk: its old text no longer matches or matches twice" (cuando ya no se aplica al trunk: su texto antiguo ya no coincide o coincide dos veces), o el trunk cambió una entrada de árbol o de biblioteca que el parche reemplazaba. Un parche que todavía se aplica no es un conflicto aunque el trunk haya cambiado la misma sección; la lectura lo informa como sección movida, "worth a reviewer's look, not a conflict." (merece una mirada de quien revisa, no es un conflicto). Dos agentes que cambian partes distintas de un mismo archivo integran los dos. Y la regla que sigue el resto de esta guía: "Nothing merges by itself." (Nada se fusiona solo).
Paso 2. Date cuenta de que una lane está en conflicto
lanes.get responde landable, que solo es verdadero para una lane abierta con al menos un parche vivo y ningún conflicto. En la aplicación, la página de la lane en /<workspace>/lanes/<label> tiene una pestaña Conflicts. Sin sondear, un evento de webhook lane.conflict nombra la lane y las rutas de sus filas en conflicto cuando una integración en el trunk la pone en conflicto por primera vez.
Paso 3. Lee el conflicto
lanes.conflicts { "label": "agent/7/fix-login" } Cada fila lleva lo que necesita quien fusiona: el parche; la sección tal como estaba cuando se tomó el parche; la sección del trunk ahora; la vista compuesta de la lane; y los changesets que la movieron, cada uno con su intención, su autor y la lane que lo integró. Para un árbol de código la fila añade un diff unificado de cada archivo en conflicto y, para un lenguaje con gramática, una lista orientativa de las definiciones de nivel superior que difieren, que "decides nothing" (no decide nada). La herramienta es de solo lectura y solo necesita el rol de lector. En la aplicación, la pestaña Conflicts muestra el texto del trunk y el de la lane con la llamada exacta para responder a cada uno, "ready to copy, while the page itself decides nothing." (lista para copiar, mientras la página en sí no decide nada).
Paso 4. Responde a un conflicto de texto
lanes.resolve { "patch_id": "…", "note": "kept both sign-in options", "old_string": "…", "new_string": "…" } La respuesta es un parche nuevo con una nota de 1 a 1.024 caracteres que dice por qué. Se "matched against the trunk as it stands now and bound to the hash of that state." (compara con el trunk tal como está ahora y se liga al hash de ese estado). El parche anterior se conserva como historial, marcado superseded. Un conflicto de árbol se responde igual con upserts, removals o patches, y una entrada de biblioteca con un sha256. Responde en orden: un parche posterior sobre la misma entidad espera hasta que se resuelve el anterior.
Paso 5. O descarta el parche
lanes.drop_patch { "patch_id": "…" } Cuando el trunk ya hizo lo que el parche pretendía, o el parche ya no se quiere, descártalo. Donde la entidad sobre la que se tomó el parche ya no existe, el rechazo de la documentación dice que descartes el parche en lugar de resolverlo.
Paso 6. Responde a un conflicto de movimiento
lanes.resolve { "patch_id": "…", "note": "kept the trunk's rename and moved on from it", "to_path": "guides/sign-in" } Una lane que renombra una página entra en conflicto cuando el trunk ha movido esa misma página desde entonces, cuando el trunk ya ocupa la ruta nueva o cuando la página ya no existe. Responde con to_path, y title donde el título deba cambiar. La resolución queda ligada a la ruta que el trunk tiene ahora, así que un movimiento posterior en el trunk también la deja obsoleta.
Paso 7. Responde a conflictos en trabajo ensamblado
lanes.merge { "from": "agent/8/tests", "into": "agent/7/fix-login", "intent": "assemble the login fix" } Un agente principal reúne las lanes de varios agentes en una antes de integrar. Un parche traído así entra en conflicto donde la lane receptora cambió lo mismo que él, y lanes.conflicts nombra, como moved_by, los parches anteriores de la lane receptora sobre los que ahora se apoya. Su resolución responde a la vista de la lane receptora, no solo al trunk.
Paso 8. Integra, con una prueba en seco primero
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" } La integración se comprueba de nuevo dentro de su propia transacción y se rechaza entera, con cada conflicto nombrado, si algo se movió. Una resolución responde a un estado exacto del trunk; si el trunk mueve esa sección antes de la integración, la resolución queda obsoleta y la integración se rechaza con:
resolution <id> was resolved against <hash>; the trunk's section is now <hash> Entonces vuelve a leer lanes.conflicts y responde al estado nuevo. En un trunk protegido con reglas de integración, recuerda que cualquier resolución posterior a las aprobaciones hace que estas "count for nothing" (no cuenten para nada), así que la aprobación va después de la última respuesta. Envía la integración con una idempotency_key y un reintento tras un tiempo de espera agotado devuelve el resultado de la primera integración en lugar de integrar dos veces.
Para una lane que lleva un cambio de código y su documentación juntos, lee nuestra guía Integra un cambio de código y su documentación en un solo changeset.
Lo que la documentación deja sin responder
- Qué hacer cuando la sección base no se puede recuperar. La fila de conflicto retrocede como mucho 200 revisiones para encontrarla y si no informa
unknown; la documentación no dice cómo responder desde ahí. - Qué responde la integración con
dry_run. La guía muestra la llamada pero no su respuesta. - Qué lleva el evento
lane.conflictademás de la lane y las rutas.