En este documento se detalla el flujo de trabajo que seguimos (seguiremos) en el equipo de desarrollo del LMS.
Convenciones en la nomenclatura para ramas y mensajes de commit.
Para las ramas, usaremos la estructura <token>/<short-descriptive-name>
.
Los tokens que podemos usar son:
chore
: mejoras en temas de administración/mantenimiento del proyecto (i.e. actualización de dependencias).docs
: creación/actualización de documentación (i.e.: guía de configuración del proyecto).feature
: nuevas funcionalidades que serán incluidas en el proyecto. (i.e. visualización de cursos).fix
/hotfix
/patch
: corrección de un bug esperado o inesperado (i.e. links rotos).refactor
: mejoras/reescritura de features existentes, no agrega un cambio grande a lo que actualmente tiene. (i.e. cambiar estados locales usando stateless components conectados a Redux).test
: agrega tests a un feature existente que no cuenta con los mismos (i.e. unit testing del componente de login).
Para los nombres que siguen al token, buscar palabras cortas que mejor describan en lo que se está trabajando.
Ejemplo: routing
, profile-settings
, course-management
.
Nota: Se podría evitar el uso de conectores :thinking_face:
- chore/deps-upgrade
- docs/setup
- feature/project-roadmap
- fix/student-routing
- refactor/settings-components
- test/cohort
Esta convención es una adapatación de la respuesta en este thread de StakOverflow.
Para los commits, seguiremos las convenciones seguidas en el equipo de Angular.
En resumen, la estructura de los mensajes de commit es <type>(<scope>): <subject>
.
-
El
type
son tokens cortos similares a los de las ramas, pueden ser:feat
(feature),fix
(bug fix),docs
(documentation),style
(formatting, missing semi colons, …),refactor
,test
(when adding missing tests),chore
(maintain). -
El
scope
hace referencia al lugar en donde se han trabajado los cambios. -
El
subject
debe cumpler algunas reglas más específicas:- En inglés, usar modo imperativo, present tense: change en vez de changed o changes.
- La primera letra en mayúsculas (para seguir el estándar por defecto que usa Git al hacer un
merge
orebase
). - Intentar acortar el mensaje a 50 caracteres, no debe pasar de 78.
- No poner punto al final
Nota: Los mensajes de commits no describen lo que alguien del equipo ha trabajado, por el contrario debe describir a la persona que obtendrá o aplicará los commits, lo que el pasará proyecto.
Ejemplo:
I"Added Github field in profile settings" ✗Someone"Adds Github field in profile settings" ✗This commit will"Add Github field to profile settings" ✔
Convenciones al trabajar colaborativamente en OSS.
Para iniciar a trabajar el proyecto seguiremos el Forking Workflow.
Esto consiste en que cada proyecto que contribuyamos, deberemos de hacer un fork para obtener una copia
local y trabajar sobre él, esto con el objetivo de tener la cantidad de ramas que cada developer desee en su
propio fork y dejar el repositorio upstream
con las ramas necesarias.
Para la etapa del desarrollo dentro del proyecto, usaremos Feature Branch Workflow. El cual implica en trabajar cada feature, task, fix, etc., en una rama específica, siguiendo la convención de nomenclatura de ramas descrita anteriormente.
Mezclando este flujo con los forks en la etapa de setup, se hará más sencillo la etapa de Code Review a través
de Pull Requests, los cuales deberán ser dirigidos al branch develop
, dejando la rama master
como una versión
estable de producción.
En el caso de que una tarea esté a cargo de más de una persona, estas llevarán el mismo flujo de PRs entre ellxs,
teniendo así un único PR hacia el remoto upstream
.
Para la etapa de llevar un release o hacer un hotfix de un release, haremos uso del Gitflow Workflow.
Esto significa, que crearemos una rama de release
a partir de la rama develop
y hotfix
a partir de master para
dejar la rama de desarrollo develop
libre de seguir trabajando en las siguientes veriones.
Cada vez que se haga un release, seguiremos el formato de versionamiento descrito en Semver. Y seguiremos las etapas de desarrollo dentro de una versión planificada.
ayúdame a crear un commit corto en ingles, que diga que borre un componente que se llamaba ejCategories que esta en la carpeta service