Objetivo técnico
Al terminar podrás versionar una configuración reproducible sin publicar claves. En RAG manejarás credenciales del modelo y de la base de datos; una clave filtrada puede exponer datos y generar costos.
Antes de empezar
Necesitas Git y una carpeta de práctica. Verifica con git --version. Usaremos valores falsos: nunca pegues una API key real en el ejercicio.
Paso a paso
- Inicializa el repositorio y crea los archivos de entorno:
git init
touch .env .env.example .gitignore
- En
.env, escribeOPENAI_API_KEY=valor-local-falso. - En
.env.example, escribeOPENAI_API_KEY=. Este archivo documenta la variable sin revelar su valor. - En
.gitignore, agrega.env. - Ejecuta
git status. Debes ver.env.exampley.gitignore, pero no.env. - Ejecuta
git check-ignore -v .envpara identificar la regla exacta que lo ignora. - Agrega solo los archivos seguros con
git add .env.example .gitignore.
Verificación
Ejecuta git diff --cached. La salida no debe contener valor-local-falso. Esa inspección es el gate antes del commit.
Errores frecuentes
.envaparece engit status: falta la regla o el nombre no coincide.- Agregaste la clave antes de ignorarla:
.gitignoreno afecta archivos ya rastreados; quítalo del índice y rota cualquier clave real. - Copiaste valores a
.env.example: ese archivo sí se publica.
Práctica
Agrega SUPABASE_URL y SUPABASE_ANON_KEY a ambos archivos, pero deja vacíos los valores del ejemplo. Sin mirar, usa git check-ignore y git diff --cached para demostrar que el secreto queda fuera.
Puente al RAG
El Bloque 5 necesita claves para embeddings y Postgres. Este patrón permite que otra persona clone el proyecto, sepa qué configurar y no reciba tus credenciales.