Un pequeño vídeo de regalo para quienes quieran configurar su prompt de Bash con los scripts de Git que permiten mostrar el nombre de la rama en Bash. La función __git_ps1 te permite mostrar la rama en la que estás, y es fácil de insertar en el PS1. Además, git-completion.
El reflog es un log especial donde se incorporan commits cada vez que se hace un cambio de rama o un reset, lo que puede ser usado en caso de emergencia para recuperar un estado anterior de la rama si la liamos con el rebase, reset o checkout.
git-blame es un comando de diagnóstico que analiza un archivo y te dice en qué commit, cuándo y quien, se modificó cada línea de un archivo, para poder identificar el commit concreto en el que se tomó ese cambio. Podemos usar el comando git-show para ver ese commit concreto y así entender el razonamiento detrás de ese cambio (si la descripción del commit está bien hecha, claro).
git-bisect es un comando de diagnóstico muy potente que permite identificar en un log de Git el momento exacto en el que se introduce un bug (o ya puestos, lo que sea que estemos buscando). Podemos iniciar un bisect con `git bisect start`, y luego ir etiquetando commits con el sub-sub-comando "good" como "buenos", o con el sub-sub-comando "bad" como malos.
El botón squash de las interfaces web está bien, pero ¿cómo haríamos un squash desde la línea de comandos usando nuestro propio cliente de Git? El squash es un flag del comando git-merge, por lo que para hacer un squash tenemos que solicitar esta estrategia al realizar un merge.
Merge and squash (GitLab / GitHub...)
Es común hoy en día que en proyectos con una organización detrás, el trabajo se delegue a interfaces web como GitHub o GitLab, donde se puede hacer la integración desde una interfaz gráfica que permite visualizar diffs o poner comentarios. Conocemos el botón Merge commit, el botón Rebase and merge, pero... ¿qué es un squash y qué consecuencias tiene pulsar ese botón?
Conventional Commits, o Commits Convencionales, es un patrón de uso de repositorios Git en el que ponemos siempre un prefijo a todos los commits para indicar de qué tipo son, por ejemplo feat para las funciones nuevas, fix para los arreglos, o chore para indicar mejoras higiénicas en el repositorio. La spec completa está en https://www.conventionalcommits.org.
Merge octopus es un tipo de merge (el del pulpo) que se hace cuando se intenta hacer un merge de más de dos ramas a la vez. Es un tipo de merge que puede ser útil en casos en los cuales haya varias ramas a integrar, para hacerlo de un único esfuerzo, pero es un tipo de merge blando que no se lleva bien con los conflictos y que por lo tanto no siempre se puede usar.
git-apply y parches en bruto (advanced)
Cómo exportar un diff para crear un archivo de parche, que podemos compartir y volver a aplicar más adelante usando el comando git-apply. Muchos proyectos de software libre siguen trabajando con parches como forma de compartir sus avances, porque no quieren dar el salto a GitLab y GitHub.
Con la opción --patch es posible que ciertos comandos como git-add, git-checkout o git-restore hagan sus cambios sobre trozos concretos de archivos en vez de sobre un archivo completo. Lo podemos usar para meter hunks concretos en un commit o para deshacer parcialmente el contenido de un archivo.