Colaboración

GitSCase está diseñado para que múltiples desarrolladores trabajen en el mismo proyecto de ScriptCase sin pisarse los cambios.

Cómo funciona la colaboración

Desarrollador A hace cambios

1. Trabaja en ScriptCase
2. GitSCase detecta los cambios
3. Hace commit en GitSCase
4. Hace commit + push en GitHub Desktop

Desarrollador B recibe cambios

1. Hace pull en GitHub Desktop
2. Abre GitSCase Desktop
3. Usa Detección para ver los cambios
4. Aplica los cambios en su ScriptCase

Resultado: Ambos tienen el mismo código.

Setup inicial del equipo

1. Líder crea el repositorio

El líder del equipo (o el primero en configurar):

1. Vincula el proyecto en GitSCase
2. Hace la primera detección
3. Hace commit de todo
4. Crea un repositorio en GitHub
5. Publica el repositorio

En GitHub Desktop:

1. File → Add local repository
2. Selecciona la carpeta del proyecto
3. Create repository
4. Commit to main
5. Publish repository
6. Marca como Privado (importante para proyectos de trabajo)

2. Equipo clona el repositorio

Los demás desarrolladores:

1. Clonan el repositorio con GitHub Desktop
2. Abren GitSCase Desktop
3. Abren el proyecto en ScriptCase (para que GitSCase lo detecte)
4. Vinculan el proyecto a la carpeta clonada

En GitHub Desktop:

1. File → Clone repository
2. Selecciona el repositorio del equipo
3. Elige carpeta local
4. Clone

En GitSCase:

1. Abre ScriptCase desde GitSCase
2. Abre el proyecto en ScriptCase
3. GitSCase lo detectará
4. Configura la carpeta → Selecciona la carpeta que clonaste

Rutina diaria

Al empezar el día

1. Abre GitHub Desktop
2. Fetch origin
3. Pull origin (si hay cambios)
4. Abre GitSCase Desktop
5. Detecta y aplica cambios
6. Refresca ScriptCase
7. Empieza a trabajar

Al terminar el día

1. Commitea en GitSCase Desktop
2. Abre GitHub Desktop
3. Revisa los cambios
4. Escribe mensaje de commit
5. Commit to main
6. Push origin

Conflictos

¿Qué es un conflicto?

Un conflicto ocurre cuando dos personas modifican el mismo archivo en las mismas líneas.

Ejemplo:

• Tú cambias la línea 10 de onExecute.php
• Tu compañero también cambia la línea 10 del mismo archivo
• Ambos hacen push
• Git no sabe cuál cambio mantener

Detectar conflictos

GitHub Desktop te avisará al hacer pull:

⚠️ Conflictos detectados
Los siguientes archivos tienen conflictos:
- root/Admin/form_usuarios/events/onExecute.php

Resolver conflictos

1. Abre el archivo en tu editor de código (VS Code, Notepad++, etc.)
2. Busca las marcas de conflicto:

<<<<<<< HEAD
// Tu código
sc_lookup(ds, "SELECT * FROM usuarios WHERE id = {id}");
=======
// Código del compañero
sc_select(ds, "SELECT * FROM usuarios WHERE user_id = {id}");
>>>>>>> main

1. Decide qué código mantener (o combina ambos):

// Código final (después de resolver)
sc_lookup(ds, "SELECT * FROM usuarios WHERE id = {id}");

1. Elimina las marcas de conflicto (<<<<<<<, =======, >>>>>>>)
2. Guarda el archivo
3. En GitHub Desktop, haz commit del merge

Aplicar el código resuelto

Después de resolver en Git:

1. Abre GitSCase Desktop
2. Detecta cambios
3. Aplica el archivo resuelto en ScriptCase

Estrategias para evitar conflictos

1. Dividir el trabajo

Asigna diferentes módulos o aplicaciones a cada desarrollador:

✅ Buena división:
- Dev A: Módulo de usuarios
- Dev B: Módulo de reportes
- Dev C: Módulo de configuración

❌ Mala división:
- Todos trabajando en el mismo formulario

2. Comunicación constante

Usa un canal de comunicación (Slack, Teams, WhatsApp):

💬 "Voy a modificar form_usuarios"
💬 "Terminé con grid_ventas, ya hice push"
💬 "¿Alguien está trabajando en el módulo de reportes?"

3. Commits frecuentes

Haz commits pequeños y frecuentes:

✅ Bueno:
- Commit cada 1-2 horas
- Commits pequeños y específicos
- Push al menos 2 veces al día

❌ Malo:
- Commit al final del día con 50 archivos
- Acumular cambios por días

4. Pull antes de push

Siempre haz pull antes de push:

1. Fetch origin
2. Pull origin
3. Resolver conflictos (si hay)
4. Push origin

Esto detecta conflictos temprano.

Ramas (branches)

Para proyectos grandes o features complejas, usa ramas:

Crear rama

En GitHub Desktop:
1. Branch → New branch
2. Nombre: feature/nuevo-modulo-ventas
3. Create branch

Trabajar en la rama

1. Haz cambios en ScriptCase
2. Commitea en GitSCase
3. Push a la rama en GitHub Desktop

Merge a main

Cuando termines:

1. Branch → Create pull request
2. Revisa los cambios en GitHub.com
3. Merge pull request
4. Otros devs hacen pull de main

Buenas prácticas

✅ Hacer

• Commitea frecuentemente (cada 1-2 horas)
• Haz pull al menos 2 veces al día
• Usa mensajes de commit descriptivos
• Comunica qué estás modificando
• Revisa el diff antes de commitear
• Resuelve conflictos apenas aparezcan

❌ Evitar

• Acumular cambios por días
• Hacer push sin hacer pull primero
• Trabajar en el mismo archivo sin coordinarse
• Usar mensajes de commit vagos ("fix", "cambios")
• Ignorar conflictos

Ejemplo real de flujo

Lunes 9:00 AM:

Dev A:
1. Abre GitHub Desktop → Pull
2. Abre GitSCase → Detecta cambios → Aplica
3. Refresca ScriptCase
4. Empieza a trabajar en form_usuarios

Lunes 11:00 AM:

Dev A:
1. Termina cambios en form_usuarios
2. GitSCase → Commit
3. GitHub Desktop → Commit + Push
4. Avisa en el chat: "Terminé form_usuarios, ya hice push"

Lunes 11:05 AM:

Dev B:
1. Ve el mensaje en el chat
2. GitHub Desktop → Pull
3. GitSCase → Detecta cambios → Aplica
4. Refresca ScriptCase
5. Ahora tiene los cambios de Dev A

Próximos pasos

• Commit — Guarda tus cambios
• Detección — Recibe cambios de otros
• Estructura del repositorio — Entiende cómo se organizan los archivos