Repositorios, forks, .env y Open Source seguro

Objetivo

Evaluar y adaptar código ajeno sin comprometer secretos o entorno.

Explicación

Antes de ejecutar un repo revisa README, LICENSE, dependencias, scripts, issues recientes y variables de entorno. Un fork crea tu copia remota; una branch documenta tu adaptación. .env debe estar en .gitignore y nunca debe contenerse en capturas o commits. 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 Repositorios, forks, .env y Open Source seguro 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: git status no lista .env como archivo nuevo preparado para versionar. La verificación principal será: git check-ignore -v .env muestra qué regla lo ignora. 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

cp .env.example .env
git check-ignore .env
git status

Archivos o datos de entrada

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

Práctica guiada

Usa la plantilla .gitignore y crea un .env ficticio.

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 «Repositorios, forks, .env y Open Source seguro».
• Ejecuta la práctica guiada: Usa la plantilla .gitignore y crea un .env ficticio. Documenta el comando, consulta o acción exacta y el resultado obtenido.
• Resuelve el reto sin mirar la solución: Comprueba con git check-ignore que no puede entrar accidentalmente al commit. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
• Compara tu resultado con el criterio esperado: git status no lista .env como archivo nuevo preparado para versionar. Después ejecuta la comprobación: git check-ignore -v .env muestra qué regla lo ignora.
• Provoca deliberadamente un caso problemático relacionado con este error frecuente: Eliminar un secreto del último commit no garantiza que desaparezca de la historia remota.. Comprueba que sabes detectarlo y corregirlo.

Reto sin ayuda

Comprueba con git check-ignore que no puede entrar accidentalmente al commit.

Resultado esperado

git status no lista .env como archivo nuevo preparado para versionar.

Cómo verificarlo

git check-ignore -v .env muestra qué regla lo ignora.

Checklist de validación

• El resultado cumple: git status no lista .env como archivo nuevo preparado para versionar.
• Has ejecutado esta verificación y puedes explicar el resultado: git check-ignore -v .env muestra qué regla lo ignora.
• 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

• Eliminar un secreto del último commit no garantiza que desaparezca de la historia remota.

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 «Repositorios, forks, .env y Open Source seguro».
• ¿Cómo evitarías subir secretos o cambios accidentales al repositorio? Explica qué evidencia enseñarías al revisor.

Siguiente paso

Aplicarás Git/GitHub en todos los proyectos del curso.

Recursos de esta lección