Git

You have a commit made locally and you run one or the other:

# Option A
git reset --soft HEAD~1

# Option B
git reset --hard HEAD~1

Predict: in each case, what happens to the commit and, above all, what happens to your changes?

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 moves the branch pointer to another commit. What changes is what it does with the content: --soft leaves it in staging, --mixed (the default) leaves it unstaged in the working directory, and --hard removes it. That's why --hard is dangerous: it's the only variant that deletes work. Also, reset rewrites history, so it should only be used on local commits that haven't been published.

# Option A
git fetch origin

# Option B
git pull origin main

Predict: which of the two modifies your current working branch and which one doesn't?

• 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 only brings down information and updates the remote references: it's the safe option to review before integrating. pull is roughly fetch + merge: it downloads and integrates in a single step, so it can produce a merge commit or conflicts in your branch. The key difference: fetch only looks, pull looks and applies.

You're on the feature branch, which branched off from an old commit of main, and meanwhile main received new commits. You run one or the other:

# Option A
git switch feature
git rebase main

# Option B
git switch main
git merge feature

Predict: how does the history end up in each case? Does either create an extra commit? Does either rewrite history?

• 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.

Rebase moves your commits onto a new base, which is why the history ends up straight but the identifiers change; it's only safe on local branches. Merge joins the histories with a special two-parent commit, preserving what actually happened; it's safe on shared branches. The golden rule: don't rebase public history.

You edited estilos.css but you haven't run git add. You run one or the other:

# Option A (classic command)
git checkout -- estilos.css

# Option B (modern command)
git restore estilos.css

Predict: what happens to your changes in estilos.css? Do they do the same thing?

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).

Since Git 2.23, the old checkout was split into git switch (for changing branches) and git restore (for restoring files), because checkout did so many things that it was confusing. In this case both discard changes irreversibly, so you need to be sure you don't want those changes.

# Command 1
git log --oneline

# Command 2
git show HEAD~2

# Command 3
git diff HEAD~2 HEAD

Predict: what does git log --oneline show? Which commit does HEAD~2 refer to? What does the third command compare?

• 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 lets you refer to commits not only by their hash, but also relatively with ~: HEAD~1, HEAD~2, etc. (HEAD^ is equivalent to HEAD~1). This avoids having to copy long hashes. --oneline compacts the log so you can read it quickly, and relative references combine with commands like show, diff, or reset.