|
| 1 | +# Guía de Contribución |
| 2 | + |
| 3 | +Gracias por tu interés en contribuir. Este documento describe el proceso y las convenciones del proyecto para mantener un flujo de trabajo ordenado y consistente. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Configuración del entorno |
| 8 | + |
| 9 | +```bash |
| 10 | +git clone https://github.com/WorkTeam01/team-practice.git |
| 11 | +cd team-practice |
| 12 | +pip install -r requirements.txt |
| 13 | + |
| 14 | +# Verificar que todo funciona |
| 15 | +pytest -v |
| 16 | +``` |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +## Flujo de trabajo |
| 21 | + |
| 22 | +Este proyecto sigue **Git Flow**. Todo el desarrollo ocurre en `dev`; `main` solo recibe merges de releases estables. |
| 23 | + |
| 24 | +### 1. Crear una rama desde `dev` |
| 25 | + |
| 26 | +```bash |
| 27 | +git checkout dev |
| 28 | +git pull origin dev |
| 29 | +git checkout -b <tipo>/nombre-descriptivo |
| 30 | +``` |
| 31 | + |
| 32 | +| Prefijo | Cuándo usarlo | |
| 33 | +| ------------ | ---------------------------------------- | |
| 34 | +| `feature/` | Nueva funcionalidad | |
| 35 | +| `bugfix/` | Corrección de un error | |
| 36 | +| `hotfix/` | Corrección urgente directamente en `main`| |
| 37 | +| `release/` | Preparación de una nueva versión | |
| 38 | + |
| 39 | +### 2. Desarrollar y hacer commits |
| 40 | + |
| 41 | +Sigue el formato de [Conventional Commits](https://www.conventionalcommits.org/): |
| 42 | + |
| 43 | +``` |
| 44 | +<tipo>: <descripción breve en imperativo> |
| 45 | +``` |
| 46 | + |
| 47 | +| Tipo | Cuándo usarlo | |
| 48 | +| ------------ | --------------------------------------------------- | |
| 49 | +| `feat` | Nueva funcionalidad | |
| 50 | +| `fix` | Corrección de bug | |
| 51 | +| `test` | Agregar o modificar tests | |
| 52 | +| `docs` | Cambios en documentación | |
| 53 | +| `refactor` | Cambios de código sin afectar comportamiento | |
| 54 | +| `style` | Formato, espaciado, nombres (sin cambios de lógica) | |
| 55 | +| `chore` | Tareas de mantenimiento, dependencias, CI | |
| 56 | + |
| 57 | +**Ejemplos:** |
| 58 | +``` |
| 59 | +feat: agregar función de historial de operaciones |
| 60 | +fix: corregir validación de paréntesis desbalanceados |
| 61 | +test: cubrir casos borde en abs_value con negativos |
| 62 | +``` |
| 63 | + |
| 64 | +### 3. Abrir un Pull Request |
| 65 | + |
| 66 | +- La rama destino siempre es `dev` (nunca directamente a `main`) |
| 67 | +- Usa la plantilla de PR del repositorio |
| 68 | +- Referencia el issue relacionado con `Closes #<número>` |
| 69 | +- Ejecuta los tests antes de hacer push: |
| 70 | + |
| 71 | +```bash |
| 72 | +pytest -v |
| 73 | +``` |
| 74 | + |
| 75 | +### 4. Code review |
| 76 | + |
| 77 | +- Todo PR requiere al menos una aprobación antes de mergear |
| 78 | +- Responde los comentarios y realiza los cambios solicitados |
| 79 | +- No hagas force push a una rama que ya tiene un PR abierto |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +## Reportar issues |
| 84 | + |
| 85 | +Usa las plantillas disponibles en GitHub según el caso: |
| 86 | + |
| 87 | +- **Reporte de error** — para bugs o comportamiento inesperado |
| 88 | +- **Mejora de función** — para proponer cambios en funcionalidad existente |
| 89 | +- **Nueva funcionalidad** — para proponer features nuevas |
| 90 | +- **Sugerencia general** — para ideas o discusiones abiertas |
| 91 | + |
| 92 | +--- |
| 93 | + |
| 94 | +## Estándares de código |
| 95 | + |
| 96 | +- **Estilo:** [PEP 8](https://pep8.org/) |
| 97 | +- **Docstrings:** [PEP 257](https://peps.python.org/pep-0257/) — todas las funciones públicas deben tenerlos |
| 98 | +- **Tests:** Toda nueva funcionalidad debe incluir tests en `tests/`. Los tests de GUI deben usar los mocks de `conftest.py` para ser ejecutables sin pantalla |
| 99 | + |
| 100 | +--- |
| 101 | + |
| 102 | +## Preguntas |
| 103 | + |
| 104 | +Si tienes dudas, abre un issue con la plantilla de **sugerencia general** o comenta directamente en el PR correspondiente. |
0 commit comments