Nota
Se asume que se está siguiendo un flujo de desarrollo a la "gitflow", esto es, se tiene al menos branches:
- develop: Ultimos features, estado del arte. No necesariamente estructurado en iteraciones
- staging: Pre-release, features seleccionados para siguiente versión, listos para ser testeados, QA-eados y reparados. (fixes también hay que irlos tirando a develop)
- main: Versión estable, release funcional, mapea 1 a 1 con el estado del servidor de producción. Producción nunca debería estar en otra rama que main
La idea es que git + github hagan la pega por nosotros, y nosotros enfocarnos sólo en lo que nos importa: Desarrollar software de calidad.
(o su equivalente de Gitlab: "merge" requests) Es una solicitud de integración de nuevos cambios
- ✅ Promueve desarrollo incremental autocontenido
- ✅ Muchísima mejor visibilidad de cambios (a través de diffs)
- Facilidad para revertir cambios en caso de ser necesario
- Commits normales pueden entremezclarse cuando se hacen merges de avances de distintas personas. PRs ayudan a agrupar commits por "unidad incremental"
- ✅ Posibilidad de agregar descripción
- Markdown, admite formato, links, imágenes, y básicos
- Puedo referenciar entre pull requests de front y back: Obligo a reviewer del PR a revisar ambos en conjunto como una misma unidad.
- Puedo agregar instrucciones antes de mergear si es necesario (ejemplo: Modificar base de datos, instalar tal herramienta, etc.)
- ✅ Facilita trabajo en equipo (Visibilidad compartida)
- ✅ Facilita peer-review: Asignación de revisión a compañeros
- ✅ Visibilidad historica
- Ir a Pull Requests
- Seleccionar ramas de origen (donde estan mis nuevos features) y destino (hacia donde quiero que se mezclen)
- Mostrará un preview de las diferencias entre lo antiguo y lo nuevo. Crear PR
- Agregar descripción. Ayuda enriquecer el formato un poco usando notación Markdown
- Opcional: Agregar tags ("Work in progress!" por ejemplo), asignar reviewers, agregar comentarios... y otros.