Chuleta de Git con buscador que cubre configuracion, el bucle diario de commits, ramas, remotos, historial y recuperacion, con copia en un clic para cada comando.
Cuarenta y nueve comandos de Git que merece la pena recordar. Filtra a la vez por nombre de comando y descripcion, y copia el que necesites. Agrupado por configuracion, flujo diario, ramas, remotos, historial y deshacer errores.
Ningun comando coincide con ese filtro.
Git tiene bastante mas de cien comandos de alto nivel, pero la mayoria de los desarrolladores usa los mismos veinte o treinta cada dia y recurre al resto unas pocas veces al ano. Una chuleta no sustituye a entender el modelo: existe para que los comandos que ya comprendes esten a una pulsacion de distancia, y no a una pestana del navegador y tres respuestas de foro.
La referencia de esta pagina esta agrupada segun ocurre el trabajo real: preparar un repositorio, el bucle de commits que repites decenas de veces al dia, las ramas, la conversacion con el remoto, la lectura del historial y como salir de un apuro. Escribe en el cuadro de filtro y la lista se reduce buscando tanto en el texto del comando como en su descripcion, de modo que buscar "stash", "force" o "deshacer" muestra las filas relevantes al instante. Cada fila tiene un boton de copia, porque volver a teclear a mano un comando que incluye --force-with-lease es justo la forma en que aparecen las erratas.
Casi todos los comandos de Git cobran sentido en cuanto tienes tres lugares en la cabeza. El arbol de trabajo son los archivos en disco tal como los ves en tu editor. El indice, tambien llamado area de preparacion, es la instantanea que estas montando para el proximo commit. El repositorio es la cadena inmutable de commits ya registrados. git add mueve contenido del arbol de trabajo al indice, git commit convierte el indice en un commit nuevo y git restore empuja el contenido en sentido contrario.
Las ramas son la segunda idea y son mas simples de lo que parecen: una rama es solo un puntero movil a un commit, y HEAD es un puntero a la rama en la que estas. Crear una rama no cuesta nada porque escribe un unico archivo con un hash de cuarenta caracteres. Por eso git switch -c resulta lo bastante barato como para usarlo en un experimento de cinco minutos.
Fusionar y rebasar combinan trabajo de dos ramas, pero difieren en lo que registran. Una fusion conserva ambos historiales y anade un commit que los une: es honesto, aunque produce un grafo trenzado. Un rebase reescribe tus commits para que parezcan escritos encima de la otra rama, lo que da una linea recta y limpia pero cambia los hashes, y esa es exactamente la razon por la que nunca se rebasan commits que otras personas ya han descargado.
Lo mas util que se puede saber sobre Git es que rarisima vez pierde trabajo ya confirmado. Mientras un cambio se haya confirmado en algun momento, git reflog te mostrara el hash y git switch -c rescue <hash> lo traera de vuelta. Esa red de seguridad cubre rebases fallidos, un reset --hard accidental despues de confirmar y ramas borradas con demasiada alegria.
Las operaciones peligrosas son las que tocan trabajo sin confirmar: git reset --hard, git checkout -- sobre un archivo modificado y git clean -fd. Ninguno de esos cambios llego a registrarse, asi que no hay nada a lo que el reflog pueda apuntar. El habito que merece la pena construir es confirmar pronto y a menudo en una rama de borrador, o hacer git stash push antes de cualquier experimento. Un commit que luego aplastas no cuesta nada; una tarde de trabajo sin confirmar no vuelve.
En ramas compartidas, prefiere git revert a reescribir el historial: registra un commit nuevo que revierte al antiguo, de modo que el clon de los demas sigue siendo valido. Reserva --force-with-lease para tus propias ramas de funcionalidad y ten presente que es bastante mas seguro que un --force a secas: se niega a ejecutarse si el remoto se movio desde tu ultimo fetch, que es precisamente el caso en el que un push forzado normal destruiria en silencio los commits de un companero.