Generador de comandos Git — Deja de buscar en Google los mismos comandos cada día

Solía tener una pestaña del navegador abierta permanentemente en la documentación de git. No porque no supiera git, lo había estado usando durante años, sino porque seguía olvidando la sintaxis exacta de cosas que solo hacía ocasionalmente. Era git reset --soft o git reset --cached cuando quería desindexar sin perder cambios? git stash apply eliminaba el stash o lo dejaba? Era el flag para establecer upstream -u o --set-upstream?

Cada desarrollador que conozco tiene una versión de esta experiencia. Git es una de esas herramientas donde los comandos diarios se convierten en reflejos dentro de tus primeras semanas, pero los comandos de frecuencia media, los que usas cada pocos días o una vez a la semana, nunca se quedan del todo. Los aprendes, los olvidas, los vuelves a aprender, los olvidas de nuevo.

El Generador de comandos Git en ToolBox Hub existe exactamente para esos momentos. En lugar de cambiar a la documentación, puedes filtrar por categoría, buscar por lo que estás tratando de hacer, llenar un nombre de rama o hash de commit, y copiar el comando completo. Sin búsquedas, sin depurar flags incorrectos.

Cómo funciona la herramienta

Cuando abres el Generador de comandos Git, ves una barra de búsqueda y una fila de botones de categoría: Basic, Branching, Remote, Undo, Stash y Advanced.

Las tarjetas de comandos muestran cada una el comando en un bloque de código de fuente fija, una descripción en lenguaje claro de lo que hace, y un botón de copiar. Para los comandos que necesitan un parámetro, un nombre de rama, una ruta de archivo, un hash de commit, hay una entrada de texto debajo de la tarjeta. Lo que escribas se sustituye en la plantilla del comando en tiempo real, por lo que el botón de copiar siempre copia la versión lista para ejecutar.

Por ejemplo, si haces clic en la tarjeta "Crear y cambiar a nueva rama" y escribes feature/payments en el campo de nombre de rama, el bloque de comandos se actualiza instantáneamente a git checkout -b feature/payments y eso es lo que se copia en tu portapapeles.

La barra de búsqueda filtra tanto los nombres de comandos como las descripciones, por lo que puedes escribir "undo" y ver todos los comandos relevantes, o escribir "stash" y ver el flujo de trabajo completo de stash junto.

Los comandos que realmente usarás

En lugar de repasar todos los 40+ comandos alfabéticamente, voy a recorrer las categorías de la manera en que aparecen en un día de trabajo real.

Configuración y conceptos básicos diarios

Los comandos en la categoría Basic son los que la memoria muscular toma durante tu primer mes. git status es probablemente el comando git más ejecutado, te dice qué está indexado, qué no lo está, y qué no está rastreado. git add . indexa todo en el directorio actual. git commit -m "mensaje" crea un commit.

Los dos que veo que los desarrolladores subutilizan en esta categoría son git diff y git diff --staged. Ejecutar git diff antes de agregar cualquier cosa te muestra precisamente qué cambió en tu árbol de trabajo desde el último commit. Ejecutar git diff --staged después de agregar muestra qué entra realmente en tu próximo commit. Desarrollar el hábito de revisar estos antes de cada commit captura una cantidad sorprendente de logs de depuración, bloques de código comentados e inclusiones accidentales de archivos.

git log --oneline es otra herramienta diaria subestimada. La salida predeterminada de git log es verbose hasta el punto de ser difícil de hojear. La versión --oneline comprime cada commit en una sola línea: los primeros 7 caracteres del hash y el asunto del mensaje de commit. Mucho más rápido para encontrar el commit que buscas.

Estrategia de ramas

La categoría Branching cubre todo, desde crear ramas hasta fusionar y etiquetar.

git checkout -b <rama> (o el más nuevo git switch -c <rama>) es cómo comienza la mayoría del trabajo de funcionalidades. La nombras, te cambias a ella, construyes. Cuando el trabajo está hecho, abres una pull request o la fusionas de vuelta. Flujo estándar.

Los comandos con los que la gente se confunde son git merge versus git rebase. Ambos integran cambios de una rama en otra, pero de maneras diferentes.

git merge crea un commit de fusión. El historial de tu rama y el historial de la rama objetivo se conservan ambos, y el commit de fusión muestra dónde se unieron. Si miras un gráfico de git, los commits de fusión crean una forma de diamante. Esto es fiel a lo que realmente sucedió, dos flujos de trabajo paralelos convergieron, y es el valor predeterminado seguro para flujos de trabajo en equipo.

git rebase toma tus commits, rebobina el puntero de rama a la punta de la rama objetivo, y reproduce tus commits encima. El resultado es una línea recta de commits sin diamantes de fusión. La ventaja es la legibilidad, git log es más fácil de seguir. La desventaja es que rebase reescribe los hashes de commits, lo que crea problemas si alguien más ya jaló esos commits. La regla: rebase en ramas personales o locales, merge en ramas compartidas.

git branch -d <rama> elimina una rama local después de fusionar. Git es conservador aquí y se negará a eliminar si la rama tiene commits no fusionados. Si genuinamente quieres descartar una rama no fusionada, usa -D (mayúscula). El generador incluye -d específicamente porque es la versión segura.

Trabajar con remotos

La categoría Remote cubre los comandos que tocan el servidor.

git fetch origin es sutilmente diferente de git pull. Fetch solo descarga nuevos commits y ramas del remoto, no toca tus ramas locales en absoluto. Pull es un fetch seguido de un merge. Prefiero hacer fetch primero y ver qué cambió antes de fusionar, especialmente en ramas compartidas activas. Es un pequeño hábito que me ha salvado de conflictos inesperados más de una vez.

git push -u origin <rama> es el primer push para una nueva rama. El flag -u establece la relación de seguimiento upstream, por lo que después de esto, git push y git pull sin argumentos funcionan automáticamente en esa rama. Si omites -u en el primer push, las llamadas posteriores a git push se quejarán de que no hay upstream configurado.

git remote -v es el comando "cuál es mi configuración." En cualquier repositorio desconocido, ejecutarlo inmediatamente te dice a dónde van los fetches y pushes. Te sorprendería cuántas veces esto revela un remoto apuntando a algún lugar inesperado.

git cherry-pick <hash> merece una mención. Copia un único commit de cualquier lugar del historial en tu rama actual. El caso de uso clásico: un hotfix fue fusionado en main, pero estás trabajando en una rama de funcionalidad de larga duración que también necesita ese arreglo. Cherry-pick el hash del commit y aterriza en tu rama sin el resto de los cambios de main.

Deshacer errores

Esta es la categoría que la gente busca más urgentemente. Algo salió mal y necesitas revertirlo sin empeorar las cosas.

git reset --soft HEAD~1 es el deshacimiento más suave. Mueve el puntero de rama de vuelta un commit pero deja todos los cambios indexados y listos para re-commitear. Úsalo cuando hayas hecho commit demasiado pronto y quieras agregar más cambios o reescribir el mensaje.

git reset HEAD~1 (modo "mixed" predeterminado) mueve el puntero de vuelta y desindexar los cambios, pero los deja en tu árbol de trabajo. Úsalo cuando quieras volver a examinar qué cambiaste antes de volver a indexar.

git reset --hard HEAD~1 es la opción nuclear. Mueve el puntero de vuelta y descarta los cambios por completo. No hay deshacimiento incorporado para esto, los cambios desaparecen del árbol de trabajo. Úsalo solo cuando estés seguro de que no quieres esos cambios.

git revert <hash> es la herramienta correcta cuando el commit que quieres deshacer ya fue empujado. Revert crea un nuevo commit que aplica el inverso de los cambios originales. El historial se conserva. Tus compañeros de equipo que jalaron no serán perturbados.

git restore <archivo> descarta los cambios del árbol de trabajo en un archivo específico. git restore --staged <archivo> desindexar un archivo sin tocar el árbol de trabajo. Estos comandos fueron agregados en Git 2.23 como alternativas más limpias al git checkout y git reset sobrecargados.

Guardando trabajo en progreso

Stash es la escotilla de escape para "necesito cambiar de contexto ahora mismo pero no estoy listo para hacer commit."

git stash guarda tus cambios no comprometidos (tanto indexados como no indexados) en una pila y revierte tu árbol de trabajo al último commit. Ahora puedes cambiar de ramas, jalar cambios, arreglar un bug, lo que necesites. Cuando vuelves, git stash pop restaura tus cambios.

git stash push -m "mensaje descriptivo" vale la pena usarlo sobre el simple git stash en el momento en que tienes más de una entrada de stash. El mensaje hace mucho más fácil identificar entradas cuando luego ejecutas git stash list. Una entrada de stash llamada WIP: refactorizando middleware de autenticación es mucho más útil que stash@{2}.

git stash apply stash@{1} aplica una entrada específica sin eliminarla de la lista. Útil cuando quieres aplicar el mismo stash a varias ramas.

Comandos avanzados y menos comunes

La categoría Advanced cubre los comandos que aparecen ocasionalmente pero son difíciles de recordar.

git log --oneline --graph --all es un favorito que recomiendo que todos ejecuten periódicamente en sus repositorios. El gráfico de ramas ASCII te da una imagen visual de cómo se relacionan tus ramas, cuáles han divergido, dónde ocurrieron las fusiones, dónde están las etiquetas.

git bisect start inicia una búsqueda binaria para encontrar qué commit introdujo un bug. Marcas un commit de buen estado conocido con git bisect good <hash> y un commit de estado malo conocido con git bisect bad <hash>, y git extrae el commit del punto medio para que lo pruebes. Continúas marcando bueno o malo hasta que git identifica el commit exacto que rompió las cosas. Para bugs que son difíciles de reproducir sin ejecutar el código, bisect es invaluable.

git blame <archivo> te muestra quién modificó por última vez cada línea de un archivo y en qué commit. El nombre suena acusatorio, en la práctica generalmente se usa para entender por qué una línea de código es como es mirando el commit y leyendo su mensaje y diff.

git reflog es el comando de rescate. Incluso después de un reset duro, git mantiene un registro interno de todos los lugares donde ha estado HEAD. Si accidentalmente destruiste commits que necesitabas, git reflog te mostrará el hash que necesitas para recuperarlos con git reset --hard <hash-recuperado>. He visto esto salvar horas de trabajo.

Consejos profesionales para un flujo de trabajo Git más fluido

Algunos hábitos que hacen una diferencia significativa:

Escribe mensajes de commit en modo imperativo. "Agregar middleware de autenticación" en lugar de "Middleware de autenticación agregado." La convención existe porque los mensajes generados por git (commits de fusión, reverts) usan el modo imperativo, por lo que tus mensajes se integran naturalmente.

Haz commits pequeños y frecuentes. Los commits atómicos, un cambio lógico por commit, hacen que git log sea legible, hacen que la revisión de código sea más fácil, y hacen que git bisect sea efectivo. Hacer commit una vez al día con un mensaje gigante de "progreso" anula la mayor parte del valor de git.

Usa .gitignore agresivamente. Artefactos de compilación, metadatos del IDE, archivos de entorno, estos nunca deben aparecer en tu repositorio. Si git status está repleto de archivos que nunca vas a commitear, arregla tu .gitignore.

Aprende el flag --patch. git add --patch (o git add -p) te permite seleccionar interactivamente qué trozos de un archivo indexar. Cuando un archivo tiene cambios para dos propósitos diferentes, puedes dividirlos en commits separados.

Herramientas que vale la pena combinar con esta

Parser Cron — Las pipelines de CI/CD a menudo tienen trabajos programados junto con trabajos activados por eventos. Si tu pipeline de despliegue incluye un horario cron y necesitas decodificar o construir una expresión cron, esta herramienta lo maneja al instante.

Codificador de URL — Las URLs remotas de Git a veces incluyen caracteres que necesitan codificación, especialmente cuando las credenciales de autenticación o tokens están integrados en la URL.

FAQ

¿Cuál es la diferencia entre git fetch y git pull? git fetch descarga nuevos commits y ramas del remoto pero no toca tus ramas locales. git pull hace un fetch seguido de un merge. Fetch cuando quieras inspeccionar primero, pull cuando estés listo para integrar.

¿Cómo deshago un commit que ya empujé? Usa git revert <hash-del-commit> para crear un nuevo commit que deshaga los cambios sin reescribir el historial. git reset solo es seguro para commits que aún no han sido empujados.

¿Para qué sirve git stash? Stash guarda temporalmente los cambios no comprometidos para que puedas cambiar de contexto, cambiar de ramas, jalar cambios, aplicar un hotfix, sin commitear trabajo a medias. git stash pop restaura los cambios cuando vuelves.

¿Cuándo debería usar rebase en lugar de merge? En ramas personales donde quieres un historial lineal limpio antes de fusionar en main. Nunca hagas rebase de commits que otros ya han jalado, reescribe los hashes y causa conflictos.

¿Cómo recupero commits después de git reset --hard? Ejecuta git reflog para ver el historial de posiciones de HEAD. Encuentra el hash del commit que necesitas y ejecuta git reset --hard <ese-hash> para restaurarlo.

En conclusión

Git es una de esas herramientas que recompensa la inversión de tiempo más que casi cualquier otra cosa en el kit de herramientas de un desarrollador. Los comandos que parecen arcanos se vuelven automáticos, los flujos de trabajo que antes requerían una pestaña de documentación se convierten en segunda naturaleza.

El Generador de comandos Git está ahí para la fase intermedia, cuando sabes lo que necesitas hacer pero no puedes recordar del todo la sintaxis exacta. Márcalo como favorito, úsalo, y para cuando lo hayas usado suficientes veces probablemente hayas memorizado los comandos de todas formas.