Áreas de trabajo en GIT

Comprender las áreas de trabajo de Git es fundamental para aprender a utilizar esta herramienta correctamente. En esta guía descubrirás qué es el Working Directory, el Staging Area y el Local Repository, cómo se relacionan entre sí y cómo intervienen en cada cambio que realizas hasta crear un commit.

1. Working Directory (Directorio de trabajo)

1.1. ¿Qué es?

El Working Directory o Directorio de trabajo es la carpeta de tu proyecto donde creas, editas, modificas y eliminas archivos. Es el lugar donde realizas todo tu trabajo antes de indicarle a Git qué cambios quieres guardar.

En otras palabras, es el espacio donde escribes código, agregas nuevos archivos o realizas cualquier modificación en el proyecto. Cada vez que cambias un archivo, Git detecta esas modificaciones dentro del Working Directory.

Por ejemplo, si tienes un proyecto con esta estructura:

mi-proyecto/
│
├── index.html
├── style.css
├── script.js
└── imagen.png

Todos esos archivos forman parte del Working Directory.

1.2. ¿Para qué sirve el Working Directory?

Sirve para desarrollar y modificar el proyecto antes de guardar una nueva versión en Git.

Aquí puedes:

• Crear nuevos archivos.
• Editar archivos existentes.
• Eliminar archivos.
• Renombrar archivos y carpetas.
• Probar cambios antes de decidir si formarán parte del próximo commit.

Es importante entender que los cambios que haces en el Working Directory todavía no forman parte del historial de Git. Primero debes revisarlos y luego agregarlos al Staging Area mediante git add.

1.3. ¿Dónde lo encuentro en Visual Studio Code?

En Visual Studio Code, el Working Directory corresponde a la carpeta del proyecto que tienes abierta.

Por ejemplo, si abriste una carpeta llamada GIT, todo su contenido representa el Working Directory.

Lo encontrarás principalmente en dos lugares:

1.3.1. Explorador de archivos (Explorer)

Es el panel ubicado en el lado izquierdo de VS Code.

Aquí puedes ver todos los archivos y carpetas del proyecto, crear nuevos archivos, modificarlos o eliminarlos.

EXPLORADOR

📁 GIT
│
├── index.html
├── style.css
├── script.js
└── README.mdLenguaje del código: CSS (css)

Este panel representa visualmente tu Working Directory.

1.3.2. Editor de código

Cuando abres un archivo, por ejemplo index.html, y comienzas a escribir:

<h1>Hola Git</h1>
<p>Aprendiendo Git</p>Lenguaje del código: HTML, XML (xml)

estás modificando un archivo dentro del Working Directory.

Todavía esos cambios no han sido preparados para un commit.

1.4. ¿Cómo sabe Git que hubo cambios?

Git compara el estado actual del Working Directory con el último commit guardado.

Puedes comprobarlo ejecutando:

git status

Si modificaste index.html, Git mostrará algo parecido a:

Changes not staged for commit:

modified: index.htmlLenguaje del código: CSS (css)

Esto significa que el archivo fue modificado en el Working Directory, pero todavía no fue agregado al Staging Area.

1.5. Relación del Working Directory con las demás áreas de Git

El Working Directory es el primer paso dentro del flujo de trabajo de Git.

Working Directory
        │
        │ (Modificas archivos)
        ▼
Staging Area
        │
        │ (git add)
        ▼
Local Repository
        │
        │ (git commit)
        ▼
Remote Repository
        │
        │ (git push)
        ▼
GitHub

Todo comienza en el Working Directory. Cada cambio que realices en tu proyecto se hace primero aquí y, solo cuando tú lo decides, pasa al Staging Area y luego al repositorio mediante un commit. Por eso, comprender esta área es fundamental para entender cómo funciona Git desde el inicio.

2. Staging Area (Área de preparación o índice)

2.1. ¿Qué es?

El Staging Area, también conocida como Área de preparación o Índice, es una zona intermedia entre el Working Directory y el Repositorio local. Su función es permitirte seleccionar exactamente qué cambios quieres incluir en el próximo commit.

En otras palabras, el Staging Area actúa como una bandeja de preparación, donde colocas los archivos que estás listo para guardar como una nueva versión del proyecto.

POR EJEMPLO: Imagina que modificas tres archivos:

index.html
style.css
script.jsLenguaje del código: CSS (css)

No necesariamente quieres guardar los tres cambios al mismo tiempo. Gracias al Staging Area, puedes decidir cuáles formarán parte del siguiente commit y cuáles seguirán en desarrollo.

2.2. ¿Para qué sirve el Staging Area?

El Staging Area sirve para preparar y organizar los cambios antes de crear un commit.

Gracias a esta área puedes:

• Seleccionar únicamente los archivos que deseas guardar.
• Crear commits más organizados y fáciles de entender.
• Separar diferentes tareas en distintos commits.
• Revisar los cambios antes de incorporarlos al historial del proyecto.

Por ejemplo, supongamos que hiciste dos tareas diferentes:

• Corregiste un error en script.js.
• Cambiaste el diseño en style.css.

En lugar de guardar ambos cambios juntos, puedes preparar primero script.js para crear un commit relacionado con la corrección del error y, más tarde, preparar style.css para crear otro commit relacionado con el diseño.

Esto hace que el historial de Git sea mucho más claro y profesional.

2.3. ¿Dónde lo encuentro en Visual Studio Code?

En Visual Studio Code, el Staging Area se encuentra dentro del panel Control de código fuente (Source Control), identificado con el ícono de una rama de Git en la barra lateral izquierda.

Cuando abres ese panel, normalmente encontrarás dos secciones principales:

SOURCE CONTROL

Changes
│
├── index.html
├── style.css
└── script.js

Staged Changes
│
└── (Archivos preparados)Lenguaje del código: CSS (css)

Dependiendo de la versión de VS Code, los nombres pueden aparecer como Changes y Staged Changes o como Cambios y Cambios preparados.

2.4. ¿Cómo pasar un archivo al Staging Area?

Supongamos que modificas index.html.

Al ejecutar:

git status

Git mostrará:

Changes not staged for commit:

modified: index.htmlLenguaje del código: CSS (css)

Esto significa que el archivo todavía está únicamente en el Working Directory.

Para prepararlo utilizas:

git add index.htmlLenguaje del código: CSS (css)

o bien:

git add .

si deseas preparar todos los archivos modificados.

En VS Code puedes hacer exactamente lo mismo haciendo clic en el ícono «+» (Stage Changes) que aparece al lado del archivo dentro de la sección Changes.

Una vez hecho esto, el archivo dejará de aparecer en Changes y pasará a Staged Changes.

2.5. ¿Cómo quitar un archivo del Staging Area?

Si cambias de opinión y no quieres incluir un archivo en el próximo commit, puedes quitarlo del Staging Area.

Desde la terminal:

git restore --staged index.htmlLenguaje del código: CSS (css)

Desde VS Code, simplemente haz clic en el ícono «-» (Unstage Changes) que aparece junto al archivo dentro de Staged Changes.

NOTA! Es importante destacar que esta acción no elimina los cambios realizados en el archivo; únicamente deja de estar preparado para el próximo commit.

2.6. Relación con las demás áreas de Git

El Staging Area representa el segundo paso dentro del flujo de trabajo de Git.

Working Directory
        │
        │ Editas archivos
        ▼
Staging Area
        │
        │ git add
        ▼
Local Repository
        │
        │ git commit
        ▼
Remote Repository

Los cambios siempre comienzan en el Working Directory. Cuando decides que un archivo está listo para formar parte de una nueva versión, lo envías al Staging Area mediante git add o utilizando el botón Stage Changes de VS Code. Finalmente, al ejecutar git commit, Git toma únicamente los archivos que están en el Staging Area y crea un nuevo commit en el repositorio local.

2.7. Ejemplo práctico

Supongamos que modificas estos tres archivos:

index.html
style.css
script.jsLenguaje del código: CSS (css)

Inicialmente todos están en el Working Directory:

Working Directory

✔ index.html
✔ style.css
✔ script.jsLenguaje del código: CSS (css)

Luego decides preparar solo index.html y script.js:

git add index.html
git add script.jsLenguaje del código: CSS (css)

Ahora la situación es:

Working Directory

✔ style.css

──────────────

Staging Area

✔ index.html
✔ script.jsLenguaje del código: CSS (css)

Finalmente ejecutas:

git commit -m "Actualizar estructura HTML y lógica JavaScript"Lenguaje del código: JavaScript (javascript)

Git guardará únicamente index.html y script.js en el historial del proyecto. style.css permanecerá en el Working Directory esperando a que decidas cuándo incluirlo en otro commit.

IDEA CLAVE PARA RECORDAR:

Puedes pensar en el Staging Area como una bandeja de selección. Todo lo que modificas aparece primero en el Working Directory. Luego decides qué archivos colocar en esa bandeja mediante git add. Cuando haces un git commit, Git guarda únicamente los archivos que están dentro de esa bandeja, permitiéndote crear un historial limpio, organizado y fácil de mantener.

3. Local Repository (Repositorio local)

3.1. ¿Qué es?

El Local Repository o Repositorio local es la base de datos donde Git almacena el historial completo de tu proyecto. Cada vez que realizas un commit, Git guarda una nueva versión del proyecto dentro de este repositorio.

En otras palabras, el repositorio local es el lugar donde Git registra todas las versiones del proyecto, permitiéndote volver a cualquier commit anterior, comparar cambios, crear ramas o recuperar versiones antiguas.

A diferencia del Working Directory, donde editas los archivos, y del Staging Area, donde preparas los cambios, el Local Repository es donde esos cambios quedan almacenados de forma permanente (hasta que decidas modificarlos con comandos como git reset).

3.2. ¿Para qué sirve el Local Repository?

El repositorio local sirve para almacenar y administrar el historial completo del proyecto.

Gracias a él puedes:

• Guardar versiones del proyecto mediante commits.
• Consultar el historial de cambios.
• Volver a versiones anteriores.
• Crear y administrar ramas.
• Comparar diferentes versiones del proyecto.
• Recuperar cambios realizados en el pasado.

Lo más importante es que todo esto funciona sin conexión a Internet, ya que el repositorio está almacenado en tu propia computadora.

3.3. ¿Dónde se encuentra?

En tu servidor (computadora) local.

Cuando ejecutas por primera vez:

git init

Git crea automáticamente una carpeta oculta llamada:

.gitLenguaje del código: CSS (css)

Por ejemplo:

mi-proyecto/
│
├── .git
├── index.html
├── style.css
└── script.js

La carpeta .git contiene toda la información del repositorio local, y como dijimos se encuentra en tu computadora, si vas a la carpeta donde empezaste tu proyecto encontrarás esta nueva carpeta .git.

Dentro de ella Git guarda:

• Todos los commits.
• Las ramas (branches).
• Las etiquetas (tags).
• La configuración del repositorio.
• El historial completo del proyecto.
• Los objetos internos que representan cada versión de los archivos.

Por esta razón, nunca deberías modificar manualmente el contenido de la carpeta .git, ya que podrías dañar el repositorio.

3.4. ¿Dónde lo encuentro en VS Code?

A diferencia del Working Directory y del Staging Area, el Local Repository no tiene un panel específico en VS Code.

Se representa principalmente a través del historial de commits.

Puedes acceder a él de varias maneras.

3.4.1. Desde la terminal integrada

Puedes visualizar el historial con:

git log

o una versión resumida:

git log --oneline

Cada commit que aparece proviene del repositorio local.

Por ejemplo:

f8c12d3 Agregado botón
d72ab45 Agregado párrafo
a81fe20 Primer commit

3.4.2. Desde la extensión Git de VS Code

En el panel Source Control, después de realizar commits, podrás ver el historial utilizando la vista de historial integrada (según la versión de VS Code) o instalando una extensión como Git Graph, que muestra gráficamente todos los commits almacenados en el repositorio local.

3.4.3. Explorando la carpeta .git

Si habilitas la visualización de archivos ocultos, podrás ver:

.gitLenguaje del código: CSS (css)

Sin embargo, normalmente no necesitas abrirla, ya que Git administra automáticamente todo su contenido.

3.5. ¿Cómo llegan los cambios al Local Repository?

Supongamos que modificas index.html.

Inicialmente el cambio está en el Working Directory.

Working Directory

✔ index.html (modificado)Lenguaje del código: CSS (css)

Luego preparas el archivo:

git add index.htmlLenguaje del código: CSS (css)

Ahora pasa al Staging Area.

Finalmente ejecutas:

git commit -m "Actualizar encabezado principal"Lenguaje del código: JavaScript (javascript)

En ese momento Git guarda una nueva versión del proyecto dentro del repositorio local.

3.6. Relación con las demás áreas de Git

El repositorio local representa la tercera etapa del flujo de trabajo de Git.

Working Directory
        │
        │ Editas archivos
        ▼
Staging Area
        │
        │ git add
        ▼
Local Repository
        │
        │ git commit
        ▼
Historial del proyecto

Cuando posteriormente trabajes con GitHub, aparecerá una cuarta etapa:

Working Directory
        │
        ▼
Staging Area
        │
        ▼
Local Repository
        │
        │ git push
        ▼
Remote Repository (GitHub)

3.7. Ejemplo práctico

Supongamos que comienzas un proyecto.

Primer commit

git add .
git commit -m "Primer commit"Lenguaje del código: JavaScript (javascript)

Git crea la primera versión del proyecto.

Segundo commit

Agregas un título:

<h1>Hola Git</h1>Lenguaje del código: HTML, XML (xml)

Luego:

git add .
git commit -m "Agregar título principal"Lenguaje del código: JavaScript (javascript)

Git almacena una segunda versión.

Tercer commit

Agregas un botón:

<button>Enviar</button>Lenguaje del código: HTML, XML (xml)

Después ejecutas:

git add .
git commit -m "Agregar botón"Lenguaje del código: JavaScript (javascript)

Ahora el repositorio local contiene tres versiones distintas del proyecto.

Visualmente sería algo como:

Repositorio local

Commit 3 → Agregar botón
      │
Commit 2 → Agregar título principal
      │
Commit 1 → Primer commit

Cada uno de esos commits está guardado dentro de la carpeta .git.

3.8. ¿Qué comandos trabajan directamente con el Local Repository?

Algunos de los comandos más importantes son:

Consultar el historial:

git log

Consultar el historial resumido:

git log --oneline

Ver un commit específico:

git show HASH

Viajar temporalmente a otro commit:

git checkout HASH

Deshacer un commit mediante uno nuevo:

git revert HASH

Mover el historial a un commit anterior:

git reset HASH

Todos estos comandos utilizan la información almacenada en el Local Repository

IDEA CLAVE PARA RECORDAR:

• Working Directory: el escritorio donde escribes y modificas tus archivos.
• Staging Area: una bandeja donde colocas únicamente los cambios que quieres guardar.
• Local Repository: un archivo histórico donde Git almacena todas las versiones del proyecto mediante commits.

Cada vez que ejecutas git commit, los cambios preparados en el Staging Area pasan al Local Repository, creando una nueva versión del proyecto que podrás consultar o recuperar en cualquier momento.

4. Ilustración de esta estructura de GIT en VS Code