Opcion

DIARIO.md

@@ -0,0 +1,92 @@
+# LABORATORIO DE GIT
+## Juan José Ruiz Rivero
+## Abril de 2026
+
+
+
+
+
+<hr>
+
+# Tarea 1 — Fork y configuración inicial
+### Diario: Escribe qué es un fork y para qué sirve upstream. Adjunta la captura 1 y la captura 2.
+Un fork es una copia de un proyecto alojado en un repositorio remoto que pasa a estar bajo nuestro propio control.
+
+El término upstream se utiliza para referirse al repositorio original del proyecto, es decir, al repositorio remoto cuyo propietario es otra persona u organización.
+
+Se diferencia de origin, que es el nombre que recibe normalmente nuestro propio repositorio remoto, asociado a la copia sobre la que trabajamos.
+
+#### Captura 1: Terminal con git remote -v mostrando origin y upstream 
+<img width="1919" height="1030" alt="C1remote" src="https://github.com/user-attachments/assets/0620617e-fb0a-40b7-8aba-c0d6f9d8e2ef" />
+
+#### Captura 2: GitHub con la rama dev visible en el desplegable de ramas
+<img width="1913" height="728" alt="C2main_dev" src="https://github.com/user-attachments/assets/539e89d9-8129-4a7c-aee2-8f5c59ede199" />
+
+<hr>
+
+# Tarea 2 — Feature branch A: añadir la Opción 5
+### Diario: Explica por qué la rama parte de dev y no de main. Adjunta la captura 3.
+Siguiendo la filosofía habitual de los flujos de desarrollo, es recomendable que todos los cambios y nuevas funcionalidades se trabajen sobre una rama dev.
+
+De este modo, la rama main representa el estado estable y desplegado en producción, mientras que el resto de cambios permanecen en dev hasta que estén listos para pasar a producción.
+
+#### Captura 3: La app en el navegador con la Opción 5 recién añadida      
+<img width="1326" height="982" alt="Caputra 3" src="https://github.com/user-attachments/assets/ec22b02b-d36a-4fc1-887e-0981cc91c4ed" />
+
+
+
+
+
+
+
+
+
+<hr>
+
+# Tarea 3 — Feature branch B: añadir la Opción 6 (aquí está el conflicto)
+### Diario: Explica qué es un conflicto en Git y por qué se va a producir aquí.
+Se ha creado una rama que modifica una misma línea de un fichero. En paralelo, se ha creado otra rama que también cambia esa misma línea, pero con una modificación distinta.
+
+Como todavía no se han integrado ambas ramas, al intentar fusionarlas aparecerá un conflicto. En ese momento será necesario resolverlo manualmente, eligiendo qué cambio se mantiene o combinando ambos si procede.
+
+
+
+<hr>
+
+# Tarea 4 — Pull Request 1: Feature A a dev
+### Diario: Explica qué revisaste en la pestaña Files changed y por qué es útil hacerlo antes de mergear. Adjunta la captura 4.
+Revisé las modificaciones realizadas respecto al estado original del fichero. Esto es útil para comprobar con precisión qué cambios se van a confirmar y asegurar que el contenido final es el esperado antes de realizar el commit.
+
+#### Captura 4: El PR de Feature A en GitHub con la pestaña Files changed abierta  
+<img width="1920" height="1026" alt="C4_4 3" src="https://github.com/user-attachments/assets/7d935e10-0ae1-46c5-95c1-9d6d671c7aaf" />
+
+
+<hr>
+
+# Tarea 5 — Pull Request 2: Feature B a dev, conflicto
+### Diario: Explica qué significan los marcadores <<<<<<<, ======= y >>>>>>> y qué criterio usaste para decidir qué versión conservar. Adjunta las capturas 5, 6 y 7.
+Cuando se produce un conflicto, el sistema marca en el código la zona afectada indicando claramente dónde comienza y termina el conflicto mediante delimitadores como <<<<<<< y >>>>>>>.
+
+Entre estos límites aparece la división de las distintas versiones del mismo fragmento de código, separadas por =======, lo que permite identificar las opciones en conflicto. A partir de ahí, el usuario debe decidir qué versión conservar o cómo combinarlas para resolver el conflicto de forma definitiva.
+
+
+#### Captura 5: El PR de Feature B en GitHub mostrando el banner rojo de conflicto    
+<img width="1920" height="1026" alt="5 2bis" src="https://github.com/user-attachments/assets/2834bb26-08c2-445f-bca9-965ca4932b79" />
+
+
+#### Captura 6: Los marcadores de conflicto (<<<<<<<, =======, >>>>>>>) en VS Code       
+<img width="1920" height="1030" alt="C5_5 3_4" src="https://github.com/user-attachments/assets/73c88ddb-99fc-4fbd-9862-b3759ec9208d" />
+
+
+#### Captura 7:	La app en el navegador con todas las opciones visibles tras resolver el conflicto
+<img width="1056" height="676" alt="C7" src="https://github.com/user-attachments/assets/007f2f8e-c547-4341-92c2-14b6a8f2ec93" />
+
+
+<hr>
+
+# Tarea 6 — Limpieza y cierre del diario
+### Diario: Adjunta la captura 8 (git log --oneline). Cierra el diario con un párrafo libre: qué te ha resultado más difícil y qué tiene más sentido ahora que antes de la clase.
+
+#### Captura 8: Terminal con git log --oneline en main mostrando todos los commits            
+<img width="935" height="335" alt="C8" src="https://github.com/user-attachments/assets/20dc8fea-1ec1-417a-9384-f95b24252b23" />
+