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

@@ -135,11 +135,11 @@ Expuestos ya los fundamentos, lo que importa que te lleves de aquí y mantengas
 # 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
+* 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 enriquecer los vínculos 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 tambié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
+* 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 esa línea en el historial del grafo 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)