Git

Tienes un commit hecho localmente y ejecutas uno u otro:

# Opcion A
git reset --soft HEAD~1

# Opcion B
git reset --hard HEAD~1

Predice: en cada caso, ¿qué pasa con el commit y, sobre todo, qué pasa con tus cambios?

Ambos deshacen el último commit (mueven la rama a HEAD~1), pero difieren en qué pasa con los cambios:

• git reset --soft HEAD~1: deshace el commit y conserva los cambios en el staging area. No se pierde nada; quedan listos para recommitear.
• git reset --hard HEAD~1: deshace el commit y borra los cambios del staging y del working directory. Se pierde ese trabajo.

reset mueve el puntero de la rama a otro commit. Lo que cambia es qué hace con el contenido: --soft lo deja en staging, --mixed (por defecto) lo deja sin stage en el working directory, y --hard lo elimina. Por eso --hard es peligroso: es la única variante que borra trabajo. Además, reset reescribe historia, así que solo debe usarse en commits locales no publicados.

# Opcion A
git fetch origin

# Opcion B
git pull origin main

Predice: ¿cuál de los dos modifica tu rama de trabajo actual y cuál no?

• git fetch origin: descarga los cambios del remoto y actualiza las ramas remotas (origin/main), pero NO modifica tu rama local ni tu working directory.
• git pull origin main: hace fetch y además integra los cambios en tu rama actual (por defecto con merge), así que sí modifica tu trabajo.

fetch solo trae información y actualiza las referencias remotas: es la opción segura para revisar antes de integrar. pull es aproximadamente fetch + merge: baja e integra en un solo paso, por lo que puede provocar un merge commit o conflictos en tu rama. La diferencia clave: fetch solo mira, pull mira y aplica.

Estás en la rama feature, que salió de un commit antiguo de main, y mientras tanto main recibió commits nuevos. Ejecutas uno u otro:

# Opcion A
git switch feature
git rebase main

# Opcion B
git switch main
git merge feature

Predice: ¿cómo queda el historial en cada caso? ¿Alguno crea un commit extra? ¿Alguno reescribe la historia?

• git rebase main (desde feature): reaplica los commits de feature encima de main, dejando un historial lineal sin merge commit, pero reescribiendo la historia (los commits obtienen hashes nuevos).
• git merge feature (desde main): crea un merge commit con dos padres, dejando un historial ramificado que conserva la historia real y no cambia los hashes existentes.

El rebase mueve tus commits a una base nueva, por eso el historial queda recto pero los identificadores cambian; solo es seguro en ramas locales. El merge une las historias con un commit especial de dos padres, conservando lo que realmente pasó; es seguro en ramas compartidas. La regla de oro: no rebasear historia pública.

Editaste estilos.css pero no has hecho git add. Ejecutas uno u otro:

# Opcion A (comando clasico)
git checkout -- estilos.css

# Opcion B (comando moderno)
git restore estilos.css

Predice: ¿qué le pasa a tus cambios en estilos.css? ¿Hacen lo mismo?

Ambos comandos hacen lo mismo: descartan los cambios sin commitear de estilos.css, devolviéndolo al estado del último commit. La diferencia es de sintaxis/claridad:

• git checkout -- estilos.css: la forma clásica; checkout hacía demasiadas cosas.
• git restore estilos.css: la forma moderna, específica para restaurar archivos (recomendada).

Desde Git 2.23, el viejo checkout se dividió en git switch (para cambiar de rama) y git restore (para restaurar archivos), porque checkout hacía tantas cosas que confundía. En este caso ambos descartan cambios de forma irreversible, así que hay que estar seguro de no querer esos cambios.

# Comando 1
git log --oneline

# Comando 2
git show HEAD~2

# Comando 3
git diff HEAD~2 HEAD

Predice: ¿qué muestra git log --oneline? ¿A qué commit se refiere HEAD~2? ¿Qué compara el tercer comando?

• git log --oneline: muestra el historial de commits, uno por línea, con el hash corto y el mensaje, del más nuevo al más viejo.
• HEAD~2: referencia relativa al commit que está dos posiciones antes del actual (HEAD es el actual, HEAD~1 su padre, HEAD~2 dos atrás). git show HEAD~2 muestra ese commit.
• git diff HEAD~2 HEAD: muestra todos los cambios acumulados entre el commit de hace dos posiciones y el commit actual.

Git permite referirse a los commits no solo por su hash, sino de forma relativa con ~: HEAD~1, HEAD~2, etc. (HEAD^ equivale a HEAD~1). Esto evita tener que copiar hashes largos. --oneline compacta el log para leerlo rápido, y las referencias relativas se combinan con comandos como show, diff o reset.