---
title: Aislamiento del espacio de trabajo
description: "Aislamiento basado en worktrees de Git para experimentación paralela sin conflictos"
---

El aislamiento del espacio de trabajo es el sistema de Verdent para garantizar que el trabajo paralelo nunca interfiera consigo mismo. Cada espacio de trabajo es un entorno de trabajo completamente independiente, aislado a nivel del sistema de archivos mediante git worktrees.

---

## Lo que aprenderás

- Cómo el aislamiento del espacio de trabajo previene conflictos
- Cómo los git worktrees permiten el aislamiento
- La diferencia entre el espacio de trabajo base y los espacios de trabajo
- Cómo crear, cambiar y administrar espacios de trabajo
- Mejores prácticas para la administración de espacios de trabajo

---

## ¿Qué es el aislamiento del espacio de trabajo?

El aislamiento del espacio de trabajo garantiza que los cambios de una tarea nunca afecten a otra. Prueba diferentes enfoques en paralelo, compara los resultados y rebasa selectivamente solo los cambios que quieras de vuelta a la rama principal.

### Cómo funciona

| Capa | Cómo funciona |
|-------|--------------|
| **Directorio** | Cada espacio de trabajo es un directorio aislado |
| **Rama** | Cada espacio de trabajo tiene su propio checkout de rama |
| **Archivos** | Los cambios de archivos en un espacio de trabajo no afectan a otros |
| **Staging** | Cada espacio de trabajo tiene su propia área de staging |

### Beneficios

<CardGroup cols={2}>
  <Card title="Cero interferencia" icon="shield-halved">
    Los agentes paralelos no pueden entrar en conflicto, es físicamente imposible
  </Card>
  <Card title="Experimentación segura" icon="flask">
    Prueba cambios arriesgados sin afectar el código estable
  </Card>
  <Card title="Comparación clara" icon="code-compare">
    Usa git diff para comparar enfoques entre espacios de trabajo
  </Card>
  <Card title="Rebase selectivo" icon="code-merge">
    Rebasa solo los resultados en los que confías
  </Card>
</CardGroup>

---

## Espacio de trabajo base frente a espacios de trabajo

### Espacio de trabajo base

El espacio de trabajo base es el checkout original de tu repositorio y sirve como punto de partida predeterminado.

| Característica | Descripción |
|----------------|-------------|
| **Ubicación** | La ubicación original de tu git clone o init |
| **Rama principal** | Normalmente en la rama main o de desarrollo |
| **Punto de referencia** | Fuente para comparar el trabajo experimental |

**Cuándo usar el base:**
- Cambios rápidos que no necesitan aislamiento
- Punto de referencia para comparar el trabajo experimental
- Cuando quieres que los cambios vayan directamente a la rama principal
- Tareas simples donde no se necesita ejecución paralela

### Espacio de trabajo

Un espacio de trabajo es un entorno de trabajo aislado creado con git worktrees, con su propio checkout de rama independiente y su propio estado de archivos.

**Cuándo usar un espacio de trabajo:**
- Desarrollo de funciones en paralelo
- Experimentación con cambios arriesgados
- Trabajo en múltiples tareas simultáneamente
- Cuando quieres aislamiento antes de rebasar

---

## Crear y administrar espacios de trabajo

### Crear un nuevo espacio de trabajo

| Plataforma | Atajo |
|----------|----------|
| **macOS** | `Cmd+Shift+N` |
| **Windows** | `Ctrl+Shift+N` |

**Qué sucede:**
1. Verdent crea un directorio aislado de git worktree
2. Se crea una nueva rama (o se hace checkout de una rama existente)
3. El espacio de trabajo queda completamente aislado de los demás espacios de trabajo
4. El espacio de trabajo aparece en **All Workspaces** en la barra superior

### Cambiar entre espacios de trabajo

| Acción | macOS | Windows |
|--------|-------|---------------|
| **Siguiente espacio de trabajo** | `Ctrl+Tab` | `Ctrl+Tab` |
| **Espacio de trabajo anterior** | `Ctrl+Shift+Tab` | `Ctrl+Shift+Tab` |
| **Seleccionar espacio de trabajo** | Selecciona **All Workspaces** en la barra superior | Selecciona **All Workspaces** en la barra superior |

**Preservación del estado:**
- Verdent mantiene activos todos los estados de los espacios de trabajo
- Cambia al instante sin retrasos de configuración
- El contexto completo se conserva al cambiar

---

## Rebasar los cambios del espacio de trabajo

Cuando estés listo para integrar los cambios del espacio de trabajo de vuelta a la rama principal:

### Usar la interfaz de Verdent

<Steps>
  <Step title="Completa el trabajo">
    Completa el trabajo en el espacio de trabajo
  </Step>
  <Step title="Revisa los cambios">
    Selecciona **Task Changes** en el panel central para revisar todas las modificaciones
  </Step>
  <Step title="Rebasa a la rama principal">
    Selecciona **Workspace Actions → Rebase to main branch** en la barra del espacio de trabajo
  </Step>
  <Step title="Resuelve conflictos">
    Resuelve cualquier conflicto si se te solicita
  </Step>
  <Step title="Verifica">
    Revisa los cambios antes de confirmar
  </Step>
</Steps>

### Mantener los espacios de trabajo actualizados

Usa **Workspace Actions → Sync with main branch** para traer los últimos cambios de la rama principal a tu espacio de trabajo. Esto ayuda a prevenir conflictos grandes al rebasar.

---

## Mejores prácticas

### Convenciones de nomenclatura

| Práctica | Ejemplo |
|----------|---------|
| Nombres descriptivos | `feature-auth`, `bugfix-123`, `experiment-caching` |
| Incluir números de ticket | `JIRA-456-user-login` |
| Mantener nombres cortos | Evita nombres demasiado largos |

### Mantenimiento de los espacios de trabajo

| Práctica | Por qué |
|----------|-----|
| **Eliminar espacios de trabajo rebasados** | Libera espacio en disco |
| **Eliminar experimentos abandonados** | Mantén manejable la lista de espacios de trabajo |
| **Mantener un número razonable de espacios de trabajo** | Los recursos del sistema son finitos |

### Higiene de Git

| Práctica | Por qué |
|----------|-----|
| **Haz commits con frecuencia** | Haz commit del trabajo en curso antes de cambiar |
| **Commits pequeños** | Los commits más pequeños son más fáciles de hacer cherry-pick |
| **Sincroniza con el base regularmente** | No dejes que los espacios de trabajo se alejen demasiado de la rama principal |
| **Reduce la complejidad de los conflictos** | La integración regular previene conflictos grandes |

---

## Preguntas frecuentes

<AccordionGroup>
<Accordion title="¿Cuánto espacio en disco usa cada espacio de trabajo?">
Cada espacio de trabajo duplica los archivos de trabajo, pero comparte el directorio `.git`. El uso de espacio equivale aproximadamente al tamaño de tu proyecto por cada espacio de trabajo. Los proyectos grandes con muchos espacios de trabajo paralelos usarán una cantidad significativa de espacio en disco.
</Accordion>

<Accordion title="¿Puedo eliminar un espacio de trabajo?">
Sí. Elimina el espacio de trabajo a través de Verdent. Esto elimina el directorio, pero conserva cualquier trabajo del que se haya hecho commit en la rama.
</Accordion>

<Accordion title="¿Qué pasa con los cambios sin commit si elimino un espacio de trabajo?">
Los cambios sin commit se pierden cuando se elimina un espacio de trabajo. Haz siempre commit o stash de los cambios antes de eliminar un espacio de trabajo.
</Accordion>

<Accordion title="¿Puedo convertir un espacio de trabajo en el espacio de trabajo base?">
No hay una conversión directa, pero puedes rebasar todos los cambios del espacio de trabajo a la rama principal y luego eliminar el espacio de trabajo. El historial de la rama se conserva.
</Accordion>

<Accordion title="¿Los worktrees funcionan con todos los servicios de alojamiento de git?">
Sí. Los worktrees de Git son una función estándar de git. Funcionan con GitHub, GitLab, Bitbucket y cualquier otro servicio de alojamiento de git.
</Accordion>
</AccordionGroup>