Control de versiones no es solo cosa de desarrolladores. Cuando modificas /etc/ssh/sshd_config a las 11 de la noche y el servicio deja de arrancar, lo que necesitas es exactamente lo mismo que un programador cuando introduce un bug: saber qué cambió, cuándo, y poder revertirlo. Git resuelve eso. Es un sistema de control de versiones distribuido que registra instantáneas (commits) del contenido de un directorio a lo largo del tiempo, junto con metadatos de autoría y mensaje explicativo.
El diseño de git gira en torno a tres zonas: el working tree (los archivos tal como están en disco), el índice o staging area (lo que has marcado para incluir en el próximo commit) y el repositorio (el historial comprimido dentro de .git/). Ese modelo de dos pasos —primero git add, luego git commit— no es burocracia: te permite construir commits atómicos y coherentes aunque hayas tocado diez archivos. En infraestructura eso importa porque un commit debe representar un cambio lógico completo (“habilitar TLS en nginx”), no una mezcla aleatoria de ediciones.
Úsalo en tres escenarios concretos: versionar /etc/ directamente (con o sin etckeeper), mantener playbooks de Ansible o configuraciones de Terraform, y documentar cambios de infraestructura con un historial auditable. Lo que se rompe si lo ignoras es sutil pero costoso: pierdes trazabilidad, no puedes comparar el estado actual con el de hace dos semanas, y los cambios coordinados entre varios administradores acaban en conflictos silenciosos o en el clásico “yo no toqué eso”.
# Instalar git si no está presente apt install git # Configuración mínima obligatoria: git rechaza hacer commits sin esto git config --global user.name "Ana Martínez" git config --global user.email "ana@infra.example.com" # Versionar /etc/ manualmente (alternativa ligera a etckeeper) # Trabajamos como root; ajusta según tu política de sudo cd /etc git init # crea /etc/.git/ git add ssh/sshd_config nginx/ # solo lo que quieres rastrear git commit -m "estado inicial: sshd y nginx antes de hardening" # Día siguiente: tocas sshd_config para deshabilitar PasswordAuthentication # Antes de continuar, verifica qué ha cambiado en disco respecto al último commit git diff ssh/sshd_config # Revisa qué archivos están modificados, nuevos o sin rastrear git status # Confirmas que el cambio es correcto; lo preparas y registras git add ssh/sshd_config git commit -m "sshd: deshabilitar PasswordAuthentication (solo clave)" # Ver el historial compacto — útil en terminales estrechas o logs de auditoría git log --oneline # Clonar un repositorio remoto (playbooks de Ansible en un servidor interno) git clone git@gitlab.infra.example.com:ops/ansible-playbooks.git cd ansible-playbooks # Traer cambios que otros han subido al repositorio remoto git pull # Después de editar un playbook, subir tus cambios git add site.yml roles/nginx/ git commit -m "nginx: añadir cabecera Strict-Transport-Security" git push
git diff sin argumentos compara el working tree contra el índice; si ya has hecho git add, usa git diff --cached para ver lo que está en staging respecto al último commit. Ese matiz evita la confusión de ejecutar diff y no ver nada porque ya habías preparado el archivo.
En el ejemplo, git add ssh/sshd_config nginx/ pasa una ruta de archivo y un directorio completo a la vez. Git acepta ambos: el directorio se añade recursivamente. En /etc/ conviene ser deliberado con lo que rastreas; añadir todo con git add . incluiría archivos con credenciales, sockets o entradas de dpkg que no quieres en el historial. Considera un .gitignore con entradas para *.dpkg-old, ssl/private/, o cualquier directorio que contenga secretos.
El mensaje de commit en "sshd: deshabilitar PasswordAuthentication (solo clave)" sigue el patrón componente: descripción imperativa. No es estilo, es funcionalidad: git log --oneline te da una línea por commit, y si esa línea es vaga (“cambios varios”) el historial pierde todo su valor como herramienta de diagnóstico.
git clone con URL SSH presupone que tienes una clave configurada en el servidor remoto. Si tu entorno usa HTTPS con tokens, la URL sería https://gitlab.infra.example.com/ops/ansible-playbooks.git y git pedirá credenciales (o las tomará del helper configurado). En Debian, git-credential-store o git-credential-cache son las opciones sin dependencias adicionales.
git pull es en realidad git fetch seguido de git merge. En repositorios de infraestructura compartidos con varios administradores, puede producir conflictos si dos personas han editado el mismo archivo. Cuando eso ocurre, git marca las zonas en conflicto directamente en el archivo con <<<<<<< / ======= / >>>>>>>. Editas manualmente para dejarlo como debe quedar, haces git add del archivo resuelto y luego git commit. No es complejo, pero hay que saber que el proceso tiene ese paso intermedio.
etckeeper automatiza parte de lo que hace el ejemplo manual: hace git init en /etc/, configura hooks de apt para commitear automáticamente antes y después de cada instalación de paquetes, y gestiona permisos de archivos sensibles que git normalmente ignora. Si vas a versionar /etc/ en producción de forma sistemática, etckeeper es la opción robusta; el ejemplo manual es útil para entender qué hace por debajo y para repositorios fuera de /etc/.
[Ubuntu]: En Ubuntu, etckeeper funciona igual. La diferencia es que los hooks de apt también capturan los cambios de snap, si lo usas.