Skip to main content

Seguridad en la colaboración: cómo protege Git el trabajo en equipo

Llegados a este punto, ya sabes colaborar con Git sin plataformas externas. Has visto que compartir historia es posible, que existe un punto común de intercambio y que cada persona trabaja con su copia completa del proyecto. Pero cuando aparece el trabajo en equipo, surge una preocupación legítima:

¿Es seguro trabajar así?​

Compartir código no es solo una cuestión técnica. Es una cuestión de confianza, control y responsabilidad. Git no elimina la necesidad de seguridad; se apoya en ella.

Git no gestiona usuarios, gestiona historia​

Git no tiene cuentas, ni contraseñas, ni perfiles. No decide quién puede trabajar ni quién no. Su función es otra: registrar cambios de forma fiable. La seguridad no está dentro de Git. Está alrededor de Git.

Cuando colaboras con Git sin GitHub, la protección del proyecto depende del entorno que rodea al repositorio remoto.

Las tres capas reales de seguridad en Git​

En cualquier colaboración con Git sin plataformas externas intervienen tres capas claras:

  • El sistema operativo donde vive el repositorio remoto.
  • El método de acceso a ese sistema (red, permisos, SSH).
  • Las normas de trabajo acordadas por el equipo.

Git se apoya en esas capas. No puede saltárselas ni reforzarlas por sí solo.

Si una de estas capas es débil, Git funciona, pero el entorno no es seguro.

Seguridad básica: permisos del sistema de archivos​

En el modelo más simple —una carpeta compartida en red— la seguridad es exactamente la misma que la del sistema de archivos.

  • Quien puede leer la carpeta puede clonar.
  • Quien puede escribir en la carpeta puede hacer push.

Ejemplo real:

En una red local con un NAS, solo ciertos usuarios tienen permisos de escritura sobre la carpeta repos/.

Git no añade privilegios. Hereda los permisos existentes. Esto es simple, pero limitado: no hay identidad fuerte ni cifrado del tráfico.

SSH: cuando la seguridad deja de ser implícita​

El salto importante ocurre cuando el repositorio remoto se accede por SSH.

Aquí no se confía en “estar en la red correcta”. Se confía en identidades criptográficas.

El modelo real es este:

  • Cada desarrollador tiene una clave privada en su equipo.
  • El servidor guarda solo claves públicas autorizadas.
  • El acceso se concede por identidad, no por ubicación.

Si no tienes una clave válida, no hay acceso. No importa que conozcas la dirección del servidor.

Qué protege realmente SSH en un flujo Git​

Cuando usas Git sobre SSH, se protegen tres aspectos críticos:

  • Quién accede al repositorio.
  • Qué puede hacer (leer, escribir).
  • Qué viaja por la red (todo va cifrado).

Los commits, los mensajes y los archivos no circulan en claro. Esto es exactamente el mismo principio que usan las plataformas profesionales por debajo.

El papel del repositorio bare en la seguridad​

El uso de repositorios bare no es solo una cuestión técnica. Es una medida de seguridad funcional.

Un repositorio bare:

  • No contiene archivos editables.
  • No se abre con editores.
  • No permite “arreglos rápidos” manuales.

Esto reduce errores humanos y evita modificaciones directas fuera del control de Git.

Cuando la red está mal configurada​

Git no puede compensar una red insegura.

Si el servidor:

  • Usa usuarios compartidos.
  • Tiene puertos abiertos sin control.
  • No separa permisos.

Entonces Git sigue funcionando, pero el riesgo no está en Git, sino en la infraestructura. Git no sustituye a una buena configuración del sistema. Solo trabaja de forma segura cuando el entorno lo es.

Seguridad técnica vs seguridad humana​

Git protege el trabajo, pero no decide por las personas.

Git puede:

  • Registrar quién hizo qué.
  • Evitar pérdidas de datos.
  • Detectar conflictos.

Git no puede:

  • Validar decisiones.
  • Revisar calidad.
  • Evitar malas prácticas.

Por eso incluso sin GitHub, los equipos establecen normas simples: cuándo se publica, quién revisa, cómo se corrige. Git facilita el control, pero no impone disciplina.