Pull Requests e Issues

Objetivo

Usar GitHub como flujo de colaboración y revisión.

Explicación

Un PR debe explicar problema, solución, pruebas y riesgos. Un Issue puede capturar el trabajo antes de empezar. Mantén el PR pequeño para que sea revisable. Git y GitHub son parte del trabajo diario de un equipo de datos. No basta con memorizar comandos: debes ser capaz de dejar cambios pequeños, revisables y reproducibles, evitar secretos y explicar qué cambia un Pull Request antes de mezclarlo. Para trabajar Pull Requests e Issues de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: El revisor sabe qué revisar y cómo reproducirlo. La verificación principal será: Una persona ajena al cambio puede seguir “Cómo probar”. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.

Contexto profesional

Git y GitHub son parte del trabajo diario de un equipo de datos. No basta con memorizar comandos: debes ser capaz de dejar cambios pequeños, revisables y reproducibles, evitar secretos y explicar qué cambia un Pull Request antes de mezclarlo.

Ejemplo real

## Qué cambia
- Añade fact_orders

## Cómo probar
- dbt build --select fact_orders+

## Riesgos
- Cambia grain: no

Archivos o datos de entrada

• templates/README-template.md
• templates/.gitignore-data

Práctica guiada

Escribe el texto de un PR para una mejora del proyecto dbt.

Laboratorio paso a paso

• Prepara el entorno y localiza los datos/archivos de entrada: templates/README-template.md, templates/.gitignore-data. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
• Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Pull Requests e Issues».
• Ejecuta la práctica guiada: Escribe el texto de un PR para una mejora del proyecto dbt. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Añade checklist de tests y una captura/resultado relevante si procede. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: El revisor sabe qué revisar y cómo reproducirlo. Después ejecuta la comprobación: Una persona ajena al cambio puede seguir “Cómo probar”.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: PR sin contexto obliga al revisor a reconstruir tu intención.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Añade checklist de tests y una captura/resultado relevante si procede.

Resultado esperado

El revisor sabe qué revisar y cómo reproducirlo.

Cómo verificarlo

Una persona ajena al cambio puede seguir “Cómo probar”.

Checklist de validación

• El resultado cumple: El revisor sabe qué revisar y cómo reproducirlo.
• Has ejecutado esta verificación y puedes explicar el resultado: Una persona ajena al cambio puede seguir “Cómo probar”.
• Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
• Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).

Errores frecuentes

• PR sin contexto obliga al revisor a reconstruir tu intención.

Qué debes recordar

Un repositorio profesional permite entender, reproducir y revisar el trabajo.

Preguntas de entrevista

• ¿Qué debería contener un commit o PR para que sea revisable? Aplícalo concretamente a «Pull Requests e Issues».
• ¿Cómo evitarías subir secretos o cambios accidentales al repositorio? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Ahora crearás un README profesional.

Recursos de esta lección