Git guarda en cada commit un autor: un nombre y un email. No los inventa: los lee de su configuración. Por eso, antes del primer commit en una máquina nueva, tienes que decirle quién eres.
La configuración vive en tres niveles, y el más específico gana:
Sistema (--system): para todos los usuarios de la máquina. Casi nunca se toca.
Global (--global): para tu usuario, en todos tus repositorios. Aquí van tu nombre y tu email.
Local (sin opción, dentro de un repo): solo para ese repositorio. Sirve, por ejemplo, para usar otro email en un proyecto del trabajo.
Con un valor, el comando lo escribe; sin valor, lo lee.
Cómo se usa
Forma
Qué hace
git config --global user.name "Nombre"
Guarda tu nombre de autor para todos tus repos.
git config --global user.email "email"
Guarda tu email de autor. Usa el mismo de tu cuenta de GitHub (o el noreply que te da GitHub).
git config user.name
Muestra el valor actual (sin cambiarlo).
git config --list
Muestra toda la configuración que git está usando.
Cuándo usarlo
Una vez por máquina, apenas instalas git. Después solo vuelves a usarlo si cambias de email o quieres un ajuste distinto en un repo concreto.
Error típico: commitear con un email que no es el de tu cuenta de GitHub. Los commits se suben igual, pero no aparecen asociados a tu perfil. Si quieres mantener tu email privado, usa el @users.noreply.github.com que te da GitHub.
Pruébalo
git config --global user.name "tu-usuario"Guarda tu nombre de autor. Las comillas hacen falta si el nombre tiene espacios.
git config --global user.email "[email protected]"Guarda tu email de autor. Este es el email privado que GitHub da a cada cuenta.
git config user.nameSin valor, el comando lee: muestra el nombre que acabas de guardar.
git config --listLista toda la configuración. Busca las líneas user.name y user.email.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git config y probaste sus ejemplos?
Básico · lección 2 de 25
git init
Convierte una carpeta en un repositorio.
Qué hace
Crea dentro de la carpeta actual una carpeta oculta llamada .git. Ahí git guarda todo: los commits, las ramas, la configuración local y el staging. Tus archivos no cambian; solo empiezan a poder ser seguidos.
Desde ese momento la carpeta es un repositorio, con una rama inicial (main) que todavía no tiene commits. Si algún día borras .git, la carpeta vuelve a ser una carpeta normal y pierdes el historial.
Cómo se usa
Forma
Qué hace
git init
Convierte la carpeta actual en un repositorio.
git init nombre
Crea la carpeta nombre y la convierte en repositorio.
Cuándo usarlo
Cuando empiezas un proyecto desde cero en tu máquina. Si el proyecto ya existe en GitHub, no uses init: usa git clone, que trae el repositorio con todo su historial.
Error típico: hacer git init dentro de otro repositorio, o en tu carpeta personal entera. Git empezaría a seguir archivos que no tienen nada que ver con el proyecto.
Pruébalo
lsLista los archivos de la carpeta.
git initCrea la carpeta oculta .git. Desde ahora esta carpeta es un repositorio.
ls -aLista también los archivos ocultos: ahora aparece .git.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git init y probaste sus ejemplos?
Básico · lección 3 de 25
git status
Muestra en qué rama estás y qué cambió.
Qué hace
Te dice en qué rama estás y compara tres lugares: el último commit, el staging (lo preparado para el próximo commit) y el working tree (tus archivos tal como están en el disco). Según esa comparación, cada archivo cae en un grupo:
Cambios preparados (staging): ya los agregaste y van a entrar en el próximo commit.
Cambios sin preparar: archivos que git ya conoce, modificados, pero que todavía no agregaste.
Sin seguimiento (untracked): archivos nuevos que git nunca vio.
Si hay un repositorio remoto, también te dice si tu rama está adelante o atrás de él. Además, casi siempre te sugiere el próximo comando que podrías usar.
Cómo se usa
Forma
Qué hace
git status
Versión completa, con explicaciones y sugerencias.
git status -s
Versión corta, una línea por archivo: M modificado, A agregado, D borrado, ?? sin seguimiento. La primera columna es el staging y la segunda, el working tree.
Cuándo usarlo
Todo el tiempo. Es un comando de solo lectura: nunca cambia nada, así que puedes usarlo sin miedo.
Hábito: ejecuta git status antes de cada git add y antes de cada git commit. Así ves exactamente qué va a entrar.
Pruébalo
git statusVersión completa: README.md modificado e idea.txt sin seguimiento.
git status -sVersión corta. Fíjate en las dos columnas de letras delante de cada archivo.
echo hola > saludo.txtCrea saludo.txt con ese texto.
git status -sVersión corta. Fíjate en las dos columnas de letras delante de cada archivo.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git status y probaste sus ejemplos?
Básico · lección 4 de 25
git add
Pasa cambios al staging: elige qué entra en el próximo commit.
Qué hace
Git no guarda automáticamente todo lo que cambias. Entre tus archivos y el historial hay un paso intermedio: el staging (también llamado índice). Es como una caja que vas armando: lo que pones en la caja es exactamente lo que va a guardar el próximo commit.
git add pone en la caja el estado actual de un archivo. Si después de agregarlo lo vuelves a modificar, esos cambios nuevos no están en la caja hasta que lo agregues otra vez.
Gracias al staging puedes hacer commits pequeños y ordenados: aunque hayas tocado cinco archivos, puedes commitear solo dos.
Agrega todo lo que cambió en la carpeta actual, incluidos los archivos nuevos.
Cuándo usarlo
Justo antes de commitear, después de revisar con git status qué cambió. Agrega solo lo que tiene que ver con el cambio que vas a describir en el mensaje.
Error típico: un git add . que se lleva un archivo de prueba, un secreto o un package-lock.json modificado sin querer. Agrega archivos concretos y revisa antes.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git add y probaste sus ejemplos?
Básico · lección 5 de 25
git commit
Guarda una foto de lo que está en el staging.
Qué hace
Un commit es una foto del proyecto en un momento dado. Git toma lo que hay en el staging y lo guarda para siempre en el historial, junto con:
un ID (hash) único, calculado a partir del contenido, como 3f2a9c1;
el autor y la fecha (de git config);
un mensaje que explica el cambio;
el commit padre, el anterior. Así se forma la cadena del historial.
Después del commit, la rama actual avanza y apunta al commit nuevo. Mira el grafo: aparece un punto nuevo al final de la rama.
Cómo se usa
Forma
Qué hace
git commit -m "mensaje"
Crea el commit con ese mensaje. Sin -m se abre un editor para escribirlo.
git commit -a -m "mensaje"
Agrega automáticamente los archivos ya seguidos que cambiaron y commitea. No incluye archivos nuevos.
git commit --amend -m "mensaje"
Reemplaza el último commit: corrige el mensaje o suma lo que hay en el staging. El commit nuevo tiene otro ID.
Cuándo usarlo
Cada vez que terminas un paso con sentido propio: una función que anda, un arreglo, un texto corregido. Muchos commits pequeños son mejores que uno gigante, porque se revisan y se deshacen más fácil.
Buen mensaje: corto, en imperativo y específico: Agregar sección de instalación, no cambios. Y usa --amend solo en commits que todavía no subiste: si ya hiciste push, reescribes una historia que otras personas tienen.
git commit --amend -m "Ampliar README con una idea nueva"Reemplaza el último commit con otro mensaje. Compara el ID con el del paso anterior: cambió.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git commit y probaste sus ejemplos?
Básico · lección 6 de 25
git log
Muestra el historial de commits.
Qué hace
Recorre el historial hacia atrás, desde el commit donde estás (HEAD), siguiendo a cada padre. Por cada commit muestra su ID, autor, fecha y mensaje.
Entre paréntesis aparecen las referencias que apuntan a ese commit: HEAD -> main significa "estás en main y main apunta aquí"; también pueden aparecer otras ramas, ramas remotas como origin/main o etiquetas.
Por defecto solo muestra lo que se puede alcanzar desde la rama actual. Los commits de otras ramas no aparecen a menos que pidas --all.
Cómo se usa
Forma
Qué hace
git log
Historial completo, con todos los datos de cada commit.
git log --oneline
Una línea por commit: ID corto y título. La forma más usada.
git log -N
Solo los últimos N commits (por ejemplo -3).
git log --all
Incluye los commits de todas las ramas.
git log rama
El historial de otra rama, sin cambiarte a ella.
Cuándo usarlo
Para ubicarte: ver qué se hizo, encontrar el ID de un commit, comprobar que tu commit quedó bien o comparar dónde está cada rama.
Pruébalo
git logHistorial completo de la rama actual, del commit más nuevo al más viejo.
git log --onelineLo mismo, una línea por commit.
git log --oneline -1Solo el último commit.
git log --oneline --allAhora también aparece el commit de la rama feature, que no está en main.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git log y probaste sus ejemplos?
Básico · lección 7 de 25
git diff
Muestra las líneas exactas que cambiaron.
Qué hace
Compara dos versiones y muestra la diferencia línea por línea. Las líneas que empiezan con + se agregaron, las que empiezan con - se quitaron y las demás son contexto que no cambió.
Lo importante es saber qué compara en cada caso:
git diff: tus archivos contra el staging. Es decir, lo que cambiaste y todavía no agregaste.
git diff --staged: el staging contra el último commit. Es decir, lo que va a entrar en el próximo commit.
git diff A B: dos commits o ramas cualesquiera.
Por eso, si agregas todo con git add, git diff sale vacío: ya no hay diferencia entre tus archivos y el staging.
Cómo se usa
Forma
Qué hace
git diff
Cambios sin agregar.
git diff --staged
Cambios agregados que entran en el próximo commit.
git diff A B
Diferencias entre dos commits o ramas.
git diff --stat A B
Solo el resumen: qué archivos cambiaron y cuántas líneas.
Cuándo usarlo
Antes de commitear, para revisar que no se cuele nada raro. Y antes de un Pull Request, para ver todo lo que cambió tu rama.
Pruébalo
git diffLa línea nueva de README.md aparece con +. idea.txt no sale porque git todavía no lo sigue.
git diff --stagedAhora el cambio de README.md está en el staging, así que sale aquí.
git diff --stat HEAD~1 HEADResumen de lo que cambió entre el penúltimo commit y el último.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git diff y probaste sus ejemplos?
Básico · lección 8 de 25
git show
Muestra un commit con todo su contenido.
Qué hace
Muestra un commit concreto: autor, fecha, mensaje y el diff de lo que cambió en ese commit. Sin argumentos muestra HEAD, el commit donde estás.
Para nombrar commits no hace falta copiar IDs. Git entiende referencias relativas:
HEAD~1 es el commit anterior a HEAD; HEAD~2, el anterior a ese.
Un nombre de rama o de etiqueta apunta a su último commit.
También puede mostrar un archivo tal como está en otro commit o rama: git show rama:archivo.
Cómo se usa
Forma
Qué hace
git show
El último commit con su diff.
git show ID
Un commit concreto (el ID corto alcanza).
git show --stat ref
Solo la lista de archivos que cambiaron.
git show rama:archivo
El contenido de un archivo en otra rama, sin cambiarte a ella.
Cuándo usarlo
Cuando git log te dio un ID y quieres ver qué hizo exactamente ese commit.
Pruébalo
git showEl último commit de main con su diff.
git show --stat HEAD~1El commit anterior, solo con la lista de archivos.
git show feature:feature.txtEl archivo feature.txt tal como está en la rama feature. En main no existe.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git show y probaste sus ejemplos?
Intermedio · lección 9 de 25
git restore
Deshace cambios que todavía no commiteaste.
Qué hace
Devuelve un archivo a una versión anterior. Tiene dos usos muy distintos, según dónde actúe:
En el working tree (git restore archivo): tira tus cambios y el archivo vuelve a como está en el staging o en el último commit. Lo que habías escrito se pierde; git nunca lo guardó.
En el staging (git restore --staged archivo): saca el archivo del staging, pero tus cambios siguen en el disco. Es lo contrario de git add.
Con --source puedes traer el archivo desde cualquier commit, por ejemplo --source HEAD~2.
Cómo se usa
Forma
Qué hace
git restore --staged archivo
Quita el archivo del staging. Tus cambios no se tocan.
git restore archivo
Descarta los cambios del archivo. No se puede deshacer.
git restore --source ref archivo
Trae el archivo tal como estaba en otro commit.
Cuándo usarlo
Cuando agregaste algo al staging por error, o cuando probaste un cambio en un archivo y quieres volver a empezar.
Ojo:git restore archivo no pide confirmación. Si no estás seguro, primero mira qué vas a perder con git diff archivo.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git restore y probaste sus ejemplos?
Intermedio · lección 10 de 25
git rm
Borra un archivo y registra el borrado.
Qué hace
Si borras un archivo a mano, git lo ve como "borrado sin preparar" y todavía tienes que agregar ese borrado al staging. git rm hace las dos cosas a la vez: borra el archivo del disco y deja el borrado listo para el próximo commit.
El archivo desaparece de los commits nuevos, pero sigue en los anteriores: puedes recuperarlo desde el historial cuando quieras.
Con --cached git deja de seguir el archivo pero lo conserva en tu disco.
Cómo se usa
Forma
Qué hace
git rm archivo
Borra el archivo y prepara el borrado.
git rm --cached archivo
Deja de seguir el archivo, pero no lo borra del disco.
git rm -r carpeta
Borra una carpeta entera.
Cuándo usarlo
Para quitar archivos que ya no hacen falta. --cached es útil cuando commiteaste algo que debía ir en .gitignore, como un archivo de configuración local.
Error típico: creer que git rm --cached borra un secreto del historial. Solo lo quita de los commits siguientes: en los anteriores sigue ahí. Si subiste una contraseña, cámbiala.
Pruébalo
git rm notas.txtBorra notas.txt y deja el borrado en el staging.
git commit -m "Quitar notas"Ya lo viste en git commit.
lsLista los archivos de la carpeta.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git rm y probaste sus ejemplos?
Intermedio · lección 11 de 25
git branch
Lista, crea y borra ramas.
Qué hace
Una rama es solo un nombre que apunta a un commit. No es una copia de los archivos: es una etiqueta liviana que, cuando haces un commit estando en ella, avanza sola al commit nuevo.
Por eso crear una rama es instantáneo. Las ramas sirven para trabajar en algo sin tocar main: si el experimento sale mal, borras la rama y listo.
git branch solo administra los nombres; para moverte a otra rama se usa git switch.
Cómo se usa
Forma
Qué hace
git branch
Lista las ramas locales. La actual lleva *.
git branch nombre
Crea una rama en el commit actual, sin cambiarte a ella.
git branch -d nombre
Borra una rama que ya está integrada. Si tiene trabajo sin integrar, git se niega.
git branch -D nombre
Borra la rama a la fuerza, aunque pierdas sus commits.
git branch -a
Incluye también las ramas remotas.
Cuándo usarlo
Una rama por cada cambio: un arreglo, una función, una mejora. Así cada Pull Request lleva una sola cosa.
Mira el grafo: cada rama nueva aparece con su nombre, apuntando al mismo commit que la rama desde la que la creaste.
Pruébalo
git branchLista las ramas. La que tiene * es la actual.
git branch experimentoCrea la rama experimento en el commit actual. Sigues en main.
git branchLista las ramas. La que tiene * es la actual.
git branch -d experimentoBorra la rama. Como no tenía commits propios, no se pierde nada.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git branch y probaste sus ejemplos?
Intermedio · lección 12 de 25
git switch
Te mueve de una rama a otra.
Qué hace
HEAD es un puntero que indica dónde estás parado: normalmente apunta a una rama, y la rama apunta a un commit. git switch rama mueve HEAD a otra rama y cambia tus archivos para que coincidan con el último commit de esa rama.
Los archivos que solo existen en la otra rama aparecen, y los que solo existen en la rama actual desaparecen del disco (siguen guardados en su rama).
Tus cambios sin commitear viajan contigo si no chocan con la otra rama. Si chocan, git no te deja cambiar para no perderlos.
Cómo se usa
Forma
Qué hace
git switch rama
Cambia a una rama que ya existe.
git switch -c nueva
Crea la rama desde donde estás y te cambia a ella, en un solo paso.
git switch -
Vuelve a la rama anterior.
Cuándo usarlo
Cada vez que empiezas un cambio nuevo (-c) o necesitas volver a main para actualizarla o crear otra rama.
Ojo: si tienes cambios sin commitear que chocan con la otra rama, git no te deja cambiar. Commitea o guárdalos con git stash. Pruébalo con el grafo abierto: al volver a main vas a ver que HEAD retrocede.
Pruébalo
git switch -c featureCrea la rama feature y te cambia a ella.
echo "nueva función" > feature.txtCrea feature.txt con ese texto.
git commit -m "Agregar feature"Ya lo viste en git commit.
git switch mainVuelve a main. HEAD retrocede en el grafo y feature.txt desaparece del disco.
lsfeature.txt no está: solo existe en la rama feature.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git switch y probaste sus ejemplos?
Intermedio · lección 13 de 25
git merge
Integra otra rama en la rama actual.
Qué hace
Trae los commits de otra rama a la rama en la que estás. El orden importa: primero te cambias a la rama que recibe los cambios (normalmente main) y después nombras la rama que quieres traer.
Según cómo estén las ramas, pasan dos cosas distintas:
Fast-forward: si main no avanzó desde que creaste la otra rama, git solo adelanta el puntero de main. No crea ningún commit nuevo y la historia queda lineal.
Commit de merge: si las dos ramas avanzaron, git crea un commit especial con dos padres que une ambas historias.
Si las dos ramas cambiaron las mismas líneas, hay un conflicto y git te pide que elijas. Este simulador no resuelve conflictos: cancela el merge y te avisa.
Cómo se usa
Forma
Qué hace
git merge rama
Integra rama en la rama actual.
git merge --no-ff rama
Crea un commit de merge aunque se pudiera hacer fast-forward.
git merge --abort
Cancela un merge con conflictos y vuelve a como estabas.
Cuándo usarlo
Cuando una rama está lista y quieres llevar su trabajo a main. En proyectos open source normalmente el merge lo hace el mantenedor desde GitHub, al aceptar tu Pull Request.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git merge y probaste sus ejemplos?
Intermedio · lección 14 de 25
git stash
Guarda cambios a medio hacer para retomarlos después.
Qué hace
Toma tus cambios sin commitear, los guarda en una pila aparte y deja tus archivos como en el último commit. Es como guardar el trabajo en un cajón para tener la mesa limpia.
Cada git stash pone una entrada nueva arriba de la pila (stash@{0} es la más reciente). git stash pop saca la de arriba y vuelve a aplicar esos cambios, incluso en otra rama.
Por defecto solo guarda archivos que git ya sigue. Los archivos nuevos se quedan donde están, salvo que uses -u.
Cómo se usa
Forma
Qué hace
git stash
Guarda los cambios de archivos seguidos.
git stash -u
Guarda también los archivos nuevos (untracked).
git stash list
Muestra lo que hay en la pila.
git stash pop
Recupera lo último que guardaste y lo saca de la pila.
Cuándo usarlo
Cuando estás a mitad de algo y tienes que cambiar de rama ya, por ejemplo para un arreglo urgente, y lo que tienes todavía no merece un commit.
Error típico: olvidar lo que guardaste. La pila no tiene fecha de vencimiento, pero sí es fácil perderle el rastro. Revisa git stash list de vez en cuando.
git stash listLa pila tiene una entrada: stash@{0}.
git stash popRecupera los cambios. Comprueba con git status -s que volvieron.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git stash y probaste sus ejemplos?
Intermedio · lección 15 de 25
git tag
Le pone un nombre fijo a un commit, como v1.0.
Qué hace
Una etiqueta marca un commit importante, normalmente una versión publicada. Se parece a una rama, porque también es un nombre que apunta a un commit, pero no se mueve: aunque hagas commits nuevos, v1.0 sigue apuntando al mismo commit. Mira el grafo: la etiqueta se queda atrás.
Hay dos tipos:
Ligera (git tag v1.0): solo un nombre.
Anotada (git tag -a v1.1 -m "…"): guarda también autor, fecha y mensaje. Es la que se usa para versiones.
Las etiquetas no se suben con un git push normal: hay que subirlas aparte.
Cómo se usa
Forma
Qué hace
git tag nombre
Crea una etiqueta ligera en el commit actual.
git tag -a nombre -m "mensaje"
Crea una etiqueta anotada.
git tag
Lista las etiquetas. Con -n muestra también sus mensajes.
git tag -d nombre
Borra una etiqueta local.
git push origin nombre
Sube una etiqueta. git push --tags sube todas.
Cuándo usarlo
Cuando publicas una versión. Así cualquiera puede volver exactamente a "lo que era la v1.0" con git show v1.0 o git switch --detach v1.0.
Error típico: mover o borrar una etiqueta que ya publicaste. Otras personas ya la descargaron; mejor crea una versión nueva (v1.0.1).
Pruébalo
git tag v1.0Etiqueta ligera en el commit actual.
git tagLista las etiquetas.
echo "Más detalles" >> README.mdAgrega una línea al final de README.md.
git commit -a -m "Mejorar README"Ya lo viste en git commit.
git tag -a v1.1 -m "Versión 1.1"Etiqueta anotada en el commit nuevo. v1.0 se quedó en el anterior.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git tag y probaste sus ejemplos?
Avanzado · lección 16 de 25
git clone
Descarga un repositorio remoto completo.
Qué hace
Copia un repositorio que vive en otro lugar (GitHub, por ejemplo) a tu máquina, con todo su historial: todos los commits y todas las ramas. No es solo bajar los archivos.
Además deja todo configurado:
crea un remoto llamado origin que apunta a la URL de donde clonaste;
crea las copias remotas (origin/main, etc.);
crea tu rama local main, vinculada a origin/main.
Cómo se usa
Forma
Qué hace
git clone URL
Clona en una carpeta con el nombre del repositorio.
git clone URL carpeta
Clona en la carpeta que elijas.
Cuándo usarlo
Una vez, al empezar a trabajar en un proyecto que ya existe. Para contribuir a un proyecto ajeno, lo habitual es clonar el original y después agregar tu fork como remoto (lo ves en git remote).
Ojo: después de clonar tienes que entrar a la carpeta con cd. Los comandos de git solo funcionan dentro del repositorio.
Pruébalo
git clone https://github.com/mantenedor/labs-abiertos.git labs-abiertosDescarga el repositorio del mantenedor en la carpeta labs-abiertos.
cd labs-abiertosEntra a la carpeta del repositorio.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git clone y probaste sus ejemplos?
Avanzado · lección 17 de 25
git remote
Administra los repositorios remotos.
Qué hace
Un remoto es un nombre corto para una URL: en vez de escribir la dirección completa cada vez, escribes origin. Un repositorio puede tener varios remotos.
Cuando contribuyes a un proyecto ajeno, la convención es:
upstream: el repositorio original del mantenedor. De ahí traes lo nuevo.
origin: tu fork, tu copia en GitHub. Ahí subes tus ramas y desde ahí abres los Pull Requests.
Al clonar el original, origin apunta al mantenedor. Por eso se renombra a upstream y se agrega tu fork como origin.
Cómo se usa
Forma
Qué hace
git remote -v
Lista los remotos con sus URLs (fetch y push).
git remote add nombre URL
Agrega un remoto.
git remote rename viejo nuevo
Le cambia el nombre a un remoto.
git remote remove nombre
Borra un remoto (no toca nada en GitHub).
Cuándo usarlo
Al preparar un repositorio para contribuir, y cada vez que un push o un pull va al lugar equivocado: lo primero es revisar git remote -v.
Pruébalo
git remote -vMuestra los remotos y sus URLs.
gh repo forkCrea tu fork en GitHub (tu copia del repositorio) con la CLI de GitHub.
git remote rename origin upstreamEl remoto del mantenedor pasa a llamarse upstream.
git remote add origin https://github.com/tu-usuario/labs-abiertos.gitTu fork pasa a ser origin.
git remote -vMuestra los remotos y sus URLs.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git remote y probaste sus ejemplos?
Avanzado · lección 18 de 25
git fetch
Descarga lo nuevo del remoto sin tocar tus ramas.
Qué hace
Pregunta al remoto qué hay de nuevo y lo descarga, pero solo actualiza las copias remotas (upstream/main, origin/main). Tus ramas locales y tus archivos no cambian.
Las copias remotas son una foto de cómo estaba el remoto la última vez que hablaste con él. No se actualizan solas: si nunca haces fetch, upstream/main se queda vieja aunque el mantenedor haya subido cambios.
Después del fetch decides qué hacer: mirar los cambios, integrarlos con git merge o rebasear tu rama encima.
Cómo se usa
Forma
Qué hace
git fetch remoto
Descarga lo nuevo de ese remoto.
git fetch --all
Descarga lo nuevo de todos los remotos.
git fetch --prune
Además borra las copias de ramas que ya no existen en el remoto.
Cuándo usarlo
Siempre que quieras saber si hay novedades. Es seguro: nunca toca tu trabajo.
Pruébalo
git log --oneline -1 upstream/mainYa lo viste en git log.
git fetch upstreamDescarga los commits nuevos del mantenedor. Mira en el grafo cómo avanza upstream/main y main se queda donde estaba.
git log --oneline -3 upstream/mainYa lo viste en git log.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git fetch y probaste sus ejemplos?
Avanzado · lección 19 de 25
git pull
fetch + merge: trae lo nuevo y lo integra en tu rama.
Qué hace
Es un atajo para dos pasos: primero hace git fetch y después integra lo descargado en tu rama actual con git merge.
Si tu rama no tenía commits propios, el merge es un fast-forward: tu rama simplemente avanza hasta lo último del remoto. Si los dos lados avanzaron, se crea un commit de merge. Con --rebase pone tus commits encima en vez de crear ese merge.
Cómo se usa
Forma
Qué hace
git pull
Trae e integra desde la rama remota vinculada.
git pull remoto rama
Trae e integra una rama concreta, por ejemplo upstream main.
git pull --rebase
Integra con rebase en vez de merge: historia lineal.
Cuándo usarlo
En main, antes de crear una rama nueva, para partir siempre de lo último del proyecto.
Error típico: hacer pull estando en tu rama de trabajo sin darte cuenta. Mezclas main en tu cambio y el PR se llena de commits que no son tuyos. Mira en qué rama estás antes.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git pull y probaste sus ejemplos?
Avanzado · lección 20 de 25
git push
Sube tus commits a un remoto.
Qué hace
Envía los commits de tu rama a un remoto y mueve allí la rama para que apunte a lo mismo que la tuya. Es lo contrario de fetch: fetch trae, push lleva.
Git solo acepta el push si es un avance: la rama remota tiene que poder moverse hacia adelante hasta tu commit. Si alguien subió algo que tú no tienes, o si reescribiste la historia, el push se rechaza para no perder commits.
La primera vez se usa -u para vincular tu rama local con la remota. Después alcanza con git push.
Cómo se usa
Forma
Qué hace
git push -u origin rama
Sube la rama por primera vez y la deja vinculada.
git push
Sube la rama actual a la remota vinculada.
git push --force-with-lease
Reemplaza la rama remota después de un rebase o amend, pero solo si nadie más subió nada.
git push origin --delete rama
Borra la rama en el remoto.
Cuándo usarlo
Cuando quieres que tus commits estén en GitHub: para abrir un Pull Request o para actualizarlo después de una revisión.
Nunca uses --force a secas en una rama compartida: pisa lo que otros hayan subido. --force-with-lease hace lo mismo, pero se detiene si hay algo que no viste.
git commit -m "Agregar aporte"Ya lo viste en git commit.
git push -u origin mi-cambioSube la rama a tu fork y la vincula. Mira en el grafo cómo aparece origin/mi-cambio.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git push y probaste sus ejemplos?
Avanzado · lección 21 de 25
git rebase
Reaplica tus commits encima de otra rama.
Qué hace
Toma los commits de tu rama que no están en la otra y los vuelve a aplicar, uno por uno, encima de la punta de esa otra rama. Es como si hubieras empezado tu trabajo recién ahora, desde lo último.
El resultado es una historia lineal, sin commits de merge. Pero los commits reaplicados son commits nuevos, con otros IDs: el contenido es el mismo, pero el padre cambió, así que el hash cambia.
Si hay conflictos, el rebase se detiene en el commit que choca para que lo resuelvas. Este simulador cancela el rebase y te avisa.
Cómo se usa
Forma
Qué hace
git rebase rama
Reaplica la rama actual encima de rama.
git rebase --continue
Sigue después de resolver un conflicto.
git rebase --abort
Cancela y vuelve a como estabas.
Cuándo usarlo
Para poner tu rama al día con main antes de abrir o actualizar un Pull Request. Muchos proyectos lo piden para mantener la historia limpia.
Regla de oro: no rebasees ramas que otras personas usan, porque les cambias la historia. Y si ya habías hecho push, después del rebase necesitas git push --force-with-lease.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git rebase y probaste sus ejemplos?
Avanzado · lección 22 de 25
git cherry-pick
Copia un commit de otra rama a la rama actual.
Qué hace
Toma los cambios de un commit y los aplica como un commit nuevo donde estás. Sirve cuando necesitas solo una parte de otra rama: por ejemplo, un arreglo que quedó en una rama experimental que todavía no se puede mergear.
El commit copiado tiene el mismo mensaje y el mismo autor, pero otro ID, porque tiene otro padre. El original sigue en su rama: no se mueve nada, se copia.
En el ejemplo, la rama experimento tiene un arreglo y una idea a medias. Solo traes el arreglo: experimento~1 es el commit anterior a la punta de la rama.
Cómo se usa
Forma
Qué hace
git cherry-pick ref
Copia ese commit a la rama actual.
git cherry-pick -x ref
Igual, pero el mensaje anota de qué commit vino.
git cherry-pick -n ref
Aplica los cambios sin commitear: quedan en el staging.
git cherry-pick A..B
Copia varios commits seguidos (de A, sin incluirlo, hasta B).
Cuándo usarlo
Para rescatar un commit puntual: un arreglo que hace falta ya en main, o un commit que hiciste en la rama equivocada.
Error típico: usar cherry-pick para traer una rama entera, commit por commit. Para eso están git merge y git rebase.
Pruébalo
git log --oneline experimentoYa lo viste en git log.
git cherry-pick experimento~1Copia a main el arreglo del cálculo. La idea a medias se queda en experimento.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git cherry-pick y probaste sus ejemplos?
Avanzado · lección 23 de 25
git revert
Deshace un commit creando otro commit, sin reescribir la historia.
Qué hace
Crea un commit nuevo con los cambios al revés del commit que indiques: lo que agregó se borra y lo que borró vuelve. El commit original sigue en el historial, y queda registro de que se deshizo.
Como no cambia ningún commit existente, es la forma segura de deshacer algo que ya subiste: nadie tiene que hacer force push ni arreglar su copia.
En git real se abre el editor para revisar el mensaje; --no-edit acepta el mensaje por defecto (Revert "…").
Cómo se usa
Forma
Qué hace
git revert ref
Crea un commit que deshace ese commit.
git revert ref --no-edit
Igual, sin abrir el editor.
git revert -n ref
Deja los cambios inversos en el staging, sin commitear.
Cuándo usarlo
Cuando un commit que ya está en GitHub rompió algo. Si el commit es solo local y nadie lo vio, también puedes usar git reset.
Error típico: hacer git reset --hard en una rama que ya está en GitHub y después necesitar --force. Si ya la compartiste, usa revert.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git revert y probaste sus ejemplos?
Avanzado · lección 24 de 25
git reset
Mueve la rama actual a otro commit.
Qué hace
Mueve la rama actual (y HEAD con ella) a otro commit, normalmente hacia atrás. Los commits que quedan "adelante" ya no forman parte de la rama.
Lo que pasa con los cambios de esos commits depende del modo:
--soft: quedan en el staging, listos para commitear otra vez. Útil para juntar varios commits en uno.
--mixed (por defecto): quedan en tus archivos, sin agregar.
--hard: se descartan, junto con cualquier cambio sin commitear. Peligroso.
Los commits "borrados" no desaparecen enseguida: los puedes encontrar con git reflog.
Cómo se usa
Forma
Qué hace
git reset --soft HEAD~1
Deshace el último commit; sus cambios quedan en el staging.
git reset HEAD~1
Deshace el último commit; sus cambios quedan sin agregar.
git reset --hard ref
Deja la rama y tus archivos exactamente como en ref.
Cuándo usarlo
Para rehacer commits locales que todavía no subiste: un commit hecho a medias, varios commits que quieres juntar, o una rama que quieres dejar igual que otra.
Mira el grafo: la rama retrocede al commit que indiques. Y recuerda: si el commit ya está en GitHub, mejor usa git revert.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git reset y probaste sus ejemplos?
Avanzado · lección 25 de 25
git reflog
El historial de todo lo que hizo HEAD: tu red de seguridad.
Qué hace
git log muestra la historia de los commits. git reflog muestra otra cosa: la historia de dónde estuvo HEAD. Registra cada commit, cada cambio de rama, cada reset y cada rebase, con una entrada HEAD@{n} (0 es lo más reciente).
Por eso, si "perdiste" un commit con un reset --hard o un rebase que salió mal, su ID sigue en el reflog. Git no borra los commits enseguida, aunque ninguna rama apunte a ellos.
Para recuperarlo, vuelve a él con git reset --hard ID o crea una rama en ese punto con git branch rescate ID.
Cómo se usa
Forma
Qué hace
git reflog
Lista los movimientos de HEAD, del más reciente al más viejo.
git reset --hard HEAD@{1}
Vuelve a donde estaba HEAD un movimiento atrás.
Cuándo usarlo
Cuando algo salió mal y te falta un commit. Es lo primero que hay que mirar antes de dar algo por perdido.
Para practicar: después de los ejemplos, copia el ID del commit "Agregar notas" que aparece en el reflog, vuelve a él con git reset --hard ID y comprueba con git log --oneline que volvió.
git reflogEl commit "Agregar notas" ya no está en el log, pero sí aquí.
Abre un repositorio de práctica preparado para esta lección y ejecuta los comandos en orden (haz click en uno para llevarlo a la terminal).
¿Ya entendiste git reflog y probaste sus ejemplos?
Git en la práctica
Contribuir a un proyecto open source, paso a paso con un ejemplo
La terminal de la derecha es un simulador: no toca tu máquina ni GitHub. Escribe help para empezar, o haz click en cualquier comando de esta guía para llevarlo a la terminal.
El escenario
Hay un repositorio original (upstream) de otra persona, el mantenedor. Tú no tienes permiso de escritura ahí, pero quieres sumar contenido y que lo revise y lo acepte. La solución estándar es fork + una branch por cambio + Pull Request.
El ejemplo: contribuir labs al repo Labs Abiertos (mantenedor/labs-abiertos) desde tu fork (tu-usuario/labs-abiertos). Los nombres son de ejemplo, pero los comandos, el orden y los errores son los que aparecen de verdad al contribuir.
PR
Qué agregó
Resultado
#30
Lab de find y grep (principiante)
Mergeado
#33
Lab intermedio de find
Revisión pedida, corregida con rebase
#34
Lab de cd (principiante)
Revisión pedida, corregida con rebase
#36
Lab de editar archivos (nano, vim, diff)
Abierto
Cómo usar esta guía
Lee Conceptos: sobre todo las tres copias de main.
Sigue el flujo completo, fase por fase, probando cada comando en la terminal.
Juega las misiones: cada una arranca de un estado preparado y te guía paso a paso.
El grafo del repo (abajo a la derecha) muestra en vivo tus branches, las copias remotas y lo que hay de verdad en GitHub.
Con sim avance, sim review y sim merge haces de mantenedor.
Los errores reales se pueden reproducir: provócalos a propósito.
Misiones
Conceptos que hay que tener claros
Concepto
Qué es
En el ejemplo
Repositorio
Carpeta con historial de cambios (commits)
labs-abiertos/
Remote
Un repositorio en otro lugar al que tu copia local apunta
origin y upstream
Fork
Copia del repo original en tu cuenta de GitHub, donde sí puedes escribir
tu-usuario/labs-abiertos
origin
Por convención, tu fork (a donde haces push)
github.com/tu-usuario/...
upstream
Por convención, el repo original (de donde traes cambios)
github.com/mantenedor/...
Branch
Un puntero a un commit; una línea de trabajo aislada
lab/linux-find-grep
Commit
Una foto de los cambios, con mensaje y autor
Add beginner find and grep lab...
Working tree
Los archivos tal como están en tu disco
lo que editas en VS Code
Staging (índice)
Lo que va a entrar en el próximo commit
lo que agregas con git add
Pull Request
Pedido para que el mantenedor integre tu branch en su main
#30, #33, #34, #36
Untracked
Archivo nuevo que git todavía no sigue (?? en git status)
un .mdx recién creado
Las tres copias de mainclave para entender todo
Repo del mantenedorupstream/main
Se actualiza sola: ahí se mergean los PRs de todos.
Fuente de verdad
Tu fork en GitHuborigin/main
No se actualiza: queda congelada cuando forkeaste.
Se queda vieja
Tu máquinamain local
Cambia solo cuando traes cambios (git pull upstream main).
La mueves tú
La fuente de verdad es upstream/main: es a donde apunta tu PR. En el grafo del simulador las ves con nombres distintos: ☁ mantenedor:main es lo que hay de verdad en GitHub, upstream/main es lo que tu máquina sabe de eso (se actualiza con git fetch), y main es tu branch.
Una branch es un puntero a un commit
main: A---B---C
\
lab/linux-find-grep: D---E← tus commits
La branch "nace" en el commit donde estás parado cuando la creas. Por eso importa crearla desde un main actualizado.
git clone https://github.com/mantenedor/labs-abiertos.git labs-abiertos
cd labs-abiertos
npm install
Problema real: después de npm install, git status mostró M package-lock.json. La versión de npm local (10) era distinta a la del mantenedor (11) y reescribió el lockfile (borró campos libc). Ese cambio no tiene que ir en ningún PR.
git diff package-lock.json # ver qué cambió exactamente
git checkout package-lock.json # descartar el cambio (volver a la versión del repo)
Lección: para instalar sin modificar el lockfile, usa npm ci.
1Fork y remotes una vez
En GitHub, botón Fork sobre el repo original (en el simulador: gh repo fork).
Reorganizar los remotes: el original pasa a ser upstream y tu fork, origin.
git branch --show-current # nombre de la branch actual
git log --oneline -1 # último commit
git status # estado del working tree
Regla de oro: nunca commitees en main. Tu main local solo sirve para sincronizar con upstream.
3Trabajar y revisar antes de commitear
git status # qué cambió
git diff # cambios no agregados, línea por línea
git diff --stat # resumen: qué archivos y cuántas líneas
Símbolo en git status --short
Significado
M
Modificado
??
Untracked (archivo nuevo que git no sigue)
A
Agregado al staging
4Agregar y commitear
git add src/content/labs/linux-real/encontrar-archivos-y-texto.mdx src/data/contributors.ts
git status
git commit
Agrega archivos concretos, no git add .: así no se cuela algo como el package-lock.json modificado.
Mira git status antes del commit: los archivos tienen que aparecer en verde, bajo "Cambios a ser confirmados".
Mensaje de commit
Formato usado (siguiendo el estilo del repo: inglés, imperativo):
Add beginner find and grep lab to Linux Real← título: imperativo, < 72 chars, sin puntoLinux Real lists shell workflow as a focus but had no← línea en blanco + body: el POR QUÉlab on finding files or text. ...- The practice folder includes a subdirectory so ...← listas con "-"- Adds tu-usuario to contributors.ts as lab author.
Dos formas de escribirlo:
git commit # abre el editor (recomendado para varias líneas)
git commit -m "Título" -m "Párrafo del body" # cada -m es un párrafo
¿Qué editor abre git commit? git busca en orden: GIT_EDITOR, core.editor, VISUAL, EDITOR y, si no hay nada, el default con que se compiló. En Ubuntu/Debian el default es /usr/bin/editor, que apunta a nano. En macOS, Fedora, Arch y Git for Windows suele ser vi. Para elegirlo:
git config --global core.editor nano
Editor
Guardar y salir
Salir sin guardar
nano
Ctrl+O, Enter, Ctrl+X
Ctrl+X, N
vim
Esc, :wq, Enter
Esc, :q!, Enter
Los dos editores funcionan en la terminal del simulador. Prueba git config --global core.editor vim y después un git commit.
Si el mensaje queda vacío, git cancela el commit ("Abortando commit debido a que el mensaje del commit está vacío") y no pasa nada.
Verificar el commit:
git log --oneline -2 # tu commit arriba, el último de upstream abajo
git log -1 # el commit completo con mensaje
git show --stat HEAD # qué archivos tocó el último commit
5Push a tu fork
git push -u origin lab/linux-find-grep
origin: tu fork.
-u (--set-upstream): conecta la branch local con la remota. Después alcanza con git push.
La primera vez, en HTTPS, la "contraseña" es un Personal Access Token, no la contraseña de la cuenta.
GitHub responde con un link para crear el PR:
remote: Create a pull request for 'lab/linux-find-grep' on GitHub by visiting:
remote: https://github.com/tu-usuario/labs-abiertos/pull/new/lab/linux-find-grep
6Abrir el PR en la web
Abrir el link o el botón "Compare & pull request" (en el simulador: gh pr create).
Revisar las branches: base mantenedor/labs-abiertos → main; compare tu-usuario/labs-abiertos → lab/.... Debe decir "Able to merge".
Título y descripción. Si el repo tiene plantilla de PR (.github/PULL_REQUEST_TEMPLATE.md), GitHub la carga sola: completala.
Revisar en Preview antes de crear (por ejemplo, pegar desde un editor de terminal cortó pedazos de texto).
Estructura de descripción que funcionó: Qué cambia, Por qué, Notas para revisar (decisiones que el mantenedor podría querer cambiar) y Checklist.
7Checks del PR
Check
Qué significa
Qué hacer
Vercel "Authorization required"
Los deploys de preview de forks necesitan que el mantenedor autorice
Nada, lo hace el mantenedor
CI "Waiting for status"
En el primer PR de alguien nuevo, GitHub no corre Actions hasta que el mantenedor aprueba
Nada
CodeQL "Cancelled after 15m"
Típicamente un incidente de GitHub ("The job was not acquired by Runner"). Se confirmó en githubstatus.com
Nada; el mantenedor puede re-ejecutarlo
"Cancelled" no es "Failed". Desde un fork no puedes re-ejecutar workflows del repo original. Pruébalo: gh pr checks
Los cambios se hacen en la misma branch: el PR se actualiza solo.
git switch lab/linux-find-intermedio
# editar
git add <archivos>
git commit # commit nuevo: el revisor ve qué cambió desde su revisión
git push
Después, comentar en el PR qué se cambió y usar "Re-request review".
Si main avanzó y necesitas lo nuevo: rebase
En el PR #33 había que editar un archivo que el mantenedor había cambiado en upstream. Primero hubo que poner la branch al día:
git pull --rebase upstream main
npm ci # porque package.json había cambiado
--rebase pone tus commits encima de lo último de upstream, como si hubieras empezado hoy. Sin --rebase, git crea un commit de merge.
Antes
Después del rebase
Los commits cambian de ID (e4832b1 pasó a ser ebef59a) porque se reescriben. Por eso el push siguiente necesita forzarse:
git push --force-with-lease
--force-with-lease reemplaza la branch remota, pero falla si en el remoto hay algo que tú no tienes localmente. Es la forma segura de forzar. Nunca uses --force a secas sobre trabajo compartido.
Salida esperada: + e4832b1...d2a7635 lab/... (forced update). El + indica que se reescribió.
Antes de rebasear hay que commitear o guardar los cambios pendientes: git no rebasea con el working tree sucio. Alternativa: git stash y después git stash pop.
Practícalo completo, con el rechazo por el permiso workflow incluido.
Fase 9: después del merge, limpiar
git switch main
git pull upstream main
git branch -d lab/linux-find-grep
git push origin --delete lab/linux-find-grep
git push origin main # opcional: actualizar el main de tu fork
Nombre
Qué es
origin/lab/linux-find-grep
Copia local que tu máquina guarda de la branch remota (git branch -r)
lab/linux-find-grep
Nombre real de la branch en GitHub (el que va en git push origin ...)
Si el mantenedor mergeó con squash, git branch -d te va a advertir que la branch "no está mergeada a HEAD": el commit en main es nuevo y tiene otro ID. Es normal; lo explica el error 4.2.
El mantenedor mergea, tú limpias.
Errores reales y cómo se resolvieron
Formato: síntoma (el mensaje exacto), causa, solución y lección. Casi todos se pueden reproducir en la terminal.
Referencia rápida de comandos usados
Comando
Qué hace
Cuándo lo usamos
Click en un comando para llevarlo a la terminal.
Hábitos que resumen todo
Una branch por cambio, siempre creada desde main actualizado.
git status antes de cada add y cada commit.
Agregar archivos concretos, nunca git add . a ciegas.
Commits chicos con título en imperativo y body que explique el porqué.
Revisar lo que va a ver el revisor:git diff --stat upstream/main HEAD.
Sincronizar el fork antes de rebasear sobre upstream.
Después de un rebase: --force-with-lease, nunca --force.
Correcciones de revisión en commits nuevos, en la misma branch.
Avisar en el PR qué cambiaste y pedir de nuevo la revisión.
No mezclar temas en un PR: un lab nuevo no lleva arreglos de otras partes; eso va en un PR aparte.
Misiones
Cada misión arranca de un estado preparado (repo, fork, PRs) y avanza sola a medida que haces las cosas bien en la terminal. Si te trabas, el botón 💡 Pista te escribe el comienzo del comando (por ejemplo git clone) y tú completas el resto. reset reinicia la misión.
Mini quiz
Diez preguntas sobre el flujo y sus errores.
~
Grafo del repo
Commit
Rama
HEAD
Copia remota
GitHub
Etiqueta
Merge
Pasa el mouse por la leyenda o haz click en un commit para ver qué es.
Git en la práctica