Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
1
respuesta

[Sugerencia] Branch Naming Conventions

Usar una estructura estándar al momento de crear una rama facilita entender el propósito de la rama con solo leer su nombre.
aqui algunos tipos,para que es y un ejemplo.

  • feat/
    • Nueva funcionalidad
    • feat/login-form
  • fix/
    • Corrección de errores
    • fix/navbar-crash
  • hotfix/
    • Corrección urgente directamente sobre producción
    • hotfix/payment-bug
  • refactor/
    • Mejora de código sin cambiar funcionalidad
    • refactor/user-service
  • docs/
    • Cambios de documentación
    • docs/update-readme
  • test/
    • Añadir o modificar pruebas
    • test/add-login-tests
  • chore/
    • Tareas de mantenimiento (configs, scripts, etc.)
    • chore/update-dependencies
  • release/
    • Preparar o etiquetar versiones
    • release/1.2.0
  • ci/
    • Cambios en CI/CD
    • ci/github-actions-node14

Recomendaciones adicionales
Usa kebab-case (nombre-con-guiones) o snake_case, pero nunca espacios.
Sé específico y breve: feat/add-user-avatar, no feat/thing1.
Limpia ramas antiguas cuando ya no se usen (git branch -d).
Protege main y develop en el repositorio (requiere PRs y revisiones).

1 respuesta

¡Hola Vicente, espero que estés bien!

¡Gracias por compartir tus recomendaciones sobre las convenciones de nombres para branches! Es una práctica excelente para mantener el repositorio organizado y facilitar la colaboración en equipo.

Al crear ramas siguiendo estas convenciones, no solo se mejora la claridad del propósito de cada rama, sino que también se facilita el seguimiento de cambios y la colaboración entre los miembros del equipo. Por ejemplo, si estás trabajando en una nueva funcionalidad, usar feat/nombre-de-la-funcionalidad permite que todos entiendan inmediatamente que se trata de una nueva característica que se está desarrollando.

Además, tu sugerencia de usar kebab-case o snake_case es muy útil, ya que evita problemas de compatibilidad que pueden surgir con espacios en los nombres de las ramas.

En cuanto a la limpieza de ramas antiguas, es una excelente práctica para mantener el repositorio limpio y evitar confusiones con ramas que ya no son necesarias. Y proteger las ramas principales como main y develop es crucial para asegurar que solo cambios revisados y aprobados se integren en ellas.

Espero que estas convenciones te ayuden a mantener tus proyectos bien organizados y que sigas disfrutando de tu aprendizaje en Git y GitHub.

¡Espero haber ayudado y buenos estudios!