Escenario: Dos usuarios colaboran en un repositorio GitHub

Repositorio GitHub compartido: https://github.com/usuario/proyecto-compartido
Usuarios: Usuario1 (crea el repositorio) y Usuario2 (Usuario1 lo añade como colaborador)

Paso 1: Clonar el repositorio

Usuario1 y Usuario2 clonan el repositorio desde GitHub usando VS Code y lo abren:

Paso 2: Crear una nueva rama para hacer cambios

Usuario1 crea una nueva rama llamada feature/usuario1 para trabajar en una nueva funcionalidad:
```
 git checkout -b feature/usuario1
```

Nota: una rama es una versión independiente del proyecto donde los desarrolladores pueden trabajar en nuevas funcionalidades sin afectar el código principal.

Usuario2 también crea una nueva rama llamada feature/usuario2 para sus propios cambios:
```
 git checkout -b feature/usuario2
```

Paso 3: Hacer cambios en el código

Usuario1 Crea el fichero archivo1.html le añade contenido y luego guarda los cambios.

Añade y confirma sus cambios:

 git add archivo1.html
 git commit -m "Añadir nueva funcionalidad por Usuario1"

Nota: El comando git add añade los cambios al área de preparación, y git commit guarda esos cambios con un mensaje descriptivo.

Envía la rama al repositorio remoto:
```
git push origin feature/usuario1
```
Nota: Push envía los cambios locales al repositorio en GitHub para que otros puedan verlos y trabajar con ellos.
Usuario2 Crea archivo1.html le añade contenido y guarda los cambios.

Añade y confirma sus cambios:

git add archivo1.html
git commit -m "Actualizar archivo2 por Usuario2"

Envía la rama al repositorio remoto:
```
git push origin feature-usuario2
```

Paso 4: Pull Requests en GitHub

Desde la web del repositorio Usuario1 abre un Pull Request (PR) para fusionar los cambios de feature/usuario1 a main:
- Va al repositorio en GitHub y selecciona la rama feature/usuario1.
- Abre un Pull Request con el título: “Añadir nueva funcionalidad por Usuario1”.
- Hace merge de la rama con main.
- En la web nos aparece la opción de eliminar la rama. Cómo no la necesitamos más la podemos eliminar.

Nota: Un Pull Request es una solicitud para que otros revisen los cambios hechos en una rama antes de fusionarlos con la rama principal (main).

Usuario2 hace lo mismo con su rama feature/usuario2:
- Abre otro Pull Request con el título: “Actualizar archivo1 por Usuario2”.

Paso 5: Revisar y resolver conflictos

Usuario1 fusiona su Pull Request después de que Usuario2 lo revisa y aprueba. Los cambios de feature-usuario1 ahora están en main.

Nota: Fusionar significa combinar los cambios de una rama con otra.

Usuario2 intenta fusionar su Pull Request, pero se encuentra con un conflicto porque el archivo archivo1.html también fue actualizado por Usuario1.

Nota: Un conflicto ocurre cuando dos ramas tienen cambios contradictorios en las mismas líneas de un archivo.

Usuario2 sincroniza su rama con la rama main que ya tiene los cambios de Usuario1:
```
   git checkout main
   git pull origin main
   git checkout feature/usuario2
   git merge main
```
Nota: Pull trae los cambios más recientes del repositorio remoto a la rama local para mantenerla actualizada. Y git merge main intenta combinar los cambios de la rama main en la rama actual.
VSCode muestra los conflictos en archivo1.html. Usuario2 los resuelve editando el archivo.

Después de resolver los conflictos, confirma los cambios:

git add archivo1.html
git commit -m "Resolver conflictos entre feature-usuario2 y main"

Envía la rama actualizada:
```
git push origin feature-usuario2
```

Paso 6: Fusionar la rama de Usuario2

Desde la web del repositorio en GitHub Usuario2 fusiona el Pull Request una vez que todos los conflictos se resuelven y el equipo lo aprueba. Ahora los cambios de ambas ramas están en main.
En la web nos aparece la opción de eliminar la rama. Cómo no la necesitamos más la podemos eliminar.

Paso 7: Actualizar las copias locales

Usuario1 y Usuario2 actualizan sus copias locales para reflejar los cambios más recientes:
```
git checkout main
git pull origin main
```
Esto asegura que ambos usuarios tengan la versión más actualizada del proyecto después de las fusiones.

Paso 8: Eliminar ramas locales

Cómo los usuarios no necesitan las ramas las pueden eliminar ejecutando.

Usuario1:
```
git branch -d feature/usuario1
```
Usuario2:
```
git branch -d feature/usuario2
```
Resumen
Usuario1 y Usuario2 clonaron el repositorio y crearon ramas separadas para trabajar en sus respectivas funcionalidades.
Ambos usuarios abrieron Pull Requests para fusionar sus cambios en main.
Usuario2 resolvió conflictos antes de poder fusionar su rama.
Finalmente, ambos usuarios actualizaron sus copias locales para tener los últimos cambios.

Esta simulación muestra un flujo básico de trabajo colaborativo en GitHub utilizando VS Code, permitiendo a los usuarios trabajar de forma organizada y evitar sobrescribir el trabajo del otro.

Anexo. Nombres de ramas en grupos de trabajo

Tipo de Rama	Convención de Nombres	Descripción	Ejemplos
Rama Principal	`main` o `master`	Rama principal y estable del proyecto; generalmente contiene código listo para producción.	`main`, `master`
Rama de Desarrollo	`develop`	Rama para la integración de nuevas características antes de fusionarlas en `main`.	`develop`
Rama de Características	`feature/nombre-de-la-caracteristica`	Utilizada para desarrollar nuevas funcionalidades.	`feature/login-page`, `feature/user-profile`
Rama de Corrección	`bugfix/nombre-del-bug`	Usada para corregir errores menores o problemas específicos.	`bugfix/fix-login-bug`, `bugfix/ui-alignment`
Rama de Soporte	`hotfix/nombre-del-hotfix`	Para aplicar correcciones urgentes y críticas en `main` o `master`.	`hotfix/security-patch`, `hotfix/critical-bug`
Rama de Pruebas	`release/nombre-de-la-version`	Preparación de nuevas versiones; pruebas finales antes de fusionar en `main`.	`release/v1.0.0`, `release/2.1.5`
Rama Experimental	`experiment/nombre-del-experimento`	Para pruebas rápidas o ideas no listas para producción.	`experiment/new-idea`, `experiment/test-feature`
Rama de Documentación	`docs/nombre-del-documento`	Para actualizaciones o mejoras en la documentación del proyecto.	`docs/api-update`, `docs/readme-enhancement`
Rama de Refactorización	`refactor/nombre-del-refactor`	Usada para reestructurar y mejorar el código o la organización de archivos sin cambiar su funcionalidad.	`refactor/project-structure`, `refactor/code-cleanup`