Anexo — Integración del trabajo a la rama main

Proyecto Final Integrador · Fase 1 → Fase 2 · Guía para los equipos cuyo avance quedó en ramas sin fusionar

¿Por qué este anexo? En la revisión de la Fase 1, dos equipos tenían su mejor trabajo (diseño y/o código) en ramas que nunca se fusionaron a main. La rama main es la entrega «oficial»: es lo que ve cualquiera que clone el repositorio y la base sobre la que se construye la Fase 2. Antes de seguir, es imprescindible integrar ese trabajo a main.

La rama es una herramienta para trabajar en paralelo sin pisarse (lo vimos en la Semana 8). Pero una rama solo aporta valor a la entrega cuando se fusiona de vuelta a main. Una rama que nunca se integra es trabajo invisible.

1. Comprobación previa (ambos equipos)

Antes de fusionar, conviene ver con claridad el estado del repositorio. Desde la carpeta del proyecto:

# Traer el estado completo del repositorio remoto (todas las ramas) git fetch origin # Ver el mapa de ramas y commits de un vistazo git log --all --oneline --graph --decorate # Listar las ramas remotas existentes git branch -r

En ese grafo se ve que main quedó «atrás» respecto de la rama de trabajo. El objetivo es traer los commits de la rama hacia main.

Vía recomendada: Pull Request en GitHub. Es el flujo que practicamos en la Semana 8 y el más seguro, porque GitHub muestra los conflictos y permite resolverlos con revisión del equipo. En el repositorio, pestaña Pull requests → New pull request → base: main, compare: la rama de trabajo → Create pull request → resolver conflictos si los hubiera → Merge pull request. Si prefieren la línea de comandos, sigan la sección correspondiente a su equipo más abajo.

2. Equipo López, Ciero, Encalada — fusión directa

Su trabajo de Fase 1 (el diseño de 45 KB y el registro de IA) está completo en la rama develop, y main no tiene cambios que entren en conflicto. Esto permite una fusión por avance rápido (fast-forward): main simplemente se adelanta hasta develop, sin conflictos.

git fetch origin # Pararse en main git checkout main # Fusionar develop: main avanza hasta develop (sin conflictos) git merge origin/develop # Publicar main ya integrada git push origin main

Resultado esperado. Git informa Fast-forward y lista los archivos incorporados (docs/diseno.md, docs/registro_ia.md). A partir de ahí, su diseño ya es visible en main.

3. Equipo Delgado, Lima, Pérez — fusión con resolución de conflictos

Su caso es distinto. Tanto main como la rama sandbox/initial-documentation tienen trabajo propio que divergió: ambas modificaron los mismos archivos por caminos diferentes. La fusión tendrá conflictos que ustedes deben resolver decidiendo, archivo por archivo, cuál es la versión correcta. No es un paso automático.

El grueso del trabajo está en sandbox/initial-documentation (esqueleto de módulos y documentación). La rama phase/first-assignment-delivery es idéntica a main (se puede ignorar) y feature/initial-library-skeleton tiene unos pocos commits que conviene revisar después, por si aportan algo no incluido.

git fetch origin git checkout main # Iniciar la fusion de la rama de trabajo git merge origin/sandbox/initial-documentation # Git se detiene y reporta los archivos en conflicto. Para verlos: git status

Los conflictos esperables aparecen en: README.md, docs/diseno.md, docs/consigna.md y varios módulos de src/ (por ejemplo main.py, ejemplares.py, socios.py, prestamos.py, indices.py, reservas.py).

3.1. Cómo resolver cada conflicto

Al abrir un archivo en conflicto, Git marca las dos versiones así:

<<<<<<< HEAD (contenido que estaba en main) ======= (contenido que viene de sandbox/initial-documentation) >>>>>>> origin/sandbox/initial-documentation

Para resolver: editar el archivo y dejar únicamente el contenido correcto (puede ser una versión, la otra, o una combinación de ambas), borrando las tres líneas de marcas (<<<<<<<, =======, >>>>>>>). Luego:

# Por cada archivo ya resuelto, marcarlo como listo git add README.md git add docs/diseno.md # ... y asi con cada archivo en conflicto # Cuando 'git status' no muestre mas conflictos, cerrar la fusion git commit # Publicar main integrada git push origin main

No resuelvan a ciegas. Eviten atajos como -X theirs o -X ours, que descartan automáticamente todo un lado del conflicto y pueden borrar trabajo válido. La decisión de qué versión de cada archivo es la correcta es justamente parte del trabajo de integración que se evalúa (dimensión D7). Es un buen momento para que el equipo revise junto qué quedó mejor en cada rama.

Si se complica, no hay daño. Mientras no se haya hecho commit ni push, la fusión se puede cancelar por completo y volver al estado anterior con:

git merge --abort

El repositorio queda exactamente como estaba. Pueden intentarlo de nuevo (o por la vía del Pull Request) sin haber roto nada.

4. Verificación posterior (ambos equipos)

# Confirmar que main ya contiene el trabajo git checkout main git log --oneline -5 # Verificar que los archivos esperados estan presentes ls docs/ ls src/ # Comprobar que el programa sigue ejecutando python src/main.py

En GitHub, al abrir el repositorio, la rama main debe mostrar ahora el diseño y el código integrados. Esa es la señal de que la entrega quedó correctamente consolidada.

5. Limpieza opcional

Una vez fusionada e integrada, la rama de trabajo ya cumplió su función. Pueden borrarla para mantener el repositorio ordenado (es opcional y no afecta lo ya integrado):

# Borrar la rama remota ya fusionada (ejemplo con develop) git push origin --delete develop

Qué NO hacer. No usar git push --force sobre main, ni git reset --hard para «pisar» main con la rama: ambas operaciones reescriben la historia y pueden borrar trabajo de otros integrantes de forma irreversible. La integración correcta es siempre sumar (merge), no sobrescribir.

El camino que sigue

Una vez integrado el trabajo, main vuelve a ser la única fuente de verdad del proyecto. La Fase 2 (codificación e integración) parte de ese estado: todo nuevo avance se hace en ramas cortas que se fusionan seguido a main mediante Pull Requests, evitando que el trabajo vuelva a quedar aislado. Integrar pronto y a menudo es lo que mantiene a un equipo sincronizado.