CAPÍTULO 1 · Un equipo, una base común
El proyecto empieza a pertenecer al equipo
Una carpeta que funciona no basta para colaborar. Si otra persona agrega un modelo mientras cambiamos una vista, necesitamos saber qué hizo cada una y decidir cómo reunir ambos trabajos. Compartir archivos sueltos hace difícil distinguir la versión correcta; también vuelve incierto recuperar una configuración que antes funcionaba.
Git nos permite registrar cambios con una intención reconocible y trabajar en ramas. GitHub se convierte en el lugar donde compartimos ese historial. VS Code sigue siendo nuestro espacio de trabajo: allí editamos y revisamos diferencias, cuidando que el intérprete seleccionado pertenezca al entorno virtual. El repositorio conserva código e instrucciones, mientras cada integrante reconstruye sus paquetes localmente.
Dejamos fuera secretos, archivos temporales y el entorno instalado. Esta decisión también será útil al publicar: podremos relacionar un paquete con una versión concreta. Sin embargo, al abrir el proyecto aparece otra dificultad cotidiana. Para compartir trabajo no solo necesitamos conservarlo; necesitamos reconocer rápidamente dónde está cada responsabilidad.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
El taller compartido
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Clonar. Copia el proyecto versionado
- Rama. Aísla una propuesta
- Verificar. Prueba y revisa cambios
- Entregar. Publica para revisión
01 / EL PROBLEMA
¿Para qué sirve?
Un integrante necesita reproducir el proyecto existente. Ejecutar startproject sobre una copia o subir el entorno virtual complica la colaboración.
02 / COMPRENDER
El concepto, explicado
Crear un proyecto e incorporarse a uno son recorridos diferentes. Si ya existe el repositorio, clónalo e instala sus dependencias. Si nace ahora, crea el entorno, ejecuta startproject y prepara el primer commit.
Una rama separa una propuesta. fetch actualiza referencias remotas; merge integra cambios en la rama actual. Revisa git status antes de cambiar de contexto y revisa el diff antes del commit.
En VS Code selecciona el intérprete .venv de esta carpeta. Una terminal que muestra otro Python puede instalar paquetes fuera del proyecto. La U indica un archivo sin seguimiento: decide si versionarlo o ignorarlo; no justifica borrar archivos ni hacer reset --hard.
03 / CONSTRUIR
Implementación paso a paso
- Clona el repositorio y abre su carpeta en VS Code.
- Crea .venv con python -m venv .venv y selecciona ese intérprete.
- Instala requirements.txt y ejecuta los checks del README.
- Crea una rama, cambia un caso pequeño, prueba y revisa el diff.
- Publica la rama y abre una revisión antes de integrar a main.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell; sustituye la URL por la de tu proyecto
git clone https://github.com/tu-organizacion/sensorhub.git
cd sensorhub
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
git switch -c feature/consulta-sensores
git status
git diff
# Tras editar y comprobar, añade únicamente los archivos de tu cambio
git add catalogo/views.py
git commit -m "Añade consulta de sensores"
git push --set-upstream origin feature/consulta-sensores
# Para integrar lo nuevo de main en tu rama, con árbol limpio:
git fetch origin
git merge origin/mainCómo leer el ejemplo
- Usar el ejecutable de .venv evita cambiar políticas de ejecución para activar scripts.
- git commit -m usa comillas normales y guion simple; --set-upstream usa dos guiones.
- Resuelve conflictos, vuelve a probar y confirma la integración antes de subir.
Error habitual
No copies otro repositorio con su .git dentro del proyecto. Tampoco ejecutes clean -fd o reset --hard como arreglo rutinario.
05 / PRACTICAR
Tu turno
Clona en otra carpeta e intenta arrancar usando solo los archivos versionados.
Ver solución orientativa
Si necesitas copiar tu .venv o secretos de otro equipo, falta documentar dependencias o variables. Registra nombres en .env.example, nunca sus valores reales.
06 / VERIFICAR
Cómo sabes que funciona
- git status no muestra .env ni .venv preparados para commit.
- La nueva copia ejecuta check sin depender de rutas de tu equipo.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 11 de octubre de 2026.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Apps y dependencias →Continuar en modo relato