Flujo-de-trabajo-con-Git-en-Gitlab-y-GitHub.md

@@ -9,8 +9,10 @@ El objetivo de esta entrada es condensar en un solo documento, el flujo de traba
     * [Nuestra manera](#nosotros-seguimos-estas-etapas-a-nuestra-manera)
   * [¿Y en GitHub?](#y-en-github)
     * [Dos gotas de agua](#dos-gotas-de-agua)
-* [Fuentes y lecturas recomendadas](#fuentes-y-lecturas-recomendadas)
+* [Versionado semántico de los roles](#versionado-sem%C3%A1ntico-de-los-roles)
+* [Algunos trucos y recomendaciones](#Algunos-trucos-y-recomendaciones)
 * [Pasando en limpio](#pasando-en-limpio)
+* [Fuentes y lecturas recomendadas](#fuentes-y-lecturas-recomendadas)
 
 
 ## Git. Ramas y trabajo en equipo
@@ -112,6 +114,13 @@ En GitHub también tenemos a *issues*, *pull requests* (idénticos a los *merge
 
 Así como hay desventajas, también ventajas. En GitHub contamos con características muy útiles al momento de realizar revisiones y fusiones. En las solicitudes de fusión (*pull requests*), es posible asignar a un miembro específicamente para la revisión y otro para la fusión. Aquí las revisiones son un [feature completo](https://github.com/features/code-review/), con una dinámica más rica y guiada al momento de mantener discusiones sobre el código.
 
+## Versionado semántico de los roles
+
+El proyecto config es de administración de sistemas y de integración contínua, por lo cual no tiene mucho sentido gestionar un versionado. La rama master debe ser estable, reflejando lo mejor posible la realidad de nuestra infraestructura. 
+
+Los roles, al contrario, son unidades de código reutilzables y trabajadas en comunidad más allá de nuestro equipo. Por eso, y en en conformidad con los mecanismos y prácticas para los roles de la [Ansible Galaxy](https://galaxy.ansible.com), conviene que [gestionemos un versionamiento](home#protocolos-y-estándares-que-seguimos). 
+
+Semánticamente seguimos, valga la redundancia, las norma de Versionado Semántico o [SemVer](https://semver.org/lang/es/). Instrumentalmente y sintáxicamente seguimos [lo que propone git-scm](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Etiquetado) y que utiliza la Ansible Galaxy. 
 
 # Pasando en limpio
 
@@ -123,8 +132,14 @@ Expuestos ya los fundamentos, lo que importa que te lleves de aquí y mantengas
 * luego de dar por finalizada la implementación de un feature, **asignar la solicitud de fusión a un compañero** y retirar el *WIP* para que proceda a realizar la revisión
 * **ser detallado y cuidadoso al momento de realizar revisiones**. Cualquier aspecto mejorable debe ser registrando como comentario en la solicitud de fusión o en el *commit* correspondiente, solicitando al autor su corrección para poder continuar con la revisión
 
+# Algunos trucos y recomendaciones
 
-
+* Al momento de abrir una incidencia, es importante pensar bien el título, sobretodo en GitLab en el cual éste será retomado en la rama y en la merge request
+* Conviene siempre establecer múltiples enlaces cruzados, entre todas las acciones y referencias que están relacionadas. GitLab y GitHub establecen varios vínculos automáticamente, pero no todo, y en particular conviene entre el proyecto `config` en nuestro Gitlab y sur roles en GitHub (que no se harán automáticamente)
+* existen muchas manera de generar fácilmente dichos enlaces, por ejemplo con *#<num_issue>* para las incidencias y *!<num_MR>* para las solicitudes de fusión en GitLab, o *#<num>* en GitHub, haciendo referencia a la numeración compartida de las *issues y las *Pull Request* en GitHub. La mención de un tag de versión tambipén genera un enlace automático
+* Estos enlaces pueden incluso fácilmente convertirse en comandos implícitos, por ejemplo con *Close #<num_issue>* o *Fix #<num_issue>* para provocar el cierre de la incidencia, MR o PR
+* Dichos atajos funcionan incluso en los mensajes de commit, vinculando así commits con issues/PR/MR y versiones, y disparando eventuales modificaciones de estado
+* Cuando realizamos un merge de una rama con otra, git abre un editor con una línea que explicita qué rama se fusiona en cual. Es importante *agregar* ahí una descripción de la operación de fusión que estamos realizando, porque sólo en el historial del grapho del repo git puede no quedar claro. Tomamos la convención de dejar tal cual la línea porpuesta por git, agregando abajo, en lista eventualmente, toda la información pertinente
 
 > #### Fuentes: (y lecturas recomendadas)
 >* [Feature Branch Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)