# Manual de trabajo con ramas: SGMI

## 1. Estructura de ramas

- **dev-sgmi**: Rama de desarrollo. Aquí se hace todo el trabajo diario.
- **test-sgmi**: Rama de pruebas. Aquí solo se integran cambios listos para ser validados por el equipo funcional.
- **main**: Rama de producción. Solo recibe código probado y aprobado.

---

## 2. Flujo de trabajo recomendado

### a) Desarrollo de una nueva feature (Recomendado)

Para mantener el trabajo organizado y aislado, especialmente en cambios grandes, es una buena práctica crear una rama específica para cada nueva funcionalidad (*feature branch*).

1.  **Asegúrate de estar en la rama de desarrollo y que esté actualizada:**
    ```bash
    git checkout dev-sgmi
    git pull origin dev-sgmi # Si usas repositorio remoto
    ```

2.  **Crea y cambia a tu nueva rama de feature:**
    Usa un nombre descriptivo, por ejemplo, `feature/login-con-google`.
    ```bash
    git checkout -b feature/nombre-de-la-feature
    ```

3.  **Trabaja en tu feature:**
    Haz todos los cambios, commits y pruebas necesarios en esta rama.
    ```bash
    git add .
    git commit -m "feat: Agrega inicio de sesión con Google"
    ```

4.  **Crea la rama remota y sincroniza tus cambios:**
    En el primer push, crea la rama remota y configura el tracking:
    ```bash
    git push -u origin feature/nombre-de-la-feature
    ```
    Para commits posteriores, simplemente:
    ```bash
    git push
    ```

5.  **Cuando la feature esté completa, intégrala de vuelta a `dev-sgmi`:**
    1.  Vuelve a la rama de desarrollo y actualízala.
        ```bash
        git checkout dev-sgmi
        git pull origin dev-sgmi
        ```
    2.  Fusiona tu rama de feature.
        ```bash
        git merge feature/nombre-de-la-feature
        ```
    3.  Resuelve los conflictos si los hay.
    4.  Sincroniza los cambios fusionados con el repositorio remoto:
        ```bash
        git push origin dev-sgmi
        ```

6.  **Elimina la rama de feature una vez fusionada:**
    Elimina tanto la rama local como la remota:
    ```bash
    git branch -d feature/nombre-de-la-feature
    git push origin --delete feature/nombre-de-la-feature
    ```

### b) Desarrollo diario (para cambios menores)

1. Cambia a la rama de desarrollo:
   ```bash
   git checkout dev-sgmi
   ```
2. Haz tus cambios, agrega y commitea:
   ```bash
   git add .
   git commit -m "Descripción clara del cambio"
   ```
3. Sincroniza los cambios con el repositorio remoto:
   ```bash
   git push origin dev-sgmi
   ```

### c) Pasar cambios a pruebas

1. Cambia a la rama de pruebas:
   ```bash
   git checkout test-sgmi
   ```
2. Trae los cambios de desarrollo:
   ```bash
   git merge dev-sgmi
   ```
3. Si hay conflictos, resuélvelos (ver sección de ejemplos).
4. Haz push si usas repositorio remoto:
   ```bash
   git push origin test-sgmi
   ```

### d) Pasar cambios a producción

1. Cambia a la rama de producción:
   ```bash
   git checkout main
   ```
2. Trae los cambios aprobados:
   ```bash
   git merge test-sgmi
   ```
3. Haz push si usas repositorio remoto:
   ```bash
   git push origin main
   ```

---

## 3. Resolución de conflictos de merge

### ¿Qué es un conflicto?
Ocurre cuando Git no puede fusionar automáticamente los cambios de dos ramas porque se modificó la misma línea o bloque de código en ambas.

### ¿Cómo se ve un conflicto?
En el archivo afectado verás algo así:

```plaintext
<<<<<<< HEAD
Este es el contenido en tu rama actual (por ejemplo, test-sgmi)
=======
Este es el contenido que viene de la rama que intentas fusionar (por ejemplo, dev-sgmi)
>>>>>>> dev-sgmi
```

### Pasos para resolverlo

1. **Abre el archivo** que tiene el conflicto. Busca las marcas `<<<<<<<`, `=======`, `>>>>>>>`.
2. **Edita el archivo** para dejar solo la versión correcta (puedes combinar ambas partes si es necesario).
3. **Elimina** todas las marcas de conflicto.
4. **Guarda el archivo**.

#### Ejemplo práctico

Supón que tienes este conflicto en `app/ejemplo.php`:

```php
<<<<<<< HEAD
echo "Hola desde test-sgmi";
=======
echo "Hola desde dev-sgmi";
>>>>>>> dev-sgmi
```

Decides que la versión correcta es la de `dev-sgmi`, así que dejas:

```php
echo "Hola desde dev-sgmi";
```

O puedes combinar ambas si lo necesitas:

```php
echo "Hola desde test-sgmi y dev-sgmi";
```

5. **Marca el conflicto como resuelto**:

```bash
git add app/ejemplo.php
```

6. **Finaliza el merge**:

```bash
git commit
```

Si el merge ya tenía otros cambios listos, puede que el commit se haga automáticamente al hacer el `add`.

---

## 4. Consejos útiles

- Antes de hacer merge, asegúrate de tener tu rama actualizada:
  ```bash
  git pull
  ```
- Haz commits pequeños y descriptivos.
- Si tienes dudas, pregunta antes de resolver un conflicto.
- Siempre prueba la aplicación después de un merge.

---

## 5. Resumen visual del flujo

```mermaid
flowchart TD
    dev["dev-sgmi (Desarrollo)"]
    test["test-sgmi (Pruebas)"]
    main["main (Producción)"]

    dev -- "merge cuando está listo para pruebas" --> test
    test -- "merge cuando está aprobado" --> main
    subgraph Corrección de errores
        test -. "si hay bugs, corregir en dev-sgmi" .-> dev
    end
```

---

## 6. Flujo de trabajo recomendado (resumen)

### 1. **Desarrollo de nuevas features en ramas dedicadas**
- Para cada nueva funcionalidad o cambio importante, crea una rama a partir de `dev-sgmi` (ej: `feature/nuevo-login`).
- Trabaja en esa rama de forma aislada.
- Cuando la feature esté completa y probada, fusiónala de vuelta en `dev-sgmi`.
- Las correcciones menores o cambios rápidos se pueden hacer directamente en `dev-sgmi`.

### 2. **Preparar una versión para pruebas**
- Cuando consideres que una versión está lista para ser probada por el equipo funcional:
  1. Cambia a la rama `test-sgmi`:
     ```bash
     git checkout test-sgmi
     ```
  2. Trae los cambios de desarrollo:
     ```bash
     git merge dev-sgmi
     ```
  3. Resuelve cualquier conflicto, si los hay.
  4. El equipo funcional realiza pruebas en `test-sgmi`.

### 3. **Corrección de errores detectados en pruebas**
- Si se detectan errores, corrígelos en `dev-sgmi` (¡nunca directamente en `test-sgmi`!).
- Repite el proceso de merge cuando haya nuevas correcciones listas para probar.

### 4. **Liberar a producción**
- Cuando el equipo funcional apruebe los cambios en `test-sgmi`:
  1. Cambia a la rama `main`:
     ```bash
     git checkout main
     ```
  2. Trae los cambios validados:
     ```bash
     git merge test-sgmi
     ```
  3. Ahora `main` tiene solo código probado y listo para producción.

### 5. **Resumen visual del flujo**

```mermaid
flowchart TD
    dev["dev-sgmi (Desarrollo)"]
    test["test-sgmi (Pruebas)"]
    main["main (Producción)"]

    dev -- "merge cuando está listo para pruebas" --> test
    test -- "merge cuando está aprobado" --> main
    subgraph Corrección de errores
        test -. "si hay bugs, corregir en dev-sgmi" .-> dev
    end
```

---

## 7. Comandos clave para el flujo

- **Actualizar tu rama de pruebas con lo último de desarrollo:**
  ```bash
  git checkout test-sgmi
  git merge dev-sgmi
  ```

- **Actualizar producción con lo último aprobado en pruebas:**
  ```bash
  git checkout main
  git merge test-sgmi
  ```

- **Volver a desarrollo para seguir trabajando:**
  ```bash
  git checkout dev-sgmi
  ```

---

## 8. Consejos adicionales

- Nunca desarrolles directamente en `test-sgmi` ni en `main`.
- Haz commits claros y descriptivos.
- Antes de cada merge, asegúrate de que tu rama esté actualizada con respecto a la rama base.
- Si usas un repositorio remoto, recuerda hacer `git push` después de cada merge importante.