Mejores Prácticas de Git y GitHub
Un resumen condensado de las 25 prácticas más importantes de Git y GitHub para equipos de backend de Node.js - contenido portátil compartido; personalizable según las convenciones de cada organización.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas más importantes de Git y GitHub para equipos de backend de Node.js - contenido portátil compartido; personalizable según las convenciones de cada organización.
main es siempre la verdad de integración: Cada PR fusionado pasa CI; nunca dejes main roto de la noche a la mañana - las pipelines de producción asumen una punta verde (Fundamentos de Git para Equipos de Node).
Confirma el archivo de bloqueo: package-lock.json (o pnpm-lock.yaml) es requerido para un npm ci reproducible - nunca lo ignores en gitignore.
IDs de tickets en cada commit: feat(orders): refund endpoint [API-412] - los cherry-picks a release/* y hotfix/* dependen de mensajes rastreables.
Fusiona por squash las características a main: Un ticket, un commit en la rama de integración - simplifica el cherry-pick a las vías de release.
Ramas de características de corta duración: Apunta a 1-3 días; fusiona o rebasea main diariamente para evitar conflictos de migración y archivos de bloqueo.
Corta release/X.Y para trenes coordinados: API + worker + migración se envían juntos; las nuevas características solo llegan a main hasta la etiqueta.
La rama de release solo acepta correcciones de errores: Hazlo cumplir con la protección de ramas, no con recordatorios de Slack durante las ventanas de congelación.
Cherry-pick a release/*, nunca fusiones main en release/*: Fusionar arrastra características no verificadas al candidato de release.
Etiqueta desde release/* después de la aprobación de staging: v2.6.0 activa el CI de release; el mensaje de la etiqueta lista los elementos desplegables.
Fusiona release/* de vuelta a main después del despliegue: Preserva el límite del tren; elimina la rama de release cuando esté completa.
Ramas de hotfix desde etiquetas: git checkout -b hotfix/2.5.1 v2.5.0 - no desde main cuando está por delante de producción.
Retrocede cada hotfix: Cherry-pick el SHA de la corrección a main y abre release/* si aún está activa.
Nunca hagas force-push a ramas compartidas: El historial de main, release/*, hotfix/* es evidencia de auditoría.
Los hooks de pre-commit reflejan CI: Husky ejecuta typecheck, lint, test - igual que pr-checks.yml (Integración de GitHub Actions).
La plantilla de PR requiere nota de migración: Los cambios de esquema necesitan SQL de reversión o un plan de expansión-contracción.
La protección de ramas requiere la verificación de quality: La política supera al sistema de honor.
Nunca confirmes .env o secretos: Solo .env.example; producción mediante inyección de plataforma.
No confirmes dist/ o node_modules/: Los artefactos de construcción pertenecen a CI/CD, no a git.
Commits convencionales para la automatización del changelog: Combínalo con semantic-release si se adopta.
Creación de etiquetas restringida: Las etiquetas activan la producción - reglas o rol de gestor de release.
Monorepo: documenta la estrategia de etiquetas: Una etiqueta de monorepo vs etiquetas por servicio - elige una.
Cambios de esquema de Worker + API en un solo PR o PRs vinculados: La deriva del contrato de eventos rompe los flujos asíncronos.
Revisa los diffs del archivo de bloqueo en los PRs de dependencia: Los scripts postinstall inesperados son señales de alerta.
Documenta la reversión en el mensaje de la etiqueta de release: Resúmenes de imágenes, plan de reversión de migración, interruptor de apagado de características.
Rebase interactivo solo en feat/* privado: --force-with-lease antes de la revisión del PR; nunca en ramas compartidas.
Prefiere trunk (main) + release/* corto + hotfix/* para servicios de Node en etiquetas de contenedor. Un develop de larga duración diverge de los SHAs de producción.
main + ramas de características + fusión por squash + Husky + despliegue impulsado por etiquetas. Añade ramas de release cuando se una el QA de staging.
Las etiquetas activan las pipelines de release; los PRs activan las puertas de calidad; la protección de ramas conecta ambos. Consulta Mejores Prácticas de CI/CD.
Desplegar la punta de main a producción mientras la congelación de release/2.6.0 está en curso - usa etiquetas y vías de rama de forma consistente.
Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.
Revisado por Chris St. John·Última actualización: 16 jul 2026