Etiquetas de flujo de trabajo de Git

En el artículo anterior, discutimos el flujo de trabajo de bifurcación en el ecosistema de código abierto y cómo ese flujo de trabajo puede ayudar a resolver cualquier problema que pueda surgir al momento de contribuir a proyectos de código abierto. Pero junto con esos pasos en el flujo de trabajo, es importante que siga una convención de nomenclatura adecuada para sus mensajes de compromiso, nombres de ramas o títulos de solicitud de extracción, por lo que tener estas etiquetas adecuadas puede ayudarlo a subir de nivel sus contribuciones y hacer que otros mantenedores sean más fáciles de usar. evaluar su trabajo.

Convenciones de nomenclatura para sucursales

La sintaxis de su nombre de rama puede ser similar a algo como esto:

name/issue#/description

Aquí el nombre puede ser su ID de Github o su nombre inicial, el problema indica el número de problema y una descripción muy breve sobre la rama

Ejemplo: 

dora/45/new-feature

También puede considerar esta convención de nomenclatura:

A. Si es una característica nueva

feature/name/issue#    

B. Si la rama es para corregir un nuevo error

bug/name/issue#                

Ejemplo:

new-footer/dora/251

Etiquetas para los mensajes de Git Commit

Tener mensajes de confirmación adecuados ayuda a aumentar la legibilidad de los registros de git y el historial de archivos. Uno puede considerar nombrar sus mensajes de compromiso en las siguientes categorías:

  • feat – Si trabajas en una nueva característica
  • corrección: si su código cambia, ayuda a corregir algún error
  • docs – Cambios relacionados con la documentación
  • estilo: cambios relacionados con el formato
  • refactor: si los cambios están relacionados con la reestructuración del código base
  • prueba: si se agregan nuevas pruebas o se modifican pruebas antiguas
  • Tarea: cambios regulares de mantenimiento, por ejemplo, generación de documentación, creación de versiones, procesamiento de compilación, etc.

Ejemplo: 

feat: New xyz component added
docs: Updated broken blog page link

También puede hacer que los mensajes de confirmación sean más precisos mencionando el alcance de los archivos:

type(scope): Message

Aquí, el tipo incluye varias categorías que se discutieron anteriormente, por ejemplo, hazaña, error, documentos, etc.
Alcance: representa el lugar donde se realizan los cambios de código, por ejemplo, nombres de archivo

Ejemplo:

chore(netlify): Redirected old models

Directrices de solicitud de extracción

Al abrir una solicitud de extracción, considere agregar los siguientes puntos en el mensaje

  • Número de emisión: emisión que el PR puede cerrar
  • Cambios:  escriba en detalle sobre los nuevos cambios que realizó
  • Problema relacionado/PR: vincula todos los problemas relacionados y la solicitud de extracción

Ejemplo:

# Closes #412 

# Changes

- Change 1
- Change 2

# Related Issues:
- Issue #410
- PR #387

Aquí, Closes #412 le indicará a Github que la fusión de este PR cerrará el problema con el número 412 con éxito y los cambios se pueden enumerar con viñetas para aumentar la legibilidad.

Publicación traducida automáticamente

Artículo escrito por aniruddhashriwant y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *