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