Cheat sheet de Git y GitHub Actions

Qué vas a provocar: Provocar los estados de git status, ver qué entra en un commit cuando el archivo cambió después del add, y traducir nombres a SHAs.

Necesitas: git 2.28 o más nuevo (git --version) y tu nombre y email configurados (git config --global user.name y user.email). Todo es local: no necesitas cuenta de GitHub.

1. Paso 1Copiar

   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15\n' > gateway/app/main.py
   printf 'RESIZE_SHORT = 256\n' > gateway/app/preprocess.py
   git add . && git commit -m "gateway: primera versión"

   Qué deberías ver: Initialized empty Git repository in /Users/<tú>/lab-git/.git/ y después [main (root-commit) <sha>] gateway: primera versión, con 2 files changed, 2 insertions(+). El <sha> cambia en cada máquina.

2. Paso 2Copiar

   printf 'INFER_TIMEOUT_S = 0.12\n' > gateway/app/main.py
   git add gateway/app/main.py
   printf 'RESIZE_SHORT = 224\n' > gateway/app/preprocess.py
   printf 'TOKEN=no-lo-subas\n' > .env
   git status -s

   Qué deberías ver: Tres líneas: M gateway/app/main.py (la M a la izquierda: está en staging), luego gateway/app/preprocess.py con la M a la derecha (cambió solo en disco) y ?? .env (git no lo sigue).

3. Paso 3Copiar

   printf '# probar 100 ms\n' >> gateway/app/main.py
   git status -s

   Qué deberías ver: MM gateway/app/main.py: una M por columna. El staging tiene el 0.12 de tu add; el disco tiene además la línea nueva.

4. Paso 4Copiar

   git diff --staged

   Qué deberías ver: Lo que entraría en el commit: -INFER_TIMEOUT_S = 0.15 y +INFER_TIMEOUT_S = 0.12. Nada de la línea # probar 100 ms.

5. Paso 5Copiar

   git diff

   Qué deberías ver: Lo que está en disco y no en staging: +# probar 100 ms en main.py, y -RESIZE_SHORT = 256 / +RESIZE_SHORT = 224 en preprocess.py.

6. Paso 6Copiar

   git commit -m "gateway: bajar INFER_TIMEOUT_S a 120 ms"
   git status -s

   Qué deberías ver: [main <sha>] gateway: bajar INFER_TIMEOUT_S a 120 ms con 1 file changed, 1 insertion(+), 1 deletion(-). Después siguen tres líneas, ahora con la M a la derecha en main.py: la línea # probar 100 ms no entró al commit.

7. Paso 7Copiar

   git log --oneline
   git rev-parse --short HEAD
   git rev-parse --short HEAD~1
   git rev-parse HEAD
   cat .git/HEAD

   Qué deberías ver: Dos commits en el log, dos SHAs cortos de 7 caracteres (HEAD y HEAD~1), el SHA completo de 40 y ref: refs/heads/main: HEAD apunta a la rama, no al commit. Si le pasas dos nombres a rev-parse --short, responde fatal: Needed a single revision.

8. Paso 8Copiar

   git reflog

   Qué deberías ver: Dos líneas, la más nueva arriba: HEAD@{0}: commit: gateway: bajar INFER_TIMEOUT_S a 120 ms y HEAD@{1}: commit (initial): gateway: primera versión. En la terminal, la primera lleva además (HEAD -> main).

9. Paso 9Copiar

   cd ~ && rm -rf ~/lab-git

   Qué deberías ver: No imprime nada. Va con -f porque git guarda sus objetos como solo lectura y rm -r te preguntaría por cada uno (override r--r--r--…?).

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Recorrer la cadena con un remoto local: rama, commit, push, revisión desde otra copia, merge, y el SHA que sería el tag de la imagen.

Necesitas: git 2.28 o más nuevo (git --version) y tu nombre y email configurados (git config --global user.name y user.email). Todo es local: no necesitas cuenta de GitHub.

1. Paso 1Copiar

   git init --bare -b main ~/lab-git-remote.git
   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15\n' > gateway/app/main.py
   git add . && git commit -m "gateway: primera versión"
   git remote add origin ~/lab-git-remote.git
   git push -u origin main

   Qué deberías ver: Dos Initialized empty Git repository (el remoto y tu repo), el commit [main (root-commit) <sha>] y el push: * [new branch] main -> main y branch 'main' set up to track 'origin/main'. La carpeta lab-git-remote.git hace el papel de GitHub: con --bare guarda solo la historia, sin archivos para editar, como un repo en GitHub.

2. Paso 2Copiar

   git switch -c feat/gateway-timeout
   printf 'INFER_TIMEOUT_S = 0.12\n' > gateway/app/main.py
   git add gateway/app/main.py
   git diff --staged --stat
   git commit -m "gateway: bajar INFER_TIMEOUT_S a 120 ms"

   Qué deberías ver: Switched to a new branch 'feat/gateway-timeout', el resumen gateway/app/main.py | 2 +- (lo que entra al commit) y [feat/gateway-timeout <sha>] gateway: bajar INFER_TIMEOUT_S a 120 ms.

3. Paso 3Copiar

   git push -u origin feat/gateway-timeout

   Qué deberías ver: * [new branch] feat/gateway-timeout -> feat/gateway-timeout y branch 'feat/gateway-timeout' set up to track 'origin/feat/gateway-timeout'. Contra GitHub, aquí aparecerían líneas remote: con el link para abrir el PR.

4. Paso 4Copiar

   git clone ~/lab-git-remote.git ~/lab-git-equipo
   cd ~/lab-git-equipo
   git switch feat/gateway-timeout
   git diff main...feat/gateway-timeout

   Qué deberías ver: Cloning into … y done. git switch encuentra la rama en el remoto y la crea conectada (set up to track). El diff muestra -INFER_TIMEOUT_S = 0.15 y +INFER_TIMEOUT_S = 0.12: lo mismo que la pestaña Files changed del PR, que también compara contra el punto donde nació la rama.

5. Paso 5Copiar

   git switch main
   git merge --no-ff --no-edit feat/gateway-timeout
   git push

   Qué deberías ver: Merge made by the 'ort' strategy. y el push de main (<sha>..<sha> main -> main). --no-ff crea un commit de merge aunque bastara con mover la etiqueta, como el botón Create a merge commit de GitHub; --no-edit acepta el mensaje sin abrir el editor.

6. Paso 6Copiar

   cd ~/lab-git
   git switch main
   git pull
   git log --oneline --graph
   git rev-parse --short=7 HEAD

   Qué deberías ver: Ojo: git switch main dice Your branch is up to date with 'origin/main'., y es falso: es según tu último fetch. git pull trae el merge (Updating <sha>..<sha>, Fast-forward: tu main solo avanza hasta el merge). El log dibuja el merge con sus dos padres, y rev-parse imprime 7 caracteres: el tag que tendría la imagen.

7. Paso 7Copiar

   git branch -d feat/gateway-timeout
   git push origin --delete feat/gateway-timeout

   Qué deberías ver: Deleted branch feat/gateway-timeout (was <sha>). y, en el remoto, - [deleted] feat/gateway-timeout. git branch -d solo borra una rama si sus commits ya están a salvo en la rama donde estás o en su rama remota; si no, se niega con not fully merged.

8. Paso 8Copiar

   cd ~ && rm -rf ~/lab-git ~/lab-git-remote.git ~/lab-git-equipo

   Qué deberías ver: No imprime nada: borra tu repo, el "GitHub" local y la copia de la otra persona.

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Abrir .git y ver que un commit es una foto con padre, que una rama es un archivo de 41 bytes y que HEAD dice dónde estás.

Necesitas: git 2.28 o más nuevo (git --version) y tu nombre y email configurados (git config --global user.name y user.email). Todo es local: no necesitas cuenta de GitHub.

1. Paso 1Copiar

   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15\n' > gateway/app/main.py
   git add . && git commit -m "gateway: primera versión"

   Qué deberías ver: Initialized empty Git repository in /Users/<tú>/lab-git/.git/ y [main (root-commit) <sha>] gateway: primera versión.

2. Paso 2Copiar

   cat .git/HEAD
   cat .git/refs/heads/main
   git cat-file -p HEAD
   git cat-file -p 'HEAD^{tree}'

   Qué deberías ver: ref: refs/heads/main; el SHA completo de 40 caracteres (la rama es solo eso); el commit por dentro: tree, author, committer y el mensaje, sin parent porque es el primero; y la foto: 040000 tree <sha> gateway (cada carpeta es otro tree y cada archivo, un blob).

3. Paso 3Copiar

   git branch feat/gateway-timeout
   git branch -v
   cat .git/refs/heads/feat/gateway-timeout

   Qué deberías ver: Las dos ramas con el mismo SHA corto y el mismo mensaje, y el archivo de la rama nueva con el mismo SHA que main: crear una rama no copió nada.

4. Paso 4Copiar

   git switch feat/gateway-timeout
   printf 'INFER_TIMEOUT_S = 0.12\n' > gateway/app/main.py
   git commit -am "gateway: bajar INFER_TIMEOUT_S a 120 ms"
   git branch -v

   Qué deberías ver: Switched to branch 'feat/gateway-timeout', el commit nuevo, y en branch -v la rama nueva en otro SHA mientras main sigue donde estaba: solo se movió la etiqueta donde está HEAD. (-a agrega los cambios de archivos que git ya seguía.)

5. Paso 5Copiar

   git cat-file -p HEAD

   Qué deberías ver: Ahora aparece parent <SHA de main>: el commit nuevo apunta al anterior.

6. Paso 6Copiar

   git switch main
   cat gateway/app/main.py
   git switch -
   cat gateway/app/main.py

   Qué deberías ver: INFER_TIMEOUT_S = 0.15 en main y INFER_TIMEOUT_S = 0.12 en la rama: cambiar de rama reescribió el archivo en disco. git switch - vuelve a la rama anterior.

7. Paso 7Copiar

   git switch --detach HEAD~1
   cat .git/HEAD
   git status

   Qué deberías ver: HEAD is now at <sha> gateway: primera versión; .git/HEAD ahora tiene un SHA en vez de ref: …; y git status dice HEAD detached at <sha>. Sin --detach, git switch <sha> se niega: fatal: a branch is expected, got commit '<sha>', con un hint que sugiere --detach.

8. Paso 8Copiar

   git switch -
   git status -sb

   Qué deberías ver: Previous HEAD position was <sha> gateway: primera versión y Switched to branch 'feat/gateway-timeout'; status -sb vuelve a mostrar ## feat/gateway-timeout.

9. Paso 9Copiar

   cd ~ && rm -rf ~/lab-git

   Qué deberías ver: No imprime nada.

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Trabajar con otra persona sobre un remoto local: ver que fetch no toca tus archivos, provocar un push rechazado y un pull que se niega, resolverlo con pull --rebase y, al final, armar un .gitignore.

Necesitas: git 2.28 o más nuevo y tu nombre y email configurados. Todo es local: el "GitHub" es la carpeta ~/lab-git-remote.git y la otra persona del equipo trabaja en ~/lab-git-equipo.

1. Paso 1Copiar

   git init --bare -b main ~/lab-git-remote.git
   git clone ~/lab-git-remote.git ~/lab-git-equipo
   cd ~/lab-git-equipo
   git config user.name "Leo Ruiz"
   git config user.email "leo@example.com"
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15\n' > gateway/app/main.py
   printf 'RESIZE_SHORT = 256\n' > gateway/app/preprocess.py
   git add . && git commit -m "gateway: primera versión" && git push -u origin main

   Qué deberías ver: Initialized empty Git repository in …/lab-git-remote.git/, el aviso warning: You appear to have cloned an empty repository. (el remoto todavía no tiene commits), el commit y * [new branch] main -> main. Leo Ruiz es la otra persona del equipo: user.name y user.email solo cambian dentro de esa copia. --bare crea un repo solo con la historia, sin archivos para editar, como el de GitHub.

2. Paso 2Copiar

   git clone ~/lab-git-remote.git ~/lab-git
   cd ~/lab-git
   git config pull.ff only
   git switch -c feat/gateway-timeout
   printf 'INFER_TIMEOUT_S = 0.12\n' > gateway/app/main.py
   git commit -am "gateway: bajar INFER_TIMEOUT_S a 120 ms"
   git push -u origin feat/gateway-timeout

   Qué deberías ver: Cloning into … y done.; Switched to a new branch 'feat/gateway-timeout'; el commit; y el push con * [new branch] y set up to track. pull.ff only queda solo en este repo (sin --global).

3. Paso 3Copiar

   cd ~/lab-git-equipo
   git fetch
   git switch feat/gateway-timeout
   printf 'MAX_TOP_K = 20\n' >> gateway/app/main.py
   git commit -am "review: tope de top_k" && git push

   Qué deberías ver: El fetch trae tu rama (* [new branch] feat/gateway-timeout -> origin/feat/gateway-timeout), git switch la crea conectada (set up to track), y el push sube review: tope de top_k. En GitHub pasa lo mismo cuando alguien aplica una sugerencia de la review con Commit suggestion: un commit nuevo en tu rama del remoto.

4. Paso 4Copiar

   cd ~/lab-git
   git status -sb
   git fetch
   git status -sb
   git log --oneline HEAD..origin/feat/gateway-timeout

   Qué deberías ver: El primer status dice ## feat/gateway-timeout...origin/feat/gateway-timeout, sin behind: status no le pregunta al remoto. Después del fetch dice [behind 1] y el log muestra review: tope de top_k. Tus archivos no cambiaron.

5. Paso 5Copiar

   printf 'RESIZE_SHORT = 256  # igual que en training\n' > gateway/app/preprocess.py
   git commit -am "preprocess: comentar RESIZE_SHORT"
   git status -sb
   git push

   Qué deberías ver: [ahead 1, behind 1]: divergieron. El push se rechaza: ! [rejected] feat/gateway-timeout -> feat/gateway-timeout (non-fast-forward), con un hint que sugiere git pull. Sin el fetch del paso anterior, diría (fetch first).

6. Paso 6Copiar

   git pull

   Qué deberías ver: Se niega: fatal: Not possible to fast-forward, aborting., después de un hint que sugiere merge o rebase. Tu rama y tus archivos no cambiaron. Sin ninguna config (desde Git 2.33.1), el mensaje sería fatal: Need to specify how to reconcile divergent branches.

7. Paso 7Copiar

   git pull --rebase
   git log --oneline --graph
   git push

   Qué deberías ver: Successfully rebased and updated refs/heads/feat/gateway-timeout. El log queda en línea recta, con tu commit encima del de la review y con otro SHA. El push ahora se acepta: <sha>..<sha> feat/gateway-timeout -> feat/gateway-timeout.

8. Paso 8Copiar

   printf '.env\n__pycache__/\n*.onnx\n' > .gitignore
   printf 'TOKEN=no-lo-subas\n' > .env
   mkdir -p model && printf 'pesos' > model/classifier.onnx
   git status -s
   git check-ignore -v .env model/classifier.onnx

   Qué deberías ver: status -s muestra solo ?? .gitignore: .env y model/ ni aparecen. check-ignore -v dice qué línea ignora cada uno: .gitignore:1:.env y .gitignore:3:*.onnx.

9. Paso 9Copiar

   cd ~ && rm -rf ~/lab-git ~/lab-git-remote.git ~/lab-git-equipo

   Qué deberías ver: No imprime nada.

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Provocar un conflicto real en la misma línea, resolverlo con merge, repetirlo con rebase para ver las marcas invertidas, y terminar con un fast-forward.

Necesitas: git 2.28 o más nuevo (2.35 para zdiff3; git --version) y tu nombre y email configurados (git config --global user.name y user.email). Todo es local: no necesitas cuenta de GitHub.

1. Paso 1Copiar

   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15  # 150 ms\nMAX_TOP_K = 20\n' > gateway/app/main.py
   git add . && git commit -m "gateway: primera versión"

   Qué deberías ver: Initialized empty Git repository in /Users/<tú>/lab-git/.git/ y [main (root-commit) <sha>] gateway: primera versión, con 2 insertions(+).

2. Paso 2Copiar

   git switch -c feat/gateway-timeout
   printf 'INFER_TIMEOUT_S = 0.12  # 120 ms: deja margen al preprocess\nMAX_TOP_K = 20\n' > gateway/app/main.py
   git commit -am "gateway: bajar INFER_TIMEOUT_S a 120 ms"
   git switch main
   printf 'INFER_TIMEOUT_S = 0.18  # 180 ms: hotfix por 504 en el pico\nMAX_TOP_K = 20\n' > gateway/app/main.py
   git commit -am "hotfix: subir INFER_TIMEOUT_S a 180 ms"
   git log --oneline --graph --all

   Qué deberías ver: Dos commits, uno en cada rama, y el log dibuja la bifurcación: tu commit, el hotfix en otra columna (|) y la primera versión abajo, donde se separan.

3. Paso 3Copiar

   git switch feat/gateway-timeout
   git merge main

   Qué deberías ver: Auto-merging gateway/app/main.py, CONFLICT (content): Merge conflict in gateway/app/main.py y Automatic merge failed; fix conflicts and then commit the result.

4. Paso 4Copiar

   git status -s
   cat gateway/app/main.py
   git diff --check

   Qué deberías ver: UU gateway/app/main.py. El archivo tiene <<<<<<< HEAD, tu línea de 0.12, =======, la línea de 0.18 y >>>>>>> main; MAX_TOP_K = 20 quedó fuera de las marcas porque nadie la tocó. diff --check lista cada marca: gateway/app/main.py:1: leftover conflict marker, y lo mismo en las líneas 3 y 5. Si ya configuraste merge.conflictStyle zdiff3, verás además un bloque ||||||| con la línea de la base, y una marca más.

5. Paso 5Copiar

   printf 'INFER_TIMEOUT_S = 0.12  # 120 ms: el deadline nuevo evita los 504\nMAX_TOP_K = 20\n' > gateway/app/main.py
   git diff --check
   git add gateway/app/main.py
   git commit --no-edit
   git log --oneline --graph

   Qué deberías ver: diff --check ya no imprime nada. El commit es [feat/gateway-timeout <sha>] Merge branch 'main' into feat/gateway-timeout y el log muestra el merge con sus dos padres.

6. Paso 6Copiar

   git reset --hard ORIG_HEAD
   git rebase main

   Qué deberías ver: HEAD is now at <sha> gateway: bajar INFER_TIMEOUT_S a 120 ms (ORIG_HEAD es donde estabas antes del merge: lo deshiciste). El rebase choca en la misma línea: CONFLICT (content), error: could not apply <sha>… y un hint con --continue, --skip y --abort.

7. Paso 7Copiar

   cat gateway/app/main.py

   Qué deberías ver: Las marcas invertidas: después de <<<<<<< HEAD viene el 0.18 de main, y tu 0.12 va al final, junto a >>>>>>> <sha> (gateway: bajar INFER_TIMEOUT_S a 120 ms). En un rebase, HEAD es la base y "el otro lado" es tu commit. (Con zdiff3, la base aparece en medio, tras |||||||.)

8. Paso 8Copiar

   printf 'INFER_TIMEOUT_S = 0.12  # 120 ms: el deadline nuevo evita los 504\nMAX_TOP_K = 20\n' > gateway/app/main.py
   git add gateway/app/main.py
   GIT_EDITOR=true git rebase --continue
   git log --oneline --graph --all

   Qué deberías ver: Successfully rebased and updated refs/heads/feat/gateway-timeout. El log es una línea recta: tu commit (con otro SHA) encima del hotfix. Sin GIT_EDITOR=true se abriría tu editor con el mensaje; si es vim, sales con :wq y Enter.

9. Paso 9Copiar

   git switch main
   git merge feat/gateway-timeout
   git branch -d feat/gateway-timeout

   Qué deberías ver: Updating <sha>..<sha>, Fast-forward: después del rebase, main solo avanza la etiqueta. Y Deleted branch feat/gateway-timeout (was <sha>).

10. Paso 10Copiar

    cd ~ && rm -rf ~/lab-git

    Qué deberías ver: No imprime nada.

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Probar amend, los tres modos de reset, el rescate de un commit "perdido" con el reflog, un revert y el stash, mirando qué queda en staging y en disco después de cada uno.

Necesitas: git 2.28 o más nuevo (git --version) y tu nombre y email configurados (git config --global user.name y user.email). Todo es local: no necesitas cuenta de GitHub.

1. Paso 1Copiar

   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   mkdir -p gateway/app
   printf 'INFER_TIMEOUT_S = 0.15\n' > gateway/app/main.py
   git add . && git commit -m "gateway: primera versión"
   printf 'INFER_TIMEOUT_S = 0.12\n' > gateway/app/main.py
   git commit -am "gateway: bajar el timout"

   Qué deberías ver: Initialized empty Git repository in /Users/<tú>/lab-git/.git/, el commit (root-commit) y [main <sha>] gateway: bajar el timout, con un typo en el mensaje.

2. Paso 2Copiar

   printf 'MAX_TOP_K = 20\n' > gateway/app/limits.py
   git add gateway/app/limits.py
   git commit --amend -m "gateway: bajar INFER_TIMEOUT_S a 120 ms"
   git log --oneline

   Qué deberías ver: [main <sha nuevo>] gateway: bajar INFER_TIMEOUT_S a 120 ms, con una línea Date: (amend conserva la fecha del autor original) y 2 files changed. El log sigue teniendo dos commits: el viejo fue reemplazado, con otro SHA.

3. Paso 3Copiar

   git reset --soft HEAD~1
   git status -s
   git commit -m "gateway: bajar INFER_TIMEOUT_S a 120 ms"

   Qué deberías ver: A gateway/app/limits.py y M gateway/app/main.py, con la letra a la izquierda: --soft dejó todo en staging. El commit lo rehace igual.

4. Paso 4Copiar

   git reset HEAD~1
   git status -s
   git add . && git commit -m "gateway: bajar INFER_TIMEOUT_S a 120 ms"

   Qué deberías ver: Unstaged changes after reset: y, debajo, M y gateway/app/main.py. Después, status muestra main.py con la M a la derecha y ?? gateway/app/limits.py: --mixed sacó todo del staging, pero tus archivos siguen como estaban.

5. Paso 5Copiar

   git reset --hard HEAD~1
   git log --oneline
   ls gateway/app

   Qué deberías ver: HEAD is now at <sha> gateway: primera versión. El log tiene un solo commit y ls muestra solo main.py: limits.py desapareció de disco. El commit no está perdido…

6. Paso 6Copiar

   git reflog -n 3

   Qué deberías ver: Tres líneas: HEAD@{0}: reset: moving to HEAD~1, HEAD@{1}: commit: gateway: bajar INFER_TIMEOUT_S a 120 ms (el commit "perdido", con su SHA) y HEAD@{2}: reset: moving to HEAD~1.

7. Paso 7Copiar

   git branch rescate 'HEAD@{1}'
   git merge --ff-only rescate
   git branch -d rescate
   git log --oneline
   ls gateway/app

   Qué deberías ver: Updating <sha>..<sha>, Fast-forward (main solo avanza hasta el commit rescatado) y create mode 100644 gateway/app/limits.py; Deleted branch rescate (was <sha>). Otra vez dos commits, y limits.py volvió. Las comillas en 'HEAD@{1}' evitan que el shell toque las llaves.

8. Paso 8Copiar

   git revert --no-edit HEAD
   git log --oneline
   cat gateway/app/main.py

   Qué deberías ver: [main <sha>] Revert "gateway: bajar INFER_TIMEOUT_S a 120 ms" y delete mode 100644 gateway/app/limits.py. Tres commits: el revert se suma arriba, y main.py vuelve a INFER_TIMEOUT_S = 0.15. Nada se reescribió.

9. Paso 9Copiar

   printf 'INFER_TIMEOUT_S = 0.10\n' > gateway/app/main.py
   printf 'probar con 100 ms\n' > notas.txt
   git stash push -u -m "probar 100 ms"
   git status -s
   git stash list

   Qué deberías ver: Saved working directory and index state On main: probar 100 ms. status -s no imprime nada (con -u también se guardó notas.txt) y la lista tiene stash@{0}: On main: probar 100 ms.

10. Paso 10Copiar

    git stash pop
    git status -s

    Qué deberías ver: El status largo con main.py modificado y notas.txt sin seguir, y al final Dropped refs/stash@{0} (<sha>). Después, status -s: main.py con la M a la derecha y ?? notas.txt.

11. Paso 11Copiar

    cd ~ && rm -rf ~/lab-git

    Qué deberías ver: No imprime nada.

Probado de verdad en una carpeta de prueba (git 2.50.1). Los SHAs y las rutas cambian en cada máquina.

Qué vas a provocar: Practicar con un remoto local lo que harás con GitHub: push con upstream, el error de una rama sin upstream y qué tags viajan con git push.

Necesitas: Git en tu Mac (viene con las Command Line Tools de Xcode). No necesitas cuenta de GitHub.

1. Paso 1Copiar

   git init --bare -b main ~/lab-git-remote.git
   mkdir ~/lab-git && cd ~/lab-git && git init -b main
   git remote add origin ~/lab-git-remote.git
   git remote -v

   Qué deberías ver: Dos líneas: origin con la ruta de lab-git-remote.git, una (fetch) y otra (push). Ese repo bare (sin carpeta de trabajo) hace de GitHub. Si quedaron carpetas de otro lab, bórralas primero con el último paso.

2. Paso 2Copiar

   echo "# gateway" > README.md && git add README.md && git commit -m "primer commit"
   git push -u origin main
   git status -sb

   Qué deberías ver: * [new branch] main -> main y branch 'main' set up to track 'origin/main'. status muestra ## main...origin/main: tu main sigue a la del remoto.

3. Paso 3Copiar

   git switch -c feat/slot-wait-env
   echo "SLOT_WAIT_S=0.05" > config.env && git add config.env && git commit -m "gateway: SLOT_WAIT_S por env"
   git push

   Qué deberías ver: fatal: The current branch feat/slot-wait-env has no upstream branch., con la sugerencia git push --set-upstream origin feat/slot-wait-env. Si tienes push.autoSetupRemote activado, el push funciona directo.

4. Paso 4Copiar

   git push -u origin feat/slot-wait-env
   git branch -vv

   Qué deberías ver: [new branch] y, en branch -vv, cada rama con su upstream entre corchetes: [origin/feat/slot-wait-env] y [origin/main].

5. Paso 5Copiar

   git switch main
   git tag -a v1.0.0 -m "primera release del gateway"
   git tag borrador
   git push
   git ls-remote --tags origin

   Qué deberías ver: Everything up-to-date, y ls-remote no imprime nada: git push no sube tags por su cuenta.

6. Paso 6Copiar

   git push --follow-tags
   git ls-remote --tags origin

   Qué deberías ver: [new tag] v1.0.0 -> v1.0.0: solo viaja el anotado. ls-remote lo lista dos veces: refs/tags/v1.0.0 (el objeto tag) y refs/tags/v1.0.0^{} (el commit al que apunta). borrador, que es liviano, se quedó en tu Mac.

7. Paso 7Copiar

   git push origin borrador
   git cat-file -t v1.0.0
   git cat-file -t borrador

   Qué deberías ver: [new tag] borrador -> borrador, y después tag y commit: el anotado es un objeto propio; el liviano es solo un nombre para el commit.

8. Paso 8Copiar

   cd ~ && rm -rf ~/lab-git ~/lab-git-remote.git

   Qué deberías ver: Nada: borra el repo y el remoto del lab.

Probado de verdad en una carpeta de prueba (git 2.50.1).

Qué vas a provocar: Ver en un repo de prueba cómo on, needs, if y outputs se vuelven un run: qué jobs corren, cuáles se saltan y qué pasa cuando uno falla.

Necesitas: una cuenta de GitHub, un repo vacío lab-actions y git configurado para hacer push (SSH, o gh auth login con la URL https://github.com/TU_USUARIO/lab-actions.git). Deja el repo: lo usan los labs de las secciones 7, 8 y 9. Gasta unos 2 minutos de Actions.

1. Paso 1Copiar

   mkdir -p ~/lab-actions/.github/workflows && cd ~/lab-actions
   git init -b main
   git remote add origin git@github.com:TU_USUARIO/lab-actions.git
   cat > .github/workflows/anatomia.yml <<'EOF'
   name: anatomia
   on:
     push:
       branches: [main]
     workflow_dispatch:
       inputs:
         saludo:
           type: string
           default: hola
   permissions:
     contents: read
   jobs:
     primero:
       runs-on: ubuntu-24.04
       timeout-minutes: 5
       outputs:
         corto: ${{ steps.sha.outputs.corto }}
       steps:
         - id: sha
           run: echo "corto=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
         - run: echo "evento=$GITHUB_EVENT_NAME rama=$GITHUB_REF_NAME"
     segundo:
       needs: primero
       runs-on: ubuntu-24.04
       timeout-minutes: 5
       steps:
         - env:
             CORTO: ${{ needs.primero.outputs.corto }}
             SALUDO: ${{ inputs.saludo }}
           run: echo "commit $CORTO, saludo '${SALUDO:-sin input}'"
     solo-manual:
       if: github.event_name == 'workflow_dispatch'
       runs-on: ubuntu-24.04
       timeout-minutes: 5
       steps:
         - run: echo "este job solo corre con el boton Run workflow"
   EOF
   git add . && git commit -m "workflow de prueba" && git push -u origin main

   Qué deberías ver: Antes, crea en github.com un repo vacío llamado lab-actions (New repository, sin README) y cambia TU_USUARIO por tu usuario. En la pestaña Actions aparece el run anatomia: primero, después segundo (imprime el commit corto y saludo 'sin input') y solo-manual en gris, porque su if es falso en un push.

2. Paso 2Copiar

   github.com → lab-actions → Actions → anatomia → Run workflow → saludo: buenas → Run workflow

   Qué deberías ver: Un run nuevo con evento workflow_dispatch: corren los tres jobs, solo-manual incluido, y segundo imprime saludo 'buenas'.

3. Paso 3Copiar

   perl -pi -e 's/^      - id: sha$/      - run: exit 1\n      - id: sha/' .github/workflows/anatomia.yml
   git commit -am "primero falla a propósito" && git push

   Qué deberías ver: primero en rojo y segundo en gris (skipped): un job que necesita a otro que falló no corre. El run termina en rojo.

4. Paso 4Copiar

   perl -pi -e 's/^    needs: primero$/    needs: primero\n    if: always()/' .github/workflows/anatomia.yml
   git commit -am "segundo corre siempre" && git push

   Qué deberías ver: Ahora segundo corre aunque primero falló, pero imprime commit vacío: el paso que escribía la salida nunca llegó a correr.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Ver una caché pasar de miss a hit, una matrix de dos versiones de Python y un test rojo que deja su reporte como artifact.

Necesitas: el repo lab-actions de la sección 6 y push con tu acceso normal de git. Gasta unos 5 minutos de Actions.

1. Paso 1Copiar

   cd ~/lab-actions && mkdir -p tests
   printf 'def suma(a, b):\n    return a + b\n' > calc.py
   printf 'from calc import suma\n\n\ndef test_suma():\n    assert suma(2, 2) == 4\n' > tests/test_calc.py
   printf '[pytest]\npythonpath = .\ntestpaths = tests\n' > pytest.ini
   printf 'pytest==9.1.1\n' > requirements.txt
   cat > .github/workflows/tests.yml <<'EOF'
   name: tests
   on:
     push:
       branches: [main]
     pull_request:
   permissions:
     contents: read
   jobs:
     tests:
       runs-on: ubuntu-24.04
       timeout-minutes: 10
       strategy:
         fail-fast: false
         matrix:
           python-version: ["3.13", "3.14"]
       steps:
         - uses: actions/checkout@v7
           with: { persist-credentials: false }
         - uses: actions/setup-python@v7
           with:
             python-version: ${{ matrix.python-version }}
             cache: pip
         - run: pip install -r requirements.txt
         - run: pytest --junit-xml=reporte-${{ matrix.python-version }}.xml
         - if: failure()
           uses: actions/upload-artifact@v7
           with:
             name: reporte-${{ matrix.python-version }}
             path: reporte-${{ matrix.python-version }}.xml
             retention-days: 3
   EOF
   git add . && git commit -m "tests con matrix" && git push

   Qué deberías ver: Dos checks: tests (3.13) y tests (3.14). En el log de setup-python, la primera vez no hay caché; el paso Post de setup-python la guarda al final.

2. Paso 2Copiar

   git commit --allow-empty -m "otra vuelta" && git push

   Qué deberías ver: Ahora setup-python restaura la caché (cache-hit: true) y pip instala sin descargar.

3. Paso 3Copiar

   git switch -c test-roto
   sed -i '' 's/== 4/== 5/' tests/test_calc.py
   git commit -am "test roto a propósito" && git push -u origin test-roto

   Qué deberías ver: En github.com, Compare & pull request → Create pull request. Los dos checks quedan en rojo (fail-fast: false deja terminar a ambos) y, al pie de la página del run, aparecen reporte-3.13 y reporte-3.14 para descargar.

4. Paso 4Copiar

   github.com → Settings → Rulesets → New ruleset → New branch ruleset
   Enforcement status: Active · Target branches: Add a target → la rama por defecto
   Require status checks before merging → agrega tests (3.13) y tests (3.14) con + → Create

   Qué deberías ver: Vuelve al PR: el merge queda bloqueado mientras los checks estén en rojo. Solo en un repo público, o privado con Pro, Team o Enterprise.

5. Paso 5Copiar

   git switch main && git branch -D test-roto && git push origin --delete test-roto

   Qué deberías ver: Deleted branch test-roto y [deleted] test-roto: GitHub cierra el PR solo, porque su rama ya no existe. Borra el ruleset si no lo quieres.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Ver por dentro el token OIDC de un job (sus claims, nunca el token) y cómo cambia el sub cuando el job usa un environment.

Necesitas: el repo lab-actions de la sección 6, público (con el plan Free, un repo privado no tiene environments), y push con tu acceso normal de git. No necesitas cuenta de AWS: el token se pide pero no se usa.

1. Paso 1Copiar

   cd ~/lab-actions
   cat > .github/workflows/oidc.yml <<'EOF'
   name: oidc
   on: workflow_dispatch
   permissions:
     contents: read
   jobs:
     sin-environment:
       runs-on: ubuntu-24.04
       timeout-minutes: 5
       permissions:
         id-token: write
       steps:
         - run: |
             test -n "$ACTIONS_ID_TOKEN_REQUEST_URL" || { echo "sin id-token: write no hay token OIDC"; exit 1; }
             curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
               "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" | jq -r .value | cut -d. -f2 > payload.txt
             python3 -c 'import base64,json; p=open("payload.txt").read().strip(); c=json.loads(base64.urlsafe_b64decode(p + "=" * (-len(p) % 4))); print({k: c.get(k) for k in ("sub", "aud", "ref", "environment", "repository_owner_id", "repository_id")})'
     con-environment:
       runs-on: ubuntu-24.04
       timeout-minutes: 5
       environment: lab
       permissions:
         id-token: write
       steps:
         - run: |
             test -n "$ACTIONS_ID_TOKEN_REQUEST_URL" || { echo "sin id-token: write no hay token OIDC"; exit 1; }
             curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
               "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" | jq -r .value | cut -d. -f2 > payload.txt
             python3 -c 'import base64,json; p=open("payload.txt").read().strip(); c=json.loads(base64.urlsafe_b64decode(p + "=" * (-len(p) % 4))); print({k: c.get(k) for k in ("sub", "aud", "ref", "environment", "repository_owner_id", "repository_id")})'
   EOF
   git add . && git commit -m "lab oidc" && git push

   Qué deberías ver: El workflow oidc queda en el repo. Solo imprime claims: el token completo nunca sale al log.

2. Paso 2Copiar

   github.com → lab-actions → Actions → oidc → Run workflow

   Qué deberías ver: sin-environment imprime aud 'sts.amazonaws.com' y un sub con IDs, como 'repo:TU_USUARIO@12345678/lab-actions@987654321:ref:refs/heads/main': tu repo es de después del 15 de julio de 2026, y esos números son el repository_owner_id y el repository_id que se imprimen al lado. con-environment imprime un sub que termina en ':environment:lab' y environment 'lab'. En Settings → Environments aparece lab: el run lo creó, sin reglas.

3. Paso 3Copiar

   perl -0pi -e 's/    permissions:\n      id-token: write\n//' .github/workflows/oidc.yml
   git commit -am "sin id-token" && git push
   # y otra vez: Actions → oidc → Run workflow

   Qué deberías ver: sin-environment falla con sin id-token: write no hay token OIDC: sin ese permiso, el job no recibe con qué pedir el token. con-environment sigue funcionando.

4. Paso 4Copiar

   git rm -q .github/workflows/oidc.yml && git commit -m "fin del lab oidc" && git push

   Qué deberías ver: El workflow desaparece de Actions. Borra el environment lab en Settings → Environments.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Que CI construya y publique una imagen linux/amd64 con tag = SHA en GitHub Container Registry (GHCR), sin AWS y sin secrets tuyos, y comprobar desde tu Mac para qué CPU es.

Necesitas: el repo lab-actions de la sección 6, público; Docker Desktop corriendo en tu Mac e internet. No necesitas AWS ni crear tokens.

1. Paso 1Copiar

   cd ~/lab-actions
   printf 'FROM busybox:1.38\nCMD ["echo", "hola desde CI"]\n' > Dockerfile
   cat > .github/workflows/imagen.yml <<'EOF'
   name: imagen
   on:
     push:
       branches: [main]
   permissions:
     contents: read
   jobs:
     imagen:
       runs-on: ubuntu-24.04
       timeout-minutes: 15
       permissions:
         contents: read
         packages: write
       steps:
         - uses: actions/checkout@v7
           with: { persist-credentials: false }
         - run: echo "IMAGEN=ghcr.io/${GITHUB_REPOSITORY,,}:${GITHUB_SHA::7}" >> "$GITHUB_ENV"
         - uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
           with:
             registry: ghcr.io
             username: ${{ github.actor }}
             password: ${{ secrets.GITHUB_TOKEN }}
         - uses: docker/setup-buildx-action@f87e5991a6d7451dcb8d9637bfbc97413f497069 # v4.4.1
         - uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc # v7.4.0
           with:
             context: .
             platforms: linux/amd64
             push: true
             tags: ${{ env.IMAGEN }}
             cache-from: type=gha
             cache-to: type=gha,mode=max
   EOF
   git add . && git commit -m "imagen en GHCR" && git push

   Qué deberías ver: En Actions, el run imagen en verde. En la página del repo, Packages muestra lab-actions con un tag de 7 caracteres: el commit corto.

2. Paso 2Copiar

   docker buildx imagetools inspect ghcr.io/TU_USUARIO/lab-actions:SHA_CORTO

   Qué deberías ver: Platform: linux/amd64, más una entrada unknown/unknown (la attestation). Usa tu usuario en minúsculas. Funciona sin login porque un paquete publicado desde un workflow hereda la visibilidad del repo, y el tuyo es público. Si igual te lo niega, hazlo público en Packages → lab-actions → Package settings → Change visibility.

3. Paso 3Copiar

   docker run --rm --platform linux/amd64 ghcr.io/TU_USUARIO/lab-actions:SHA_CORTO

   Qué deberías ver: hola desde CI: corre emulada, porque tu Mac es linux/arm64 y pediste amd64. Sin --platform, docker busca en el índice una variante para tu Mac, no la encuentra y puede fallar con no matching manifest for linux/arm64/v8 in the manifest list entries.

4. Paso 4Copiar

   git commit --allow-empty -m "otro commit" && git push

   Qué deberías ver: Un tag nuevo (otro commit corto) en Packages; en el log del build, los pasos que no cambiaron salen como CACHED.

5. Paso 5Copiar

   docker rmi ghcr.io/TU_USUARIO/lab-actions:SHA_CORTO
   # en github.com: Packages → lab-actions → Package settings → Delete this package

   Qué deberías ver: Untagged y Deleted en tu Mac; en GitHub, el paquete desaparece. Si terminaste los labs, borra también el repo lab-actions.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Simular GitOps en tu máquina (un repo bare hace de repo de manifests y main es lo que Argo CD aplicaría): desplegar con un merge, volver con un revert (de un merge commit y de un squash) y, si quieres, ver en GitHub un environment con aprobación y concurrency.

Necesitas: Una terminal de macOS (sed -i '' es la forma de macOS) y git con user.name y user.email configurados. Para los pasos opcionales: tu cuenta de GitHub, un repo nuevo, vacío y público (en Free, los required reviewers solo existen en repos públicos) con un environment produccion que te tenga como required reviewer (Settings → Environments → New environment → Required reviewers → Save protection rules), push con tu autenticación de siempre y gh con sesión iniciada (o la web).

1. Paso 1Copiar

   git init --bare -b main ~/lab-git-remote.git && mkdir ~/lab-git && cd ~/lab-git && git init -b main && git remote add origin ~/lab-git-remote.git && mkdir k8s && echo "image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/classifier-gateway:3f9c2ab" > k8s/gateway.yaml && git add k8s && git commit -m "gateway 3f9c2ab" && git push -u origin main

   Qué deberías ver: Initialized empty Git repository dos veces, [main (root-commit) …] gateway 3f9c2ab, * [new branch] main -> main y branch 'main' set up to track 'origin/main'. Un manifest mínimo: solo la línea que cambia en cada deploy.

2. Paso 2Copiar

   git switch -c deploy/gateway && sed -i '' 's/:3f9c2ab/:9d41e7c/' k8s/gateway.yaml && git commit -am "deploy: gateway 9d41e7c" && git push -u origin deploy/gateway

   Qué deberías ver: Switched to a new branch 'deploy/gateway', el commit deploy: gateway 9d41e7c y * [new branch] deploy/gateway -> deploy/gateway. Es lo que hace el job de CI: cambia el tag y empuja una rama para el PR.

3. Paso 3Copiar

   git switch main && git merge --no-ff -m "Merge pull request #7 from acme/deploy/gateway" deploy/gateway && git push && git show origin/main:k8s/gateway.yaml

   Qué deberías ver: Merge made by the 'ort' strategy., el push de main y image: …/classifier-gateway:9d41e7c. Así queda un PR mergeado con Create a merge commit; esa línea es la que Argo CD aplicaría.

4. Paso 4Copiar

   git revert HEAD

   Qué deberías ver: error: commit … is a merge but no -m option was given. y fatal: revert failed. Un merge tiene dos padres: hay que decir contra cuál deshacer.

5. Paso 5Copiar

   git revert -m 1 --no-edit HEAD && git push && git show origin/main:k8s/gateway.yaml && git log --oneline --graph -4

   Qué deberías ver: [main …] Revert "Merge pull request #7 from acme/deploy/gateway", el push y otra vez …:3f9c2ab. El grafo muestra el commit inicial, el merge del deploy y el revert arriba: la historia guarda qué se desplegó y cómo se volvió. En un repo real, el revert entra con un PR.

6. Paso 6Copiar

   git switch -c deploy/gateway-2 && sed -i '' 's/:3f9c2ab/:5b2e8aa/' k8s/gateway.yaml && git commit -qam "deploy: gateway 5b2e8aa" && git switch main && git merge --squash deploy/gateway-2 && git commit -m "deploy: gateway 5b2e8aa (#8)" && git revert --no-edit HEAD && cat k8s/gateway.yaml

   Qué deberías ver: Squash commit -- not updating HEAD, el commit deploy: gateway 5b2e8aa (#8), Revert "deploy: gateway 5b2e8aa (#8)" sin pedir -m y otra vez …:3f9c2ab. Con Squash and merge, el PR es un commit normal.

7. Paso 7Copiar

   mkdir -p .github/workflows && printf '%s\n' 'name: deploy-lab' 'on: workflow_dispatch' 'permissions:' '  contents: read' 'concurrency:' '  group: deploy-produccion' '  cancel-in-progress: false' 'jobs:' '  deploy:' '    runs-on: ubuntu-24.04' '    timeout-minutes: 5' '    environment: produccion' '    steps:' '      - run: echo "desplegando ${GITHUB_SHA::7} (run $GITHUB_RUN_NUMBER)" && sleep 60' > .github/workflows/deploy-lab.yml && git add .github && git commit -m "workflow de deploy de prueba" && git remote add github https://github.com/TU_CUENTA/lab-cd.git && git push github main

   Qué deberías ver: Opcional, en GitHub (cambia TU_CUENTA). El push crea main en tu repo de prueba con el workflow deploy-lab. El environment produccion ya tiene que existir con tus reglas: si no existe, GitHub lo crea solo al correr el job, sin aprobación.

8. Paso 8Copiar

   for i in 1 2 3; do gh workflow run deploy-lab.yml --repo TU_CUENTA/lab-cd; sleep 5; done

   Qué deberías ver: En la pestaña Actions: el 1.er run queda Waiting, con Review deployments; el 2.º, pending, porque el 1.º tiene el grupo deploy-produccion; al llegar el 3.º, el 2.º se cancela con Canceling since a higher priority waiting request for 'deploy-produccion' exists. Sin gh: Run workflow tres veces en la web.

9. Paso 9Copiar

   gh run list --workflow deploy-lab.yml --repo TU_CUENTA/lab-cd --limit 3

   Qué deberías ver: Antes, en la web: en el 1.er run, Review deployments → produccion → Approve and deploy (corre ≈ 1 min); cuando el 3.º quede Waiting, Reject. La lista muestra uno completado, uno cancelado (el 2.º) y uno fallido (el rechazado).

10. Paso 10Copiar

    cd ~ && rm -rf ~/lab-git ~/lab-git-remote.git

    Qué deberías ver: Sin salida. Si hiciste los pasos de GitHub, borra el repo de prueba en Settings → General → Delete this repository.

Verificado contra la documentación. Los pasos 1–6 y 10 (git) se corrieron con git 2.50.1 en macOS y zsh, con un repo bare local como remoto. Los pasos 7–9 usan GitHub y se verificaron contra docs.github.com (environments, concurrency, gh workflow run), sin correrlos aquí.