Buenas prácticas

Adoptar buenas prácticas en Git no solo mejora la organización y claridad de tu repositorio, sino que también facilita la colaboración con otros desarrolladores, minimiza errores y asegura que el historial del proyecto sea fácil de rastrear. A continuación, se detallan algunas de las mejores prácticas que puedes seguir para optimizar el uso de Git en proyectos colaborativos.

1. Convenciones de mensajes de commit #

Los mensajes de commit son una parte crucial del trabajo en Git, ya que documentan cada cambio en el historial del proyecto. Mensajes claros y consistentes permiten que cualquier persona en el equipo (incluyendo tu "yo" del futuro) entienda fácilmente qué cambios se hicieron y por qué.

Buenas prácticas para escribir mensajes de commit #

1. Usar el estándar Conventional Commits: Es la convención más extendida en la industria para estructurar mensajes con prefijos semánticos:

   • feat: nueva funcionalidad para el usuario.

   • fix: corrección de un error (bug).

   • docs: cambios en documentación.

   • refactor: refactorización de código sin alterar comportamiento.

   • test: adición o corrección de pruebas.

   • chore: tareas de mantenimiento, dependencias o configuración.

   • Ejemplos:

     1feat(auth): agrega validación al formulario de registro
     2fix(billing): corrige error en el cálculo de impuestos
     3chore(deps): actualiza dependencias a la versión más reciente

2. Mantener mensajes cortos y descriptivos: El título debe ser claro y conciso (máximo 50-72 caracteres), describiendo qué se cambió y por qué.

3. Agregar un cuerpo cuando sea necesario: Si el cambio requiere contexto adicional, añade un cuerpo explicativo dejando una línea en blanco tras el título.

   • Ejemplo:

     1feat(auth): agrega validación al formulario de registro
     2
     3Se añade comprobación de formato de correo y longitud mínima
     4de contraseña para evitar registros erróneos.
     5Ref: Issue #23.

4. Referenciar issues o pull requests: Incluir referencias (Ref #45 o Closes #12) para vincular automáticamente el commit con la tarea en GitHub/GitLab.

2. Mantener un historial limpio: squash, rebase y cherry-pick #

Un historial claro y organizado es más fácil de leer y mantener. Git ofrece varias herramientas como squash, rebase y cherry-pick para mantener el historial de commits limpio y comprensible.

Squash: combinar commits #

El squash te permite combinar varios commits en uno solo. Esto es útil para limpiar el historial antes de fusionar cambios en la rama principal, especialmente si una rama contiene muchos commits pequeños e intermedios.

• Uso (durante un rebase interactivo):

  1git rebase -i HEAD~n

  Cambia pick por squash en los commits que deseas combinar. Luego puedes editar el mensaje final del commit.

Rebase: reescribir el historial #

El comando git rebase te permite "mover" los commits de una rama para aplicarlos sobre otra. Esto es útil cuando deseas mantener un historial más lineal y limpio.

• Rebase interactivo para reescribir los últimos 3 commits:

  1git rebase -i HEAD~3

Durante el rebase interactivo, puedes cambiar el orden de los commits, combinarlos (squash) o eliminar algunos de ellos. El rebase es preferible a merge cuando quieres mantener un historial sin "ramificaciones".

Cherry-pick: aplicar commits específicos #

git cherry-pick te permite tomar un commit específico de una rama y aplicarlo a otra sin fusionar toda la rama. Es útil cuando quieres trasladar un solo cambio (por ejemplo, una corrección) de una rama de características a la rama principal o a una rama de hotfix.

• Uso:

  1git cherry-pick <commit-hash>

Esto aplica el commit identificado por <commit-hash> a la rama actual.

3. Uso eficiente de ramas y pull requests #

Trabajar con ramas es esencial para un flujo de trabajo eficiente y ordenado, especialmente en equipos. Las ramas te permiten aislar nuevas características, correcciones de errores, y otras tareas sin afectar la rama principal (main o master).

Buenas prácticas con ramas #

1. Crea ramas pequeñas y específicas: Cada nueva funcionalidad o corrección debe desarrollarse en su propia rama. Evita hacer grandes cambios en una sola rama; esto facilita las revisiones de código y la resolución de conflictos.

   • Ejemplo:

     1git switch -c feature/agregar-formulario

2. Nombre descriptivo para las ramas: Utiliza nombres de ramas que indiquen claramente el propósito de la rama (por ejemplo, feature/nueva-funcionalidad, bugfix/corregir-error-123, hotfix/solucion-inmediata).

3. Eliminar ramas innecesarias: Una vez que una rama ha sido fusionada en main o develop, es una buena práctica eliminarla para mantener el repositorio limpio.

   • Eliminar rama local:

     1git branch -d nombre-rama

   • Eliminar rama remota:

     1git push origin --delete nombre-rama

Buenas prácticas con pull requests #

1. Crea pull requests pequeños y frecuentes: Un pull request debe contener cambios manejables y enfocados. Pull requests grandes son difíciles de revisar y propensos a errores.

2. Solicita revisiones de código: Antes de fusionar un pull request en la rama principal, solicítales a otros miembros del equipo que revisen el código. Esto ayuda a detectar errores o áreas de mejora.

3. Incluir una buena descripción: Explica claramente el propósito del pull request, los cambios realizados y, si es necesario, el contexto de las decisiones tomadas.

4. Creación de versiones y manejo de hotfixes #

Las versiones (releases) y los hotfixes son partes fundamentales del ciclo de vida de un proyecto, especialmente en proyectos de software. Git facilita la creación de versiones específicas del código y la gestión de correcciones urgentes sin interrumpir el flujo de desarrollo normal.

Creación de versiones #

Una release es una versión estable y lista para producción del proyecto. Git te permite marcar estos puntos clave en el historial utilizando etiquetas (tags).

1. Crear una etiqueta de versión:

   Una etiqueta (tag) marca un commit específico como una versión del proyecto. Se puede usar tanto en ramas de main como en release.

   • Etiqueta ligera:

     1git tag v1.0.0

   • Etiqueta anotada (con mensaje y metadatos):

     1git tag -a v1.0.0 -m "Lanzamiento de la versión 1.0.0"

2. Publicar una etiqueta:

   Una vez que has creado una etiqueta localmente, debes empujarla al repositorio remoto para compartir la versión con otros colaboradores:

   1git push origin v1.0.0

Manejo de hotfixes #

Los hotfixes son correcciones rápidas que se aplican a la rama de producción (main) para solucionar errores críticos que no pueden esperar al siguiente ciclo de lanzamiento. Git permite trabajar en hotfixes sin interrumpir el desarrollo en otras ramas.

1. Crear una rama de hotfix:

   Si descubres un error crítico en producción, crea una rama de hotfix a partir de la rama principal:

   1git switch -c hotfix/corregir-error-urgente main

2. Aplicar los cambios en la rama de hotfix:

   Realiza las correcciones necesarias y confírmalas en la rama de hotfix.

   1git commit -m "fix(prod): corrige error crítico en pasarela de pago"

3. Fusionar el hotfix en main y develop:

   Una vez que el hotfix ha sido probado, fusiónalo en la rama de producción (main) y en la rama de desarrollo (develop), para asegurar que el código de desarrollo incluya también la corrección.

   • Fusionar en main:

     1git switch main
     2git merge hotfix/corregir-error-urgente

   • Fusionar en develop:

     1git switch develop
     2git merge hotfix/corregir-error-urgente

4. Eliminar la rama de hotfix:

   Después de la fusión, elimina la rama de hotfix, ya que ya no es necesaria:

   1git branch -d hotfix/corregir-error-urgente
   2git push origin --delete hotfix/corregir-error-urgente