Flujos de trabajo con Git
PrecauciónRamas y
main
Evita subir cambios grandes a main sin revisión cuando el equipo activo lo requiere; prefiere PR con contexto reproducible.
Ramas y commits
| Práctica | Motivo |
|---|---|
main estable |
Lo que un colaborador externo debería poder clonar y correr sin sorpresas inmediatas. |
Ramas por pregunta (feature/heat-definitions) |
Facilita revisiones atómicas y rollbacks puntuales. |
| Commits atómicos con mensaje imperativo breve | Historia legible para bisectar errores. |
Plantilla de mensaje de commit
Ámbito: acción en infinitivo (≤ 72 caracteres)
Cuerpo opcional: por qué (contexto científico o técnico)Pull requests (PR / merge requests)
- Descripción — pregunta de investigación o bug reproducible.
- Checklist —
READMEactualizado, rutas relativas, sin datos sensibles. - Revisor asignado — al menos una lectura cruzada cuando toca
Models/o export finales.
Colaboración externa
Los lineamientos indican que cualquiera puede hacer fork de repositorios públicos. Si planeas incorporar código externo:
- Documenta la procedencia y licencia en el
READMEy en comentarios mínimos en el script importado. - Prefiere integración vía PR pequeño antes que copiar archivos masivos sin atribución.
Entornos reproducibles (resumen)
| Contexto | Herramienta sugerida |
|---|---|
| R | renv + lockfile versionado |
| Python | requirements.txt o pyproject.toml + versiones fijadas |
| Mixto | documenta contenedor o entorno Conda solo si es estrictamente necesario para no sobrecargar onboarding |
Detalles de estilo de código —tidyverse cuando usemos R, revisiones— están en Estándares de código.