Photo by Mabel Amber
En la entrada anterior mencionaba cómo usar una plantilla para homogeneizar los commits.
Además de la plantilla, usar Conventional Commits permite dotar de un formato standard a los commits. La buena gente de Charm ofrece como parte del tutorial para aprender a usar Gum un script con el que redactar conventional commits.
En esta entrada, ofrezco una versión ampliada que incluye la descripción para cambios que rompen la retrocompatibilidad.
Git proporciona la opción de establecer un fichero como plantilla para los commits de Git.
Cuando defines una plantilla para los commits, al ejecutar git commit, el editor que tengas configurado para componer el mensaje de commmit carga automáticamente la plantilla que hayas definido.
Ni que decir que usar una plantilla para todos los commits ayuda a homogeneizar los mensajes en el repositorio y es una configuración esencial en equipos de trabajo.
Imagina que te encuentras en el siguiente escenario: creas un rama y haces cambios en un fichero.
¿Cómo puedes ver qué diferencias hay en el fichero en dos ramas distintas?
La solución es mi #TIL (today I learn) de hoy.
El ejemplo habitual para introducir los sparse checkouts es cuando todo el código de un equipo se encuentra en un mono repo, es decir, un repositorio para todo. En el repositorio cada “carpeta” contiene el código de un microservicio, por ejemplo…
En esta situación, un miembro del equipo tiene que clonar el repositorio entero aunque sólo tenga que trabajar en una parte muy pequeña del mismo, generalmente circunscrita a una funcionalidad que se encuentra en una carpeta del repositorio.
Del mismo modo, para compilar el código de uno de los microservicios de este mono repo, es necesario clonarlo completamente…
En este tipo de situaciones es cuando podemos usar git sparse-checkout.
Un grupo de compañeros van a cambiar las tareas que realizan como parte de su trabajo; parte de esa transformación consiste en familiarizarse con el uso de Git.
He decidido darle una vuelta a cómo les introduciría en el uso de Git de manera sencilla y que tenga sentido.
Las buenas prácticas (por ejemplo Version Control Best Practices) relacionadas con el control de versiones usando Git indican que hay que guardar (commit) los cambios de forma frecuente, conteniendo únicamente pequeños cambios.
Sin embargo, el desarrollo no se produce de una forma lineal, de principio a fin; a veces, lo que parece una buena idea que funciona al principio, más adelante es necesario cambiarla o modificarla…
Si guardamos todos los commits, la historia del repositorio quedará llena de estos cambios de dirección durante el desarrollo. Por este motivo, una de las opciones que tenemos es la de reescribir la historia del repositorio antes de, por ejemplo, hacer merge de la rama de feaure sobre la rama principal.
En este artículo vemos cómo conseguirlo usando git rebase.
Revisando los repositorios del diseñador original del tema de este blog, Daisuke Tsuji he encontrado el fichero .git_commit_message que contiene una lista de emojis:
Al clonar un repositorio, Git añade una referencia en la configuración del repositorio clonado para incluir el repositorio “original” como “remote”. Este repositorio se denomina, por defecto, origin. De esta forma, si quieres enviar cambios a este repositorio, ejecutas el comando git push origin ${rama}.
En algunas situaciones te puede interesar trabajar con múltiples repositorios remotos, por lo que en esta entrada explico cómo revisar los repositorios remotos configurados en tu repositorio, cómo añadir y eliminar repositorios “remotos” adicionales, cambiarles el nombre, etc.
He encontrado este artículo Automatically keeping Git identities distinct between accounts hojeando el blog de la empresa SEP después de leer un artículo sobre testing de plantillas de CloudFormation.
La configuración que indica Aaron Alexander en el artículo referenciado permite usar una identidad concreta para cada cuenta de Git.
Esto te permite identificarte con tu cuenta de empresa en los repositorios de la empresa, en los personales con una dirección de correo personal, etc.
Gogs es un servidor web de repositorios Git (a lo GitHub). He hablado otras veces de lo sencillo que es montarlo usando Docker, de manera independiente (usando SQLite como base de datos o con MySQL).
A través de este artículo 6 Github alternatives that are open source and self-hosted descubrí hace unos días Gitea y a continuación te explico porqué creo que es todavía mejor que Gogs.
