ft versionamiento
- Repositorios
| Nombre | URL | Propósito |
|---|---|---|
| Backend-Equipo18 | https://github.com/andergcp2/backend-proyecto-final | Código del backend de la aplicación ABC Jobs |
| Frontend-Equipo18 | https://github.com/andergcp2/frontend-proyecto-final | Código del frontend de la aplicación ABC Jobs |
- Ramas
| Nombre rama | Propósito |
|---|---|
| Main | Esta rama contiene el paquete de funcionalidades de la aplicación ABC Jobs |
| Develop | En esta rama se integran los cambios desarrollados en cada feature |
| Feature/* | Cada rama feature contiene la implementación de una funcionalidad o historia de usuario |
- Flujo
GitFlow (Sin ramas release)
- Acuerdos
Indicar los acuerdos del equipo para uso de los repositorios y ramas. Incluir acciones como creación y clonación de repositorios, actualizaciones e integraciones (mezclas).
| Acción | Quién | Cuándo | Dónde |
|---|---|---|---|
| Clonar los repositorios de Backend y Frontend en su máquina local | Todos los desarrolladores | Al empezar a trabajar en el proyecto | Repositorios |
| Crear Rama develop a partir de main | Anderson Castiblanco | Crear la rama develop para el trabajo de desarrollo | Rama develop |
| Crear un PR al mezclar cambios de develop a main | Todos los desarrolladores | Cuando los cambios estén aprobados en develop y se requiera hacer una entrega de valor al cliente | Rama main |
| Ejecutar los tests creados antes de mezclar de develop a main | Github Actions | Cuando se cree un PR para fusionar cambios de develop a main | Rama main |
| Ejecutar los tests creados antes de mezclar de una rama feature a develop | Github Actions | Cuando se cree un PR para fusionar cambios de feature/* a develop | Rama develop |
| Mezclar cambios de ramas feature/* a rama develop | Todos los desarrolladores | Cuando se tenga listo y probado el código de una nueva funcionalidad o HU y se quiera fusionar los cambios a develop | Rama develop |
| Crear ramas para trabajar en nuevas funcionalidades o HUs con el formato feature/<< nombre funcionalidad o HU >> | Todos los desarrolladores | Cuando se empiece a trabajar en una nueva funcionalidad o HU | Ramas feature/* |
La estrategia a usar es la propuesta en https://semver.org/lang/es/, donde:
Dado un número de versión MAYOR.MENOR.PARCHE, se incrementa:
- La versión MAYOR cuando realizas un cambio incompatible en el API.
- La versión MENOR cuando añades funcionalidad compatible con versiones anteriores.
- La versión PARCHE cuando reparas errores compatibles con versiones anteriores.
Por tanto cuando se acepte un pull request en la rama main se incrementará el dígito de la mitad si se agregó una nueva funcionalidad, y el de la derecha si se corrigió un error. El dígito de la izquierda se mantendrá en la versión 1.
La versión PARCHE debe reiniciarse cuando la versión MENOR se incrementa.
Ejemplo: 1.5.1
Esto indicará 2 funcionalides y un bug solucionado en la versión. La siguiente versión si se agrega una nueva funcionalidad compatible será 1.6.0