Hábitos profesionales con Git y GitHub: estándares, seguridad y errores típicos

Reglas prácticas para un historial sano (y fácil de mantener)

Un historial “sano” no es el más bonito: es el que reduce sorpresas, facilita revisiones y permite volver atrás sin romper el trabajo de otras personas. Estas reglas son hábitos operativos que puedes aplicar en cualquier equipo.

1) No forzar push en ramas compartidas

git push --force reescribe la historia del remoto. En una rama compartida (por ejemplo, main, develop o una rama de release), esto puede “borrar” commits de otras personas o dejar sus ramas colgando.

• Regla: solo usar force push en ramas personales y con acuerdo explícito.
• Preferencia: si de verdad necesitas forzar, usa --force-with-lease para evitar pisar trabajo ajeno.

# Más seguro que --force: falla si el remoto avanzó y tú no lo tienes localmente
git push --force-with-lease origin mi-rama

2) No rebasear commits ya publicados

Si ya publicaste commits (por ejemplo, ya están en el remoto y alguien podría basarse en ellos), reescribirlos con rebase crea historias divergentes y conflictos innecesarios al sincronizar.

• Regla: rebase solo en trabajo local o en ramas personales antes de abrir PR.
• En ramas compartidas: integra con merge o con la estrategia acordada por el equipo.

3) Evitar commits gigantes (y cómo partirlos)

Los commits enormes dificultan revisar, revertir y entender el “por qué”. Un buen commit suele representar una intención clara: “agrego validación”, “cambio contrato”, “corrijo bug X”.

• Regla: si un commit toca muchas áreas, probablemente son varios cambios mezclados.
• Práctica: prepara commits por partes usando staging selectivo.

# Ver cambios
git status

# Añadir por partes (interactivo)
git add -p

# Confirmar con un mensaje específico
git commit -m "Validar email en registro"

4) Usar ramas cortas (vida corta, propósito claro)

Ramas que viven semanas acumulan divergencia y aumentan el costo de integración. Mantén ramas pequeñas, enfocadas y con integración frecuente.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Regla: una rama = un objetivo (feature, fix, refactor acotado).
• Señal de alerta: si tu rama tiene demasiados commits “WIP” o cambia demasiados módulos, replanifica.

Pautas de seguridad con Git y GitHub (sin fricción)

La seguridad en repositorios suele fallar por hábitos: copiar un token en un archivo, subir un .env, o publicar un log con credenciales. Aquí tienes un enfoque práctico.

1) Evitar secretos en el repositorio (desde el primer día)

• Regla: ningún secreto (tokens, claves privadas, contraseñas) debe vivir en el repo, ni siquiera “por un momento”.
• Práctica: usa variables de entorno, gestores de secretos o secretos del proveedor CI/CD.
• Checklist antes de commit: revisa git diff buscando palabras típicas: token, secret, password, apikey, PRIVATE KEY.

# Revisión manual antes de confirmar
git diff

# Revisión de lo que realmente se va a commitear
git diff --staged

2) Si se filtra un secreto: rotación inmediata (y asumir compromiso)

Si un secreto se sube al repositorio, borrarlo en un commit posterior no lo “desfiltra”: el secreto queda en el historial y puede estar en clones, forks o caches.

• Acción 1: rota/revoca el secreto inmediatamente (genera uno nuevo y deshabilita el anterior).
• Acción 2: identifica el alcance (dónde se usaba, qué permisos tenía).
• Acción 3: limpia el historial solo si el equipo lo decide (es una operación delicada y coordinada).

3) Revisión antes de publicar (higiene de salida)

Antes de empujar al remoto o abrir un PR, aplica una rutina corta de verificación.

• Verifica: no hay secretos, no hay archivos generados, el cambio es el esperado, y el mensaje/estructura es revisable.
• Práctica: revisa el conjunto final con git status y git diff --staged.

git status
git diff --staged

Catálogo de errores típicos (y cómo prevenirlos)

Error 1: Commits en main por accidente

Ocurre cuando empiezas a trabajar sin crear rama, o cuando cambiaste de rama y no lo notaste.

Prevención:

• Configura protección de rama en GitHub (requerir PR, revisiones y checks).
• Antes de editar, confirma tu rama actual.
• Adopta el hábito: “crear rama primero, luego trabajar”.

# Ver rama actual
git branch --show-current

# Crear y cambiar a una rama nueva
git switch -c feature/descripcion-corta

Si ya hiciste commits en main localmente (sin publicar): mueve esos commits a una rama y deja main limpio (esto evita publicar directo). La mecánica exacta depende de tu caso, pero la idea es: crear rama desde el estado actual y luego devolver main al punto anterior.

Error 2: Conflictos recurrentes por archivos generados

Archivos compilados, bundles, artefactos, caches o lockfiles mal gestionados suelen causar conflictos repetitivos y ruido en PRs.

Prevención:

• No versionar artefactos generados salvo que el proyecto lo requiera explícitamente.
• Si un archivo se genera, define una única fuente de verdad (por ejemplo, el código fuente, no el resultado).
• Asegura que el equipo genera artefactos de forma reproducible (misma versión de herramientas).

Checklist:

• ¿Este archivo lo produce una herramienta? Si sí, probablemente no debe commitearse.
• ¿Cambia en cada máquina? Si sí, es candidato a excluirse.
• ¿Es necesario para ejecutar en producción? Si sí, considera pipeline de build en lugar de commit manual.

Error 3: Mensajes imprecisos (“fix”, “changes”, “update”)

Mensajes vagos rompen la trazabilidad: no sabes qué se cambió, por qué, ni qué impacto tiene. Esto afecta revisiones, debugging y auditoría.

Prevención:

• Describe intención + área afectada + contexto mínimo.
• Si aplica, referencia issue/PR.
• Evita mezclar cambios no relacionados en el mismo commit.

Error 4: Uso incorrecto de reset (pérdida de trabajo o historia confusa)

reset es potente y fácil de usar mal, especialmente si no distingues entre cambios locales y publicados. Un error típico es “arreglar” algo con reset y luego empujar, reescribiendo historia compartida.

Prevención:

• Antes de usar reset, confirma si tus commits ya están en el remoto.
• Si el objetivo es deshacer un cambio ya compartido, evita reescritura: usa una estrategia que no rompa a otros.
• Antes de operaciones destructivas, crea un punto de seguridad (por ejemplo, una rama temporal).

# Checkpoint de seguridad antes de experimentar
git switch -c backup/antes-de-reset

Flujos recomendados con checkpoints (cambio pequeño vs. cambio grande)

Estos flujos priorizan: ramas cortas, revisión antes de publicar, y checkpoints claros para detectar problemas temprano.

Flujo A: Cambio pequeño (1–3 commits, PR rápido)

1. Crear rama con nombre claro

   git switch -c fix/validacion-email

2. Checkpoint 1: confirmar estado limpio antes de empezar

   git status

3. Implementar el cambio

4. Checkpoint 2: revisar qué cambió (buscar secretos/ruido)

   git diff

5. Preparar commit pequeño (staging selectivo si hace falta)

   git add -p
   git diff --staged
   git commit -m "Validar formato de email en registro"

6. Checkpoint 3: ver historial local y coherencia

   git log --oneline -n 5

7. Publicar rama (sin force) y abrir PR

   git push -u origin fix/validacion-email

8. Checkpoint 4 (en PR): revisa archivos tocados, tamaño del PR, y que no haya artefactos generados

Flujo B: Cambio grande (varios días, múltiples commits, riesgo de conflictos)

1. Definir alcance y partir en entregables (por ejemplo: “infraestructura”, “cambio de API”, “migración”, “limpieza”).

2. Crear rama de trabajo

   git switch -c feature/nueva-integracion

3. Checkpoint 1: establecer reglas del cambio

   • ¿Qué carpetas/archivos no deben tocarse?
   • ¿Qué secretos o configuraciones deben ir fuera del repo?
   • ¿Qué artefactos generados deben evitarse?

4. Trabajar en commits por etapas (cada etapa con intención clara)

   git add -p
   git commit -m "Preparar cliente: estructura base y configuración"
   
   git add -p
   git commit -m "Implementar integración: endpoint X con manejo de errores"

5. Checkpoint 2: verificación frecuente antes de publicar

   • git diff --staged para confirmar que no hay secretos ni archivos generados.
   • git status para evitar arrastrar cambios no relacionados.

   git status
   git diff --staged

6. Checkpoint 3: sincronización cuidadosa

   • Evita reescribir historia si ya publicaste commits.
   • Integra cambios del remoto según la política del equipo (sin force push en ramas compartidas).

7. Publicar rama y abrir PR temprano (aunque sea “draft”) para recibir feedback y detectar problemas de integración.

   git push -u origin feature/nueva-integracion

8. Checkpoint 4 (en PR): dividir revisión por commits/etapas, verificar que el PR no incluye ruido (artefactos), y confirmar que el cambio es reversible por partes (si algo falla, puedes revertir una etapa sin deshacer todo).