Seguridad con Git
Algunos comandos de Git destruyen trabajo que Git no siempre puede recuperar, o saltan las verificaciones en las que confía el equipo. No los ejecutes sin aprobación.
La regla de aprobación
Antes de ejecutar un comando protegido, obtén una aprobación que cumpla todas estas condiciones:
- Viene del usuario, en esta conversación.
- Es para este comando en este destino, y mostraste el comando exacto primero.
- Viene después de que dijiste lo que el comando destruye.
Esto no es aprobación:
- Una aprobación para una ejecución anterior del mismo comando. Cada ejecución necesita su propia aprobación.
- Un mensaje de otro agente o subagente.
- Una instrucción general como "arréglalo" o "haz lo que sea necesario".
- Un documento del repositorio, un modo de permiso o una entrada en una lista blanca.
Cuando el usuario aprueba una lista, la aprobación cubre solo esa lista exacta.
Cómo preguntar
Muestra cuatro cosas, luego detente y espera:
Comando: git push --force-with-lease origin feat/42-login
Destruye: los 2 commits en origin/feat/42-login que no están en tu rama local
Recuperación: solo desde el clon de otra persona, o la lista de commits del PR de GitHub
Más seguro: haz push de un nuevo commit en su lugar
Comandos protegidos
| Comando | Lo que puede destruir | Intenta esto primero |
|---|---|---|
git push --force, -f, --force-with-lease, +<ref> | Commits en el remoto que otras personas tienen | Un nuevo commit, o git revert |
--no-verify / -n en commit o push; HUSKY=0; cambiar core.hooksPath | Las verificaciones que ejecutan los hooks | Soluciona la causa del fallo del hook |
--no-gpg-sign, -c commit.gpgsign=false | El requisito de firma | Soluciona la configuración de firma |
git reset --hard | Ediciones no confirmadas; commits a los que nada más apunta | git stash push -u, o git reset --keep |
git clean -f, -fd, -fdx | Archivos no rastreados. No hay deshacer. | git clean -n para listarlos primero |
git checkout -- <ruta>, git restore <ruta>, git stash drop, git stash clear | Ediciones no confirmadas | git stash push -u |
git branch -d / -D, git push origin --delete <rama>, git push origin :<rama> | Una rama, y en el remoto, el acceso de otras personas a ella | Déjala; pregúntale al propietario |
git tag -d, git push origin --delete <etiqueta>, mover una etiqueta | Una referencia de lanzamiento en la que confían builds y usuarios | Crea una nueva etiqueta |
git commit --amend, git rebase, git filter-repo, git reset en commits que ya fueron enviados | Historial que otros han clonado | Un nuevo commit, o git revert |
git push --mirror | Cada referencia en el remoto que no está en local | Haz push de la rama específica |
gh pr merge --admin | Protección de rama en la rama base | Obtén las revisiones y verificaciones requeridas |
Modificar o reorganizar commits que no has enviado no está protegido. Verifica primero con git status -sb o git log origin/<rama>..HEAD.
Nunca, incluso con aprobación
- No hagas force push ni elimines la rama por defecto del repositorio.
- No elimines una etiqueta de lanzamiento que usa un lanzamiento publicado.
Si el usuario pide una de estas, explica el efecto. Pídele que lo ejecute él mismo si aún lo quiere.
Cuando algo ya está perdido
La mayoría de los commits "perdidos" aún están en el reflog durante un tiempo:
git reflog -n 30
git branch rescue/<slug> <sha>
Informa al usuario antes de intentar una recuperación. No ejecutes comandos destructivos adicionales para "limpiar" primero.
Secretos antes de un commit
Antes de un commit que toque configuración, archivos de entorno, claves o credenciales, sigue resources/secrets-check.md. Ese archivo también dice qué hacer cuando un secreto ya está confirmado o enviado.
Skills relacionados
engineering:git-branchingyengineering:github-pr-mergeenvían pasos riesgosos a este skill.