Añadir un Label acorde con la tarea (feature, bug, docs …).
Añadir el issue a Project.
Asignar tarea a ti mismo o al desarrollador que vaya a trabajar en ella.
2. Actualizar issue en Kanban
El Kanban deberá estar actualizado con las tareas.
Cuando tengas una tarea pendiente para los próximos días debes mover el issue a la columna To Do.
Cuando empieces a trabajar en una tarea debes mover el issue a la columna In Progress.
3. Crear una rama localmente
Cada rama debe esar asociada a un issue.
Antes de empezar a programar debes crear la rama de la siguiente manera:
git branch feature/someIssue
El nombre deberá ser descriptivo pero corto, en formato camelCase
No te olvides de moverte a la rama después de crearla:
git switch feature/someIssue
Una vez tengas algún commit podrás subir la rama al repositorio con git push y deberás asociar dicha rama al issue en gitea.
Nombres de ramas
Usaremos un formato similar a los commits:
feature/issueName
bugfix/issueName
chore/issueName
refactor/issueName
docs/issueName
4. Programar y hacer commits
Los commits deberán usar el formato de Conventional Commits
para hacer un commit añadiremos los cambios con:
git add path/to/file
Si tenemos cambios que queremos separar en diferentes commits en el mismo fichero podemos usar:
git add -i
Una vez tengamos todos los cambios añadidos podemos asegurarnos con git status y crearemos el commit de la siguiente forma:
git commit #para abrir el editor y añadir una descripción larga (recomendado)git commit -m "feat: descripción de los cambios" #para hacer un commit simple
Puedes (y es recomendable) pushear los cambios a remoto frecuentemente, en especial cuando trabajas en feature solo, y estás pendiente de revisión.
5. Crear pull request
Cuando hayas implementado todo lo descrito en el issue deberás hacer un pull request, asegurate de tener todos los cambios pusheados a tu rama antes.
Recuerda hacer el PR de tu rama a la rama develop NO a main.
El titulo del PR debe ser descriptivo, para cerrar automáticamente el issue asociado debes añadir “Closes <#issue-id>” debe ser algo como el siguiente ejemplo:
Implement CRUD for user class (Closes #2)
Añade detalles de implementación en la descripción del PR para ayudar a la revisión!
Una vez esté creado el PR debes mover el issue en el Kanban a la columna In Review.
Recuerda notificar en el canal de Teams apropiado para que la review sea cuanto antes.
WIP Pull Request
Cuando estés trabajando en una PR con mucho contenido, o que necesite feedback, puedes crearla antes de haber terminado de programar. Para esto, es necesario marcarla en el título:
WIP: Implement CRUD for user class (Closes #2)
Esto permite hacer revisiones parciales del código, mientras uno sigue desarrollando.
