Tutorial de Git

En este primer episodio del Tutorial de Git discuto qué es Git, por qué se ha vuelto tan popular en la industria del software y qué ventajas nos aporta frente a otros sistemas de control de versiones ya existentes.

En este episodio me centro en la instalación de Git en Windows, Linux y MacOS X. Instalar Git en sistemas UNIX es particularmente sencillo. En Windows también hay alternativas fáciles de instalar.

Una vez que Git se encuentra instalado en el ordenador podemos crear un repositorio y hacer el primer commit. Hoy veremos cómo usar git init, git add, git commit y git status.

Hoy me centro en detalle en lo que comencé a explicar en el episodio anterior. En qué estados se pueden encontrar los archivos en nuestro repositorio de Git.

Cuando hacemos la modificación que no debimos nunca hacer, ¿cómo damos marcha atrás? En este vídeo os muestro cómo deshacer cambios locales y cómo sacar cambios del stage.

Si lo que queremos deshacer es algo que ya hemos confirmado, podemos deshacer el commit de varias formas. Hoy nos centramos en el comando git reset.

Cómo revertir cambios de una forma no destructiva por medio del comando revert. Si has hecho un commit que has visto daba problemas, hoy te enseño cómo deshacer sus modificaciones.

Las ramas es un mecanismo que tienen los sistemas de control de versiones mediante el cual podemos mantener varias versiones del código de forma paralela sin interferencia.

Continuando con las explicaciones sobre ramas, hoy veremos cómo crear una rama con Git, y cómo modificar y eliminar ramas. Además, cómo usar checkout para cambiar de rama.

Cuando trabajamos bajo el workflow Feature Branch, implementamos las características en ramas separadas de la principal. En este vídeo veremos cómo se pueden hacer commits en otras ramas.

Una vez que hemos desarrollado la característica de un commit, tenemos que fusionarlo (merge) para que vuelva a la rama inicial. Vemos cómo hacer esto, esta vez mediante fast-forward y recursive.

Cuando hacemos fusiones más avanzadas en Git corremos el riesgo de que se desate un conflicto. Hoy estudiamos qué ocurre si hacemos modificaciones al mismo archivo en varias ramas.

Hagamos un interludio en el tutorial para explicar cómo usar alias, de modo que podamos escribir menos letras para ejecutar nuestros comandos con Git.

Todo un vídeo dedicado a conflictos. Os vuelvo a explicar cómo ocurren y cómo resolverlos. Como abortar un conflicto. Y mi experiencia personal en dónde suelen ocurrir conflictos en Git.

Los sistemas de control de versiones ofrecen etiquetas para marcar commits significativos a los que podamos referirnos más tarde. En este vídeo te cuento cómo crear etiquetas en Git.

Los tags anotados son tags que se comportan como objetos. Pueden tener descripción, datos de autor, de fecha y hora, firma... en este vídeo te explico sus diferencias y cómo crearlos.

El stash es una potente herramienta que trae Git para apartar temporalmente modificaciones hechas al directorio de trabajo.

Alerta por videomonólogo. En este episodio os introduzco al concepto de remotos explicando cómo se comportan en Git y en qué se diferencian de los de un SCV centralizado.

Crearemos un repositorio en GitLab y lo asociaremos a nuestro repositorio local con `git remote`. Luego enviaremos nuestro código a la nube usando `git push`.

Ahora que tenemos el código en un remoto vamos a ver cómo podemos acceder a él de cero usando clone y cómo podemos recibir commits de un remoto usando pull.

Cómo obtener información sobre un remoto con fetch, y cómo los remotos no son más que ramas que se pueden fusionar. Además, qué ventajas aporta un pull-rebase frente a un pull-merge normal.

El rebase es un comando que deja tocar el historial de commits de Git con distintos usos. Hoy os enseño cómo hacer un rebase en vez de un merge a la hora de integrar cambios.

Para cerrar esta temporada, os hablo acerca del rebase interactivo, un comando útil para reescribir del todo el historial de Git: aplastar commits, cambiarlos de orden, modificar mensajes... ¡todo!

Arrancamos con un tema fresco. Hace ya un tiempo que se empezó a recomendar no usar "master" como nombre de la rama principal, por lo que hoy día Git tiene ajustes para cambiar el nombre de la rama, y también hay que estar pendiente de lo que se clona.

Con git switch podemos cambiar de rama. Un poco como con git checkout, pero sin usar git checkout.

Con el comando git-restore se pueden deshacer modificaciones hechas a archivos. Como ya se podía hacer con git-checkout, pero sin utilizar un comando que vale para ocho cosas diferentes. Otros flags de restore que cuento hoy: --staged, --workdir, --source.

git-grep es un comando que toda la vida ha estado ahí, pero que hace unas versiones fue mejorado para dotarle de más rendimiento, y ahora es un comando ideal para buscar código en un repositorio porque los resultados son rápidos.

El gitignore es un archivo en el que se declaran rutas a ignorar para que nunca se metan cuando se hace un git add, entre otras cosas. Tienes una lista de ejemplos de gitignore en https://github.com/github/gitignore.

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.

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.

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.

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.

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?

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.

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.

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).

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.

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.

En esta primera parte (lógicamente, como no tengo máquina del tiempo, la segunda parte la tengo que grabar otro día), vamos a ver qué es un submódulo, cómo acoplar un submódulo a un repositorio, y cómo clonar un repo con submódulos.

Ahora que han pasado varios días, podemos continuar grabando la segunda parte de este tutorial presentando los comandos para poner al día un submódulo acoplado a un repositorio, o para poner al día un repositorio con submódulos.

Se cierra aquí la temporada 2 de Git hablando de diferentes plugins que sirven para hacer que se pueda usar Git desde otro programa, o bien programas independientes que han sido creados expresamente para poder trabajar con Git.