> ## Documentation Index > Fetch the complete documentation index at: https://docs.jelou.ai/llms.txt > Use this file to discover all available pages before exploring further. # Ramas > Trabaja en una rama sin tocar el borrador del proyecto: publica commits inmutables, decide qué rama corre cada canal y promueve tu trabajo a producción cuando esté listo. Por defecto, tu directorio local lee el **borrador** del proyecto: las mismas filas que edita Studio, vivas y mutables. Con ramas puedes trabajar contra una versión publicada en su lugar, probar en un canal aparte y llevar el resultado a producción cuando esté listo, sin que nadie más vea el trabajo a medias. Una **rama** guarda commits. Un **commit** es una foto inmutable de todos los workflows del proyecto, y es lo que un canal sirve a tus usuarios. Esta página asume que ya vinculaste el directorio con `jelou link` y bajaste los workflows con `jelou pull`. Si aún no lo hiciste, empieza por [Proyectos y canales](/guides/cli/project). ## Los dos orígenes Tu directorio lee de un solo lugar a la vez, y `jelou status` lo dice en la primera línea. | Origen | Qué es | Quién lo ve | | - | - | - | | **Borrador** | Las filas vivas que edita Studio | Solo se publica con `jelou project publish` | | **Rama** | El commit de cabeza de esa rama | Los canales apuntados a esa rama | El borrador es el origen por defecto y es lo que describe el resto de la documentación del CLI. Todo lo de abajo es lo que cambia cuando trabajas en una rama. ## Moverte entre orígenes ```bash theme={null} jelou checkout dev # lee la rama dev jelou checkout draft # vuelve al borrador jelou checkout -b nueva-rama # crea una rama desde donde estás jelou branch list # qué ramas existen y cuál lees ``` `jelou checkout ` reescribe tus archivos con lo que esa rama sirve. Por eso se niega si tienes ediciones sin publicar: súbelas primero, o descártalas con `jelou pull --accept-server`. `jelou checkout -b ` es la excepción y no toca ningún archivo. Crea la rama desde el commit que estás leyendo y se lleva tu trabajo en progreso, así que es la forma de decir "esto que tengo a medias va a ser una rama". `draft` es un nombre reservado, para que `jelou checkout draft` no sea ambiguo. No puedes crear una rama con ese nombre. ## Publicar en una rama Estando en una rama, `jelou push` cambia de significado: en lugar de escribir el borrador, **publica un commit** y mueve la rama hacia él. ```bash theme={null} jelou push -m "menú de pedidos" # publica los archivos modificados jelou push --dry-run # muestra qué publicaría ``` Tres cosas que conviene saber: * **El borrador no se toca.** Nada de lo que publiques en una rama aparece en Studio hasta que promuevas a la rama que Studio lee. * **Solo se envía lo modificado.** Los workflows y canales que no tocaste conservan la versión que la rama ya servía, así que publicar un archivo produce un commit completo igual. * **El nombre del commit es obligatorio.** Úsalo para saber qué contiene cuando lo veas en el historial. `jelou push` se niega si la rama avanzó desde tu último `pull`. Alguien más publicó mientras tanto y tu commit se construiría encima de trabajo que no has visto. Haz `jelou pull`, revisa y vuelve a intentar. ### Conversaciones en curso Publicar mueve las conversaciones que están a mitad de camino a la versión nueva en su siguiente turno. Si prefieres que terminen con la versión con la que empezaron, publica con `--keep-pinned`. ```bash theme={null} jelou push -m "hotfix" --keep-pinned ``` Solo aplica al publicar a `master`, porque el ajuste es del proyecto entero y no de una rama en particular. ## Llevar el trabajo a otra rama ```bash theme={null} jelou promote master # master sirve el commit que estás leyendo jelou promote master -m "Release 12" ``` `jelou promote` hace que otra rama sirva el commit en el que estás. La promoción aparece en el historial de la rama destino con su propio identificador, y tu directorio no cambia: sigues en tu rama, en tu commit. El commit del destino recibe un identificador distinto al de origen. Es una copia, no el mismo commit apuntado desde dos lados, y por eso queda registrado en la historia de ambas ramas. Se niega si tienes trabajo local que el commit no contiene — estarías promoviendo algo distinto de lo que ves en pantalla. Publica primero, o usa `--allow-dirty` si de verdad quieres promover lo publicado y dejar tus ediciones donde están. ## Qué rama corre cada canal Esto es independiente de lo que lee tu directorio. Un canal puede estar sirviendo `master` mientras tú trabajas en `dev`. ```bash theme={null} jelou channels list --project 01H2XCEJQTG2H5V5NKCYW3J7Z2 jelou channels set-branch 01H2XCEJQTG2H5V5NKCYW3J7Z2 dev ``` La columna **Branch** del listado muestra qué corre cada canal. En gris significa que nunca se fijó, así que sigue `master`. `set-branch` surte efecto de inmediato en las conversaciones nuevas. Se niega si la rama no tiene nada publicado todavía. Apunta un canal de pruebas a tu rama y deja los de producción en `master`. Así pruebas con mensajes reales sin que ningún usuario vea el cambio. ## Probar una rama en el número productivo Apuntar el sandbox a tu rama sirve cuando el proyecto todavía no tiene un número real, o cuando no importa desde qué número llegan los mensajes. Cuando lo que quieres probar es el número que ya usan tus clientes, `branch-testers` deja que **un teléfono concreto** corra la rama mientras todos los demás siguen en la que sirve el canal. ```bash theme={null} jelou channels branch-testers add 01H2XCEJQTG2H5V5NKCYW3J7Z2 promo-navidad --phone +14155550100 jelou channels branch-testers list 01H2XCEJQTG2H5V5NKCYW3J7Z2 jelou channels branch-testers remove 01H2XCEJQTG2H5V5NKCYW3J7Z2 --phone +14155550100 --yes ``` `add` hace las mismas comprobaciones que `set-branch`: el canal debe estar integrado en el proyecto de tu directorio y la rama debe tener algo publicado. Surte efecto en el siguiente mensaje de ese teléfono, y su conversación empieza de cero en la rama. Registrar el mismo teléfono en otra rama lo mueve. Con `--expires-in ` la asignación termina sola; sin él, dura hasta que la quites con `remove`. `list` muestra qué teléfono corre qué rama y hasta cuándo. Para devolver el teléfono a la rama del canal, quítalo con `remove`: desde su siguiente mensaje vuelve a correr lo que sirve el canal, normalmente `master`, igual que el resto de usuarios. Aplica a proyectos que publican por ramas. Si la compañía tiene auto-publicación activa, producción sirve el borrador y ninguna rama corre, ni la del canal ni la del tester. Un `FORBIDDEN` en `add` significa que el token no pertenece a la compañía dueña del bot. Si el teléfono es tester del sandbox del proyecto, `add` le quita también la marca de borrador a esa asignación, porque un tester de borrador ejecuta el borrador y nunca llega a la rama; al quitarlo de la rama seguirá en lo publicado, no en el borrador. Un workflow que solo exista en la rama no se alcanza por intención del usuario, porque el enrutamiento por intenciones es del proyecto completo; sí se ejecuta la versión de la rama de los workflows que también existen en `master`, y el workflow por defecto. ## Un ciclo completo La rama sale del commit que estás leyendo y se lleva tu trabajo en progreso. ```bash theme={null} jelou checkout -b promo-navidad # edita workflows/*.json jelou workflow validate ``` ```bash theme={null} jelou push -m "promoción de navidad" ``` El borrador no se toca: nada de esto aparece en Studio todavía. ```bash theme={null} jelou channels set-branch 01H2XCEJQTG2H5V5NKCYW3J7Z2 promo-navidad ``` Escríbele al canal y verifica el comportamiento con mensajes reales. Repite los pasos anteriores hasta que quede como quieres. ```bash theme={null} jelou promote master -m "Promo navidad" ``` Ahora `master` sirve el mismo commit que probaste. ```bash theme={null} jelou channels set-branch 01H2XCEJQTG2H5V5NKCYW3J7Z2 master ``` Así vuelve a seguir producción y queda libre para la siguiente rama. ## Una rama sin nada publicado Un proyecto nuevo nace con `master` vacía, y crear una rama desde ahí es perfectamente válido. Tu directorio queda apuntando a una rama sin commits — `jelou status` lo llama *nothing published yet* — y el primer `jelou push` escribe su commit inicial. Leer una rama vacía no es un error. Distinto es pedir una rama que no existe, que sí falla. ## Qué necesita el borrador Estos comandos escriben el borrador, así que se niegan mientras leas una rama. Vuelve con `jelou checkout draft` para usarlos. | Comando | Por qué | | - | - | | `jelou project publish` | Publica el **borrador**, no tus archivos: reemplazaría lo que acabas de publicar en la rama | | `jelou incoming accept-local` | Despacha tu archivo contra el borrador | | `jelou incoming accept-server` | Resuelve un conflicto capturado contra el borrador | | `jelou status --check-remote` | Solo esta bandera; `jelou status` a secas funciona en ambos orígenes | Después de un `jelou push` en una rama no hay nada más que ejecutar: el commit existe y la rama ya apunta a él. Al revés también aplica: `jelou promote` necesita estar en una rama, porque el borrador no tiene ningún commit que promover. ## Workflows en TypeScript Si adoptaste un workflow a TypeScript con `jelou workflow adopt`, ese archivo es la fuente y el CLI nunca escribe JSON encima, ni siquiera al cambiar de rama. Cuando el `.ts` difiere de lo que la rama sirve, `jelou pull` te lo dice y `jelou status` lo marca como modificado. A partir de ahí decides: * **Publicar el tuyo** — `jelou push`, que lo sube como un commit nuevo. * **Quedarte con el de la rama** — borra el `.ts` y vuelve a hacer `jelou pull`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.