3. Comandos y flujo de trabajo

Las tres zonas de Git

Antes de los comandos hay que entender por dónde pasa un archivo. Git no guarda todo lo que modificas: tú eliges qué entra en cada commit, y para eso un cambio recorre tres zonas dentro de tu computador antes de llegar a GitHub.

Las zonas por las que pasa un archivo

flowchart LR
    A["1 · Directorio de trabajo<br/>tus archivos"] -->|git add| B["2 · Zona de preparación<br/>staging"]
    B -->|git commit| C["3 · Repositorio local<br/>historial .git"]
    C -->|git push| D["4 · Repositorio remoto<br/>GitHub"]
    D -->|git pull| A

#	Zona	Dónde está	Qué contiene	Cómo se llega
1	Directorio de trabajo	Tu carpeta del proyecto	Los archivos que ves y editas en VSCode	Editando y guardando archivos
2	Zona de preparación (staging)	Tu computador	La lista de cambios que elegiste para el próximo commit	git add
3	Repositorio local	La carpeta oculta .git	El historial completo: todos tus commits	git commit
4	Repositorio remoto	Los servidores de GitHub	El historial que los demás pueden ver y descargar	git push

Las tres primeras son las tres zonas de Git, y viven enteras en tu computador: funcionan sin internet. La cuarta, GitHub, es la única que está fuera, y por eso push y pull son los únicos comandos que necesitan conexión.

El recorrido de un cambio

Supongamos que editas index.html y agregas un menú:

1. Lo guardas en VSCode. El archivo cambió en el directorio de trabajo. Git lo nota (git status lo muestra en rojo, como modificado), pero todavía no lo ha guardado en ninguna parte.
2. git add index.html. El cambio pasa a la zona de preparación. Sigue sin estar en el historial: solo quedó anotado que este cambio entrará en el próximo commit. En git status ahora aparece en verde.
3. git commit -m "Agrega el menú". Git toma lo que había preparado y lo guarda como una versión en el repositorio local, con tu nombre, la fecha y el mensaje. Recién aquí el cambio es permanente y recuperable.
4. git push. Esa versión sube al repositorio remoto. Ahora existe fuera de tu computador: hay respaldo, y los demás pueden verla.

La flecha de vuelta, git pull, hace el camino inverso: baja de GitHub los commits que otros subieron y actualiza tu directorio de trabajo.

¿Por qué add y commit son dos pasos?

Porque la zona de preparación te deja elegir. Si tocaste cinco archivos pero solo dos corresponden a “arreglar el menú”, haces add de esos dos y commiteas; los otros tres quedan esperando para un commit aparte. Así cada commit cuenta una sola cosa, y el historial se puede leer.

Nada existe fuera de tu computador hasta el push

Un archivo modificado no está en ningún commit hasta que lo agregas (add) y lo confirmas (commit). Y un commit no está en GitHub hasta que lo subes (push). Si el computador falla entre medio, se pierde lo que no hayas subido.

Comandos comunes

git status

Muestra en qué estado está todo: qué archivos modificaste, cuáles están preparados para el próximo commit y cuáles Git todavía no conoce.

git status

Es el comando que más vas a usar

Ante cualquier duda sobre qué está pasando, git status te lo dice. Ejecútalo antes y después de cada comando mientras estás aprendiendo.

git diff

Muestra las líneas exactas que cambiaron respecto a la última versión guardada.

git diff

Sirve para revisar qué vas a subir antes de hacerlo. Se sale con q.

git add .

Prepara los archivos para el próximo commit. El punto significa “todo lo que hay en esta carpeta y sus subcarpetas”.

git add .

También puedes preparar un archivo específico:

git add index.html

git commit

Confirma los archivos preparados y los guarda en el historial con un mensaje.

git commit -m "Agrega el formulario de contacto"

La -m es el mensaje. Si la omites, Git abrirá un editor de texto en la terminal para que lo escribas.

El mensaje importa

Escribe qué cambió, no “cambios” o “avance”. Un buen mensaje permite encontrar después en qué commit se rompió algo.

Mal	Bien
cambios	Agrega validación al formulario de login
asdasd	Corrige el menú que se desarmaba en móvil
final	Cambia la paleta de colores del header

git push

Sube tus commits al repositorio remoto en GitHub.

git push

Hasta que no hagas push, tus commits existen solo en tu computador. Si el computador falla, se pierden.

git pull

Trae los cambios que estén en GitHub y no tengas en tu copia local.

git pull

Es imprescindible al trabajar en grupo, o cuando usas más de un computador.

git log

Muestra el historial de commits: quién hizo cada uno, cuándo y con qué mensaje.

git log --oneline

El --oneline deja un commit por línea, que es como se revisa normalmente:

ad36031 Agrega vista contacto
7804a64 Agrega la navbar a las tres vistas
9616f49 Estructura inicial del sitio

Ese código de siete caracteres del principio es el hash: el identificador único del commit. Se usa para referirse a un commit concreto en otros comandos.

Variantes útiles

Comando	Qué muestra
git log --oneline	Un commit por línea
git log --oneline -5	Solo los cinco últimos
git log --oneline --graph	Dibuja las ramas y las fusiones
git log --author="Ana"	Solo los commits de esa persona

Se sale con q, igual que git diff.

Esto es lo que se revisa de tu entrega

git log es literalmente la vista que abre el profesor al corregir. Un historial repartido en el tiempo, con mensajes que explican qué cambió, se lee solo. Un único commit gigante el día de la entrega también se nota, y juega en contra.

git clone

Descarga un repositorio completo por primera vez. Ya lo viste en la página anterior.

git clone https://github.com/tu-usuario/tu-proyecto.git

Tabla resumen

Comando	Qué hace	Cuándo lo usas
git status	Muestra el estado actual	Todo el tiempo
git diff	Muestra las líneas que cambiaron	Antes de hacer commit
git add .	Prepara los cambios	Antes de cada commit
git commit -m "…"	Guarda una versión en el historial	Al terminar algo que funciona
git push	Sube los commits a GitHub	Al terminar de trabajar
git pull	Baja los commits de GitHub	Al empezar a trabajar
git clone <url>	Descarga un repositorio completo	Una vez por proyecto
git log --oneline	Muestra el historial de commits	Para revisar qué se hizo y cuándo
git restore <archivo>	Descarta los cambios de un archivo	Cuando algo salió mal y quieres volver atrás
git restore --staged <arch>	Saca un archivo de la preparación	Cuando hiciste add de algo de más

Deshacer cambios

Esta es la razón de fondo para versionar: nada de lo que guardaste se pierde. El comando que necesitas depende de en qué zona esté el cambio que quieres deshacer.

Qué comando deshace qué, según la zona

 Directorio          Zona de              Repositorio
 de trabajo          preparacion          local
     |                    |                    |
     |<-- git restore ----|                    |
     |     --staged       |                    |
     |                    |                    |
     |<------------- git restore <arch> -------|
     |                                         |
     |<------------- git reset --hard ---------|
     |               (PELIGROSO)               |

Descartar los cambios de un archivo

Editaste index.html, no te gustó, y quieres volver a como estaba en el último commit:

git restore index.html

git restore borra tu trabajo sin preguntar

Los cambios que descarta no estaban en ningún commit, así que no hay forma de recuperarlos. Ejecuta git diff antes para ver exactamente qué vas a perder.

Sacar un archivo de la zona de preparación

Hiciste git add . y te diste cuenta de que un archivo no debía entrar en este commit:

git restore --staged archivo.txt

El archivo vuelve al directorio de trabajo con tus cambios intactos: solo deja de estar marcado para el próximo commit. Esto es seguro.

Deshacer el último commit

Te equivocaste en el mensaje, o commiteaste algo de más:

# Deshace el commit pero CONSERVA los cambios, listos para volver a commitear
git reset --soft HEAD~1
 
# Deshace el commit y saca los cambios de la zona de preparación,
# pero los archivos siguen modificados
git reset HEAD~1

HEAD~1 significa “un commit antes del actual”.

git reset --hard borra todo sin vuelta atrás

git reset --hard HEAD~1   # NO lo uses mientras aprendes

Deshace el commit y borra los cambios de los archivos. Es el comando con el que más trabajo se ha perdido en la historia de Git.

Si dudas, no lo uses: git reset --soft deshace el commit y te deja todo el trabajo a mano.

No hagas reset de un commit que ya subiste

Si el commit ya está en GitHub y lo deshaces en tu copia, los dos historiales quedan distintos y el push siguiente será rechazado. Para eso existe git revert, que en vez de borrar el commit crea otro que lo anula:

git revert <hash-del-commit>

Resumen de deshacer

Situación	Comando	¿Se pierde trabajo?
Descartar cambios de un archivo	git restore <archivo>	Sí
Sacar un archivo del staging	git restore --staged <archivo>	No
Deshacer el último commit, conservando el trabajo	git reset --soft HEAD~1	No
Deshacer el último commit y el trabajo	git reset --hard HEAD~1	Sí
Anular un commit ya subido	git revert <hash>	No

Dos archivos que todo repositorio lleva

.gitignore

Hay archivos que no deben subir a GitHub: los que genera el sistema, los que produce la compilación, y sobre todo los que llevan contraseñas.

El archivo .gitignore se crea en la raíz del proyecto, con un patrón por línea, y Git ignora todo lo que coincida: no aparece en git status ni lo toma git add ..

# Archivos del sistema
.DS_Store
Thumbs.db

# Carpetas de dependencias
node_modules/

# Ejecutables compilados
*.out
*.exe

# Configuración con contraseñas
config/credenciales.php

Patrón	Qué ignora
archivo.txt	Ese archivo exacto, esté donde esté
carpeta/	Esa carpeta entera y todo lo de dentro
*.out	Todos los archivos con esa extensión
# comentario	Nada: es una nota para quien lee el archivo

Una contraseña subida a GitHub sigue ahí aunque la borres

El historial guarda todas las versiones. Si subes un archivo con la clave de la base de datos y al commit siguiente lo borras, la clave sigue en el historial y cualquiera puede recuperarla. La única salida real es cambiar la contraseña.

En la Unidad 2, cuando aparezca la conexión a PostgreSQL, esto deja de ser teórico.

.gitignore no saca lo que ya estaba subido

Solo afecta a archivos que Git todavía no sigue. Si el archivo ya tiene commits, hay que sacarlo a mano:

git rm --cached archivo.txt

El --cached lo saca del repositorio pero lo deja en tu carpeta.

README.md

Es la portada del repositorio: GitHub lo muestra automáticamente al entrar. Está escrito en Markdown, el mismo formato de estos apuntes.

# Trabajo 1 (Sitio personal)
 
Sitio estático de tres vistas para el ramo Diseño Web, UMAG 2026.
 
## Cómo verlo
 
Abre `index.html` con Live Server desde VSCode.
 
## Estructura
 
- `index.html` (portada, con la tabla de actividades)
- `sobre-mi.html` (presentación y galería)
- `contacto.html` (formulario de contacto)
- `img/` (imágenes del sitio)
 
## Autores
 
- Ana Soto
- Beto Díaz

Qué tiene que responder un README

Qué es el proyecto, cómo se ejecuta y quién lo hizo. Con eso basta. Es lo primero que ve quien corrige, y en los trabajos grupales es donde se declara quién es quién.

Flujo de trabajo con Git

Este es el ciclo de un día cualquiera de trabajo:

El ciclo de un día de trabajo

flowchart LR
    A([Empiezas]) --> B["git pull<br/>traer cambios"]
    B --> C["Programas"]
    C --> D["git add .<br/>preparar"]
    D --> E["git commit -m<br/>guardar"]
    E --> F["git push<br/>subir"]
    F --> G([Listo])
    E -.->|sigues trabajando| C

En comandos:

git pull                              # 1. Traes lo que haya nuevo
# ... programas ...
git status                            # 2. Revisas qué cambiaste
git add .                             # 3. Preparas los cambios
git commit -m "Agrega la galería"     # 4. Guardas la versión
git push                              # 5. Subes a GitHub

Empieza siempre con pull, termina siempre con push

El pull del principio evita conflictos: partes desde la versión más reciente. El push del final evita perder trabajo y, en este curso, es lo que registra la fecha de tu entrega.

Commits pequeños y frecuentes

No esperes a terminar todo para hacer un commit. Cada vez que algo funcione, aunque sea pequeño, haz commit. Así el historial cuenta la construcción del proyecto y siempre tienes un punto seguro al que volver.

Checkpoint

Intenta responder antes de desplegar cada pregunta.

¿Cuáles son las tres zonas de Git y qué comando lleva a cada una?

1. Directorio de trabajo (tu carpeta del proyecto, los archivos que editas).
2. Zona de preparación (staging) (lo que elegiste para el próximo commit; se llega con git add).
3. Repositorio local (el historial dentro de la carpeta .git; se llega con git commit).

Las tres están en tu computador y funcionan sin internet. GitHub es una cuarta ubicación, fuera de tu máquina, y se llega a ella con git push.

¿Cuál es el flujo normal para subir cambios al repositorio?

git pull                              # 1. Traes lo que haya nuevo
# ... programas ...
git status                            # 2. Revisas qué cambiaste
git add .                             # 3. Preparas los cambios
git commit -m "Agrega la galería"     # 4. Guardas la versión
git push                              # 5. Subes a GitHub

Siempre se empieza con pull y se termina con push.

¿Qué diferencia hay entre git add y git commit?

git add prepara: marca qué archivos van a entrar en la próxima fotografía, pero todavía no guarda nada en el historial. git commit confirma: toma lo preparado y lo guarda como una versión, con su mensaje.

Son dos pasos y no uno porque así puedes elegir qué entra en cada commit, en vez de verte obligado a guardar todo lo que tocaste.

¿Dónde están tus commits si hiciste commit pero no push?

Solo en tu computador, dentro de la carpeta .git del proyecto. Nadie más los ve y, si el computador falla, se pierden. En este curso además significa que la entrega no quedó registrada: la fecha la marca lo que está en GitHub.

¿Por qué conviene empezar la sesión con git pull?

Porque parte tu trabajo desde la versión más reciente. Si empiezas sin hacer pull y alguien subió cambios mientras tanto, al intentar hacer push Git te lo rechazará, y si ambos tocaron las mismas líneas tendrás un conflicto que resolver.

¿Qué muestra git log --oneline y para qué sirve el hash?

Muestra el historial de commits, uno por línea: el hash, y el mensaje. El hash es el código de siete caracteres del principio, el identificador único de ese commit, y es con lo que te refieres a él en otros comandos (git revert <hash>).

Es literalmente la vista que abre el profesor al corregir tu entrega.