ivandevp/lms-git-conventions.md

## lms-git-conventions.md

      
    Raw
  

              lms-git-conventions.md
            
          
    LMS Git Conventions

En este documento se detalla el flujo de trabajo que seguimos (seguiremos) en el equipo de desarrollo del LMS.

Naming Conventions

Branches
Commits


Workflow

Setup


Development
Release
Versioning


Naming Conventions

Convenciones en la nomenclatura para ramas y mensajes de commit.
Branches

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:

Ejemplos


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

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 o rebase).
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" ✔


Workflow

Convenciones al trabajar colaborativamente en OSS.
Setup

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

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.
Release/Hotfix

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

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.