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.

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:

Usar el presente imperativo: Es una convención común escribir los mensajes de commit en tiempo presente e imperativo, ya que refleja el hecho de que el commit "hace" algo (como si fuera un comando).

Ejemplo:

1Agrega validación al formulario de registro
2Corrige error en el cálculo de impuestos
3Actualiza dependencias a la versión más reciente

Mantener mensajes cortos y descriptivos: El mensaje de commit debe ser claro y conciso, describiendo qué se cambió y por qué. La primera línea debe ser una descripción corta (máximo 50 caracteres).

Agregar un cuerpo cuando sea necesario: Si el cambio es complejo o requiere contexto adicional, añade un cuerpo descriptivo después de la línea del título. Deja una línea en blanco entre el título y el cuerpo. Aquí puedes explicar cómo se implementaron los cambios o añadir referencias a issues o pull requests.

Ejemplo:

1Agrega validación al formulario de registro
2
3Se añadió la validación de campos obligatorios y el chequeo
4de formatos de correo electrónico para evitar errores en la
5base de datos. Ref: Issue #23.

Referenciar issues o pull requests: Es útil incluir referencias a números de issue o pull request para mantener una relación clara entre los commits y las tareas del proyecto.

Ejemplo:

1Soluciona la visualización en dispositivos móviles (Ref #45)

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.

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:

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 checkout -b feature/agregar-formulario
```
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).
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:

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

Creación de versiones (release) 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 (release):

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

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"
```
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.

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 checkout -b hotfix/corregir-error-urgente main

Aplicar los cambios en la rama de hotfix:

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

1git commit -m "Corrige error crítico en producción"

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 o feature), para asegurar que el código de desarrollo incluya también la corrección.

Fusionar en main:

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

Fusionar en develop:

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

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

Resumen

Las buenas prácticas en Git son esenciales para mantener un flujo de trabajo eficiente, organizado y colaborativo.

Curso git nivel medio