|
| 1 | +[volver al inicio](/readme.md) |
| 2 | + |
| 3 | +# Fase de seguimiento de la implementación |
| 4 | + |
| 5 | +Durante la implementación de la solución se debe hacer un seguimiento del avance del proyecto y el trabajo realizado mediante el uso de herramientas de control de versiones y gestión de tareas. |
| 6 | + |
| 7 | +El seguimiento de la implementación se divide en dos partes: el seguimiento de las tareas y el seguimiento de los cambios en el código fuente. |
| 8 | + |
| 9 | +<br/> |
| 10 | + |
| 11 | + |
| 12 | +## Tareas y commits |
| 13 | + |
| 14 | +Las tareas son los objetivos que se deben cumplir para completar la fase de implementación, y los commits son registros de los cambios en el código fuente. Cada tarea debe tener un commit asociado, así como un mensaje que se guardará en el repositorio. Este mensaje debe describir los cambios realizados usando el formato: |
| 15 | + |
| 16 | +``` |
| 17 | +<tipo>: <descripción> |
| 18 | +
|
| 19 | +<detalles> |
| 20 | +``` |
| 21 | + |
| 22 | +<br/> |
| 23 | + |
| 24 | +El **tipo** del commit indica el tipo de cambio realizado. Los tipos de commit son: |
| 25 | + |
| 26 | +- bug: se corrigió un error. |
| 27 | +- configuration: cambios en la configuración, dependencias o herramientas de construcción. |
| 28 | +- docs: cambios en la documentación. |
| 29 | +- feat: se agregó una nueva característica. |
| 30 | +- performance: mejoras en el rendimiento. |
| 31 | +- refactor: se reestructuró el código sin agregar o quitar funcionalidades. |
| 32 | +- style: cambios en la interfaz de usuario. |
| 33 | +- test: cambios en las pruebas automatizadas. |
| 34 | + |
| 35 | + |
| 36 | +<br/> |
| 37 | + |
| 38 | +La **descripción** inicial del commit es un título que sirve para identificar el cambio al leer el historial o buscar un commit en particular. Debe ser breve con un máximo de 50 caracteres y estar escrito en minúsculas. Se debe usar el tiempo pasado y no debe terminar con un punto. |
| 39 | + |
| 40 | +Para facilitar la navegación, se recomienda que la primera palabra sea estándar según el cambio: |
| 41 | + |
| 42 | +- creado: se han creado nuevos archivos. |
| 43 | +- actualizado: se han actualizado archivos existentes. |
| 44 | +- - agregado: se ha agregado contenido. |
| 45 | +- - cambiado: se ha cambiado contenido. |
| 46 | +- - quitado: se ha quitado contenido. |
| 47 | +- - renombrado: se ha renombrado contenido. |
| 48 | +- reemplazado: se han reemplazado archivos. |
| 49 | +- eliminado: se han eliminado archivos. |
| 50 | +- corregido: se han corregido errores. |
| 51 | +- reestructurado: se ha reestructurado código. |
| 52 | +- renombrado: se han renombrado archivos. |
| 53 | +- movido: se han movido archivos. |
| 54 | +- mejorado: se ha mejorado código. |
| 55 | + |
| 56 | +<br/> |
| 57 | + |
| 58 | + |
| 59 | +### Ejemplo de commit |
| 60 | + |
| 61 | +``` |
| 62 | +docs: creado el archivo readme.md |
| 63 | +
|
| 64 | +Se creó el archivo readme.md con la descripción del proyecto. |
| 65 | +``` |
| 66 | + |
| 67 | + |
| 68 | +### Consideraciones |
| 69 | + |
| 70 | +- Se debe hacer un commit que represente la tarea finalizada, pero esto no significa que no se puedan hacer otros commits durante el desarrollo de la tarea. |
| 71 | +- Es una buena práctica durante la definición de tareas escribir los mensajes de los commits que se harán para cada tarea. |
| 72 | + |
| 73 | + |
| 74 | +<br/> |
| 75 | + |
| 76 | +## Docstrings |
| 77 | + |
| 78 | +Los docstrings son comentarios que se agregan al código para documentar su funcionamiento. Estos comentarios deben ser agregados a funciones, métodos y clases. |
| 79 | + |
| 80 | +[ver más](../textos/c%C3%B3digo.md#docstrings) |
| 81 | + |
| 82 | + |
| 83 | +## Artefacto |
| 84 | + |
| 85 | +La documentación de esta fase son el registro de tareas, el historial de versiones y los docstrings. |
0 commit comments