Git para Redes Informáticas: Control de Versiones de tus Configuraciones Cisco

Como administrador de redes, probablemente ya hayas vivido esta pesadilla: una configuración de enrutador (router) modificada que provoca una avería, sin ningún modo de volver rápidamente a la versión anterior.

O peor aún, varios administradores modificando simultáneamente los mismos equipos sin coordinarse, creando conflictos difíciles de resolver. En estos casos, usar Git para redes informáticas puede marcar la diferencia: te permite restaurar la versión correcta, identificar los cambios y evitar errores de configuración.

La gestión tradicional de las configuraciones de red, basada en archivos de texto dispersos o copias de seguridad manuales, muestra rápidamente sus limitaciones. Ahí es donde entra en juego Git: un sistema de control de versiones de redes que te permite versionar, documentar y proteger tus configuraciones de forma profesional. Si quieres profundizar en sus fundamentos, Pro Git es el libro de referencia oficial, disponible gratis online.

Gracias al uso estratégico de cada comando de Git —desde git add hasta git commit, pasando por git push y git branch— puedes garantizar una trazabilidad completa de los cambios, una colaboración fluida entre administradores y una reversión instantánea en caso de incidente.

Esta guía completa cubre los comandos esenciales de Git para redes informáticas, desde el flujo de trabajo básico hasta las técnicas avanzadas, pasando por la gestión de ramas y la integración con herramientas de automatización de redes Cisco como Ansible o Terraform — parte fundamental del módulo de automatización de redes en el CCNA 200-301.

En el contexto del examen CCNA 200-301, el módulo de Automatización y Programabilidad —que representa el 10 % del examen según el temario oficial del CCNA 200-301— exige comprender cómo herramientas como Git forman parte de la Infraestructura como Código (IaC) en entornos modernos. Dominar Git ya no es opcional: es una competencia indispensable para cualquier profesional de redes.

¿Por qué usar Git para el control de versiones de tus configuraciones de red?

Git es un sistema de control de versiones distribuido que registra cada cambio en tus archivos de configuración, quién lo hizo y cuándo. Aplicado a redes informáticas, convierte el caos de las modificaciones manuales en un historial trazable, reversible y auditable.

Los retos de la gestión tradicional

El método clásico de gestión de configuraciones de red presenta numerosas fallas críticas. Las configuraciones suelen modificarse directamente en los equipos sin ningún tipo de trazabilidad, lo que hace imposible identificar quién hizo qué y cuándo. La ausencia de un historial estructurado impide cualquier retroceso fiable en caso de problema.

Cuando varios administradores trabajan en el mismo proyecto de red, la colaboración se convierte en un verdadero quebradero de cabeza: las modificaciones se sobrescriben entre sí, los conflictos entre versiones de archivos se multiplican y los errores de configuración pueden ser desastrosos. Sin un sistema de control de versiones, cada cambio representa un riesgo incontrolado para la estabilidad de la red.

Las ventajas de Git para redes informáticas

Trazabilidad completa

Git registra cada modificación en un historial trazable y detallado. Por defecto ese historial es estable, aunque operaciones avanzadas como rebase o reset --hard pueden modificarlo — razón por la que establecer protecciones de rama en producción es fundamental.

Cada commit contiene la identidad del autor, la fecha exacta y un mensaje descriptivo: ante cualquier auditoría o incidente, sabes exactamente quién cambió qué ACL y por qué.

Colaboración eficaz

El trabajo en equipo se vuelve fluido gracias al sistema de ramas de Git. Varios administradores pueden trabajar simultáneamente en diferentes partes de la red sin interferir entre sí.

La revisión del código antes de su aplicación permite detectar posibles errores antes de la puesta en producción. Las ramas de prueba ofrecen un entorno seguro para validar nuevas configuraciones sin poner en riesgo la infraestructura de producción.

Seguridad y resiliencia

La capacidad de reversión instantánea es un seguro de vida para tu infraestructura de red. En caso de una configuración incorrecta o una avería, volver a la versión estable anterior lleva unos segundos con un simple comando de Git.

La naturaleza distribuida de Git hace que cada clon del repositorio contenga el historial completo, lo que añade una capa de redundancia útil. Sin embargo, Git no es un sistema de backup: no reemplaza snapshots, copias offsite ni soluciones de recuperación ante desastres. Su valor real es la trazabilidad y el control de cambios, no la protección de datos en sentido estricto.

Automatización moderna

Git se integra perfectamente con herramientas de automatización de redes como Ansible o Python aplicado a redes informáticas. Terraform también entra en juego en entornos más orientados a infraestructura programable (cloud, ACI, NSX, APIs como Meraki), aunque su uso en redes tradicionales on-premise es menos frecuente.

Esta convergencia entre redes y código es lo que hoy se conoce como GitOps: el repositorio Git como única fuente de verdad del estado de la infraestructura, donde cualquier cambio en producción pasa obligatoriamente por un commit. Para entender cómo Cisco articula este principio a nivel metodológico, la guía de Cisco Network as Code sobre IaC en redes lo desarrolla en detalle.

Instalación y configuración inicial de Git

Instalación de Git

La instalación de Git varía según el sistema operativo. En distribuciones Linux Ubuntu o Debian, usa el gestor de paquetes APT:

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install git

Para sistemas CentOS o RHEL, usa YUM:

# CentOS/RHEL
sudo yum install git

En Windows, descarga Git for Windows desde el sitio oficial git-scm.com y sigue el asistente de instalación gráfico. En macOS, la instalación más sencilla es a través de Homebrew:

brew install git

Una vez instalado, comprueba la versión para confirmar que funciona correctamente:

git --version

Configuración inicial obligatoria

Antes de usarlo, Git requiere que configures tu identidad. Esta información aparecerá en cada commit que crees:

# Configurar tu identidad
git config --global user.name "Tu Nombre"
git config --global user.email "tu.email@empresa.com"

# Configurar el editor predeterminado
git config --global core.editor "vim"

# Comprobar la configuración
git config --list

El parámetro --global aplica estos ajustes a todos tus proyectos Git. Para una configuración específica de un solo proyecto, omite este parámetro y ejecuta el comando desde el directorio del repositorio en cuestión.

Configuración específica para administradores de red

Los administradores de red deben tomar precauciones adicionales para proteger los datos confidenciales:

# Ignorar archivos confidenciales (contraseñas, claves)
git config --global core.excludesfile ~/.gitignore_global

# Configurar el resaltado de color para mejor legibilidad
git config --global color.ui auto

A continuación, crea el archivo ~/.gitignore_global para excluir automáticamente los archivos que contengan contraseñas o claves de autenticación. Lo veremos en detalle en la sección dedicada al .gitignore para redes Cisco.

Comandos Git esenciales para redes informáticas

Antes de entrar en cada comando, aquí tienes el mapa completo de lo que cubre esta sección:

• git init — inicializar el repositorio
• git add / git commit — registrar cambios
• git status / git log — inspeccionar el estado e historial
• git branch / git switch / git merge — trabajar con ramas
• git push / git pull / git fetch — sincronizar con el repositorio remoto

git init — Crear un nuevo repositorio

El comando git init inicializa un nuevo repositorio Git en un directorio. Crea la estructura de datos necesaria para el control de versiones en una carpeta oculta .git:

# Crear una carpeta para tus configuraciones de red
mkdir configs-red
cd configs-red

# Inicializar el repositorio Git
git init

El mensaje “Initialized empty Git repository” confirma la creación del repositorio. El directorio .git contiene toda la base de datos de Git: historial de commits, configuración del proyecto, referencias a las ramas e índice de archivos.

Para una organización óptima, estructura tu repositorio desde el principio separando los tipos de equipos:

# Estructura recomendada para configuraciones de red Cisco
mkdir -p configs-red/{routers,switches,firewalls}
cd configs-red
git init

Esta estructura separa claramente los diferentes tipos de equipos, facilitando la navegación y la gestión de las configuraciones.

git add — Añadir archivos al control de versiones

El comando git add mueve los archivos modificados a la zona de preparación (staging area), preparando su inclusión en el próximo commit:

# Crear un archivo de configuración de ejemplo
echo "hostname ROUTER-01" > routers/router-01.conf

# Añadir al control de Git
git add routers/router-01.conf

Para añadir varios archivos a la vez:

# Añadir todos los archivos modificados
git add .

# Añadir todos los archivos de un directorio
git add routers/

El punto . representa el directorio actual y todos sus subdirectorios. Comprueba siempre con git status lo que estás añadiendo para evitar incluir archivos confidenciales.

git commit — Guardar los cambios

Un commit es una instantánea completa de tu proyecto en un momento dado. El comando git commit guarda de forma definitiva los cambios presentes en el área de preparación:

# Commit con mensaje descriptivo
git commit -m "Añadir configuración inicial ROUTER-01"

# Commit con mensaje detallado (abre el editor)
git commit

Buenas prácticas para los mensajes de commit en entornos de red:

# Formato recomendado: [TIPO] Descripción breve
# Tipos: ADD (añadir), UPDATE (modificar), FIX (corregir), DELETE (eliminar)

git commit -m "[ADD] Configuración VLAN 10 en SWITCH-CORE-01"
git commit -m "[FIX] ACL entrada ROUTER-EDGE: corrección regla 20"
git commit -m "[UPDATE] BGP neighbor 10.0.0.2 — añadir soft-reconfiguration"

Un buen mensaje responde a tres preguntas: qué se cambió, en qué equipo y por qué.

git status — Comprobar el estado del repositorio

El comando git status muestra el estado actual de tu directorio de trabajo y de la zona de preparación:

git status

Ejemplo de salida típica:

En la rama main
Cambios no preparados para la confirmación:
  modificados:   routers/router-01.conf

Archivos no controlados:
  switches/switch-01.conf

Este comando indica tres categorías: archivos modificados no añadidos (modified), archivos listos para ser confirmados (staged) y archivos no controlados por Git (untracked). Úsalo con frecuencia para mantener una visión clara de tu trabajo.

git log — Consultar el historial de cambios

El historial de confirmaciones se consulta con git log:

# Historial completo
git log

# Historial resumido (una línea por confirmación)
git log --oneline

# Historial gráfico con todas las ramas
git log --oneline --graph --all

# Ver los cambios de un commit específico
git show <commit-hash>

El formato --oneline ofrece una vista resumida especialmente útil para repositorios con muchos commits. La opción --graph visualiza la estructura de las ramas, esencial para comprender flujos de trabajo complejos en equipo.

Gestión de ramas para configuraciones de red

¿Por qué usar ramas en redes informáticas?

Las ramas son el núcleo del poder de Git. Cada rama representa una línea de desarrollo independiente, lo que te permite trabajar en varios cambios simultáneamente sin interferencias. En un contexto de red, las ramas tienen ventajas estratégicas claras:

• Rama main (o master): contiene únicamente las configuraciones de producción validadas y probadas, garantizando la estabilidad.
• Rama dev: entorno de desarrollo donde se prueban las nuevas configuraciones antes de su validación.
• Ramas de características (feature/…): creadas para probar modificaciones específicas como nuevas VLANs, ACLs o configuraciones de enrutamiento.
• Ramas por sitio: para gestionar configuraciones específicas de cada ubicación (site/madrid, site/barcelona).

Esta organización evita modificaciones directas en producción e instaura un flujo de validación riguroso.

git branch — Gestionar ramas

# Listar todas las ramas locales
git branch

# Crear una nueva rama
git branch feature-vlan-10

# Crear y cambiar a una nueva rama (forma clásica)
git checkout -b feature-acl-web

# Eliminar una rama local (solo si ya está fusionada)
git branch -d feature-vlan-10

# Eliminar una rama remota
git push origin --delete feature-vlan-10

La rama activa está marcada con un asterisco. La opción -d solo elimina ramas ya fusionadas, protegiéndote contra la pérdida accidental de trabajo. Para forzar la eliminación de una rama no fusionada, usa -D en mayúsculas, pero con precaución.

git switch / git restore — Cambiar de rama y restaurar archivos

Desde Git 2.23, git switch y git restore son los comandos recomendados. git checkout sigue funcionando pero se considera una sintaxis menos clara hoy en día, porque hacía demasiadas cosas a la vez: cambiar ramas, restaurar archivos, crear ramas… Para el CCNA y entornos modernos, interioriza directamente la sintaxis nueva:

# Cambiar de rama — forma moderna
git switch main

# Crear y cambiar — forma moderna
git switch -c feature-acl-web

# Restaurar un archivo al estado del último commit
git restore routers/router-01.conf

# git checkout sigue siendo válido pero evítalo en código nuevo
git checkout main       # equivalente a git switch main
git checkout -b dev     # equivalente a git switch -c dev

La opción -c (create) crea la nueva rama antes de cambiar a ella.

git merge — Fusionar ramas

La fusión de ramas integra los cambios de una rama en otra. Flujo de trabajo típico en redes:

# 1. Trabajas en una rama de características
git switch feature-vlan-10
# ... cambios en las configuraciones y commits ...

# 2. Cambiar a la rama de destino
git switch main

# 3. Fusionar la rama de características
git merge feature-vlan-10

# 4. Si no hay conflictos, enviar al repositorio remoto
git push origin main

Ejemplo concreto — añadir una nueva VLAN para el departamento de RRHH:

# Crear una rama de prueba
git switch -c test-vlan-20

# Modificar la configuración del conmutador (switch)
vim switches/switch-01.conf

# Añadir y confirmar los cambios
git add switches/switch-01.conf
git commit -m "[ADD] VLAN 20 para el departamento de RRHH"

# Tras la validación en entorno de prueba, fusionar en main
git switch main
git merge test-vlan-20

# Implementar en producción
git push origin main

Este flujo garantiza que cualquier modificación pase por una fase de prueba antes de su integración en producción.

Trabajar con repositorios remotos (GitHub, GitLab)

git clone — Clonar un repositorio existente

# Clonar desde GitHub
git clone https://github.com/tu-empresa/configs-red.git

# Clonar desde GitLab
git clone https://gitlab.com/tu-empresa/configs-red.git

# Clonar en un directorio específico
git clone https://github.com/tu-empresa/configs-red.git mi-carpeta

Este comando descarga todo el historial del proyecto, crea el directorio local y configura automáticamente el repositorio remoto con el nombre “origin”. Todos los miembros del equipo pueden así trabajar sobre la misma base de configuraciones.

git remote — Gestionar repositorios remotos

# Añadir un repositorio remoto
git remote add origin https://github.com/tu-empresa/configs-red.git

# Listar los repositorios remotos con sus URLs
git remote -v

# Modificar la URL de un repositorio remoto
git remote set-url origin https://nueva-url.git

# Eliminar un repositorio remoto
git remote remove origin

El nombre “origin” es la convención para designar el repositorio remoto principal. Puedes configurar varios repositorios remotos con nombres diferentes para flujos de trabajo complejos (copias de seguridad, réplicas, etc.).

git push — Enviar confirmaciones al repositorio remoto

# Enviar a la rama actual
git push origin main

# Enviar y crear la rama remota
git push -u origin feature-vlan-10

# Enviar todas las ramas locales
git push --all

# Forzar un envío (¡PELIGROSO — solo en último recurso!)
git push --force

La opción -u (o --set-upstream) configura la rama local para que siga automáticamente la rama remota. Los futuros git push y git pull ya no necesitarán especificar el destino.

Usa --force solo como último recurso y nunca en ramas compartidas. Si realmente necesitas forzar un push, la alternativa segura es --force-with-lease: verifica que nadie haya hecho push desde tu último fetch antes de sobreescribir, evitando pérdida de trabajo ajeno.

# Alternativa segura a --force
git push --force-with-lease origin feature-vlan-10

git pull — Recuperar los cambios remotos

# Pull desde la rama actual
git pull origin main

# Pull con rebase (historial más limpio)
git pull --rebase origin main

# Fetch + merge manual (enfoque en dos pasos)
git fetch origin
git merge origin/main

La opción --rebase vuelve a aplicar tus commits locales sobre los commits remotos, creando un historial lineal más legible. Este enfoque evita los commits de fusión superfluos en el historial.

git fetch — Recuperar sin fusionar

# Recuperar todas las ramas remotas
git fetch origin

# Ver las diferencias antes de fusionar
git diff main origin/main

# Fusionar manualmente si estás satisfecho
git merge origin/main

A diferencia de git pull, git fetch recupera los cambios sin fusionarlos automáticamente. Este enfoque en dos pasos te da más control: puedes inspeccionar los cambios remotos antes de integrarlos, reduciendo el riesgo de conflictos inesperados.

Comandos avanzados de Git para administradores de red

git diff — Comparar versiones de configuraciones

El comando git diff revela las diferencias entre distintas versiones de los archivos:

# Ver los cambios no marcados (no añadidos con git add)
git diff

# Ver los cambios marcados (añadidos con git add)
git diff --staged

# Comparar dos commits
git diff <commit1> <commit2>

# Comparar dos ramas
git diff main dev

# Ver los cambios de un archivo específico
git diff routers/router-01.conf

Ejemplos prácticos para configuraciones de red:

# Ver solo los cambios en los routers
git diff main dev -- routers/

# Comparar la configuración actual con la versión anterior
git diff HEAD~1 routers/router-01.conf

La notación HEAD~1 designa el commit anterior al último. HEAD~2 se remonta dos commits atrás, y así sucesivamente.

git stash — Guardar cambios temporalmente

El stash guarda temporalmente los cambios en curso sin crear un commit. Caso de uso típico: estás trabajando en una configuración pero debes cambiar de rama urgentemente para corregir un problema crítico en producción:

# Guardar los cambios actuales
git stash

# Listar todos los stashes guardados
git stash list

# Reaplicar el último stash (y eliminarlo)
git stash pop

# Reaplicar un stash específico sin eliminarlo
git stash apply stash@{0}

# Eliminar un stash
git stash drop stash@{0}

Si prefieres conservar el stash tras su aplicación, usa git stash apply en lugar de git stash pop. Cada stash está numerado, lo que te permite apilar varios cambios temporales.

git rebase — Reescribir el historial

El rebase vuelve a aplicar tus commits sobre otra base, creando un historial lineal más limpio:

# Rebase sobre main
git switch feature-vlan-10
git rebase main

# Rebase interactivo para modificar los últimos commits
git rebase -i HEAD~3

El rebase interactivo (-i) abre un editor que muestra los últimos commits. Puedes reordenarlos, fusionarlos, modificar sus mensajes o eliminarlos. Esta herramienta limpia el historial antes de compartir tu trabajo.

⚠️ Importante: nunca hagas rebase de commits ya enviados a una rama compartida. El rebase reescribe el historial, lo que provoca conflictos para todos los colaboradores que hayan basado su trabajo en los commits originales.

git reset — Deshacer commits

El comando git reset modifica el historial desplazando la rama actual a un commit anterior:

# Deshacer el último commit (conservar los cambios en staging)
git reset --soft HEAD~1

# Deshacer el último commit (conservar los cambios en el directorio)
git reset --mixed HEAD~1

# Deshacer el último commit (eliminar todos los cambios)
git reset --hard HEAD~1

# Volver a un commit específico
git reset --hard <commit-hash>

Los tres modos de reset ofrecen diferentes niveles de impacto:

• --soft: desplaza HEAD, conserva los archivos modificados en la zona de preparación.
• --mixed (por defecto): desplaza HEAD, conserva los archivos modificados pero los retira del staging.
• --hard: desplaza HEAD y elimina todas las modificaciones — retorno completo al commit objetivo.

Usa --hard con extrema precaución: las modificaciones perdidas son irrecuperables (salvo a través del reflog, técnica avanzada).

Resolución de conflictos en Git

¿Qué es un conflicto en Git?

Un conflicto surge cuando Git no puede fusionar automáticamente los cambios. Ocurre cuando dos personas modifican las mismas líneas de un archivo en ramas diferentes, o cuando un archivo se elimina en una rama pero se modifica en otra. Git marca las zonas conflictivas en el archivo y espera una resolución manual.

Ejemplo de conflicto en un archivo de configuración Cisco:

<<<<<<< HEAD
hostname ROUTER-01-MADRID
=======
hostname ROUTER-01-MAIN
>>>>>>> feature-rename

Los marcadores <<<<<<<, ======= y >>>>>>> delimitan las versiones en conflicto. La sección entre <<<<<<< HEAD y ======= muestra tu versión local actual. La sección entre ======= y >>>>>>> feature-rename muestra la versión de la rama a fusionar.

Cómo resolver un conflicto paso a paso

Paso 1 — Identificar el conflicto

Tras una fusión fallida, git status enumera los archivos en conflicto:

git merge feature-vlan-20
# CONFLICT (content): Conflicto de fusión en switches/switch-01.conf
git status

Paso 2 — Editar manualmente

Abre el archivo en conflicto con tu editor y elige la versión correcta. Puedes conservar una versión, la otra, o crear una fusión personalizada de ambas:

vim switches/switch-01.conf
# Elimina los marcadores de conflicto y ajusta el contenido

Paso 3 — Marcar como resuelto

git add switches/switch-01.conf

Paso 4 — Finalizar la fusión

git commit -m "[FIX] Resolución conflicto hostname ROUTER-01"

Herramientas para facilitar la resolución

Git puede ejecutar herramientas gráficas para resolver conflictos visualmente:

# Iniciar la herramienta de fusión configurada
git mergetool

Herramientas populares como kdiff3, meld o vimdiff muestran tres paneles: versión local, versión de base común y versión remota. También puedes cancelar completamente una fusión en curso si no estás listo para resolverla:

# Cancelar la fusión y volver al estado anterior
git merge --abort

# Ver solo los archivos en conflicto
git diff --name-only --diff-filter=U

Flujo de trabajo Git para equipos de red

Git Flow adaptado a configuraciones de red

Git Flow es una metodología de gestión de ramas que estructura el desarrollo colaborativo. Adaptada a las configuraciones de red, garantiza un proceso de validación riguroso:

# Estructura de ramas recomendada
main (producción)
├── dev (desarrollo y pruebas)
├── feature/vlan-dept-rrhh
├── feature/acl-servidor-web
├── hotfix/parche-seguridad-critico
└── site/madrid

Flujo de trabajo típico en 6 pasos:

1. Crear una rama feature: git switch -c feature/nueva-config
2. Desarrollar y confirmar: modificaciones + commits periódicos con mensajes descriptivos.
3. Subir al repositorio remoto: git push origin feature/nueva-config
4. Crear un Pull Request (GitHub) o Merge Request (GitLab): revisión por pares.
5. Fusionar en dev: pruebas en entorno de desarrollo.
6. Fusionar en main: implementación en producción tras la validación completa.

Este flujo en cascada garantiza que cada modificación pase por varios niveles de validación antes de llegar a producción, minimizando drásticamente el riesgo de incidentes.

¿Git Flow o GitHub Flow? Git Flow es ideal para equipos con ciclos de validación estrictos y múltiples entornos. Si tu pipeline CI/CD es ágil y el equipo es pequeño, considera GitHub Flow: una estructura más simple basada en main + ramas de feature + Pull Request directo a main. Menos overhead, igual de seguro con un buen CI.

Buenas prácticas para equipos de red

Mensajes de commit claros y estandarizados

# CORRECTO
git commit -m "[UPDATE] ACL IN en ROUTER-EDGE: bloqueo de red 192.168.50.0/24"

# INCORRECTO
git commit -m "modif config"

Commits atómicos

Cada commit debe representar una unidad lógica de cambio. No combines en un mismo commit la adición de una VLAN, la modificación de una ACL y la actualización de una configuración BGP. Estas acciones distintas merecen commits separados. Los commits atómicos simplifican las revisiones de código, los rollbacks selectivos y la comprensión del historial.

Ramas cortas y específicas

Crea ramas dedicadas a modificaciones concretas y fusiónelas rápidamente tras la validación. Una rama que se mantiene demasiado tiempo puede provocar conflictos importantes con otras ramas del equipo.

Revisión de código sistemática

Usa Pull Requests (GitHub) o Merge Requests (GitLab) para establecer una revisión obligatoria. Ningún cambio debe llegar a producción sin la validación de al menos otro administrador. Este enfoque detecta errores y fomenta el intercambio de conocimientos entre el equipo.

Documentación integrada en el repositorio

Mantén dos archivos esenciales en la raíz de tu repositorio:

• README.md: estructura del repositorio, convenciones de nomenclatura, instrucciones para contribuir.
• CHANGELOG.md: historial de los cambios importantes con fechas, impacto y motivos.

Integración de Git con la automatización de redes Cisco

.gitignore para entornos Cisco y Ansible

Antes de integrar Git con cualquier herramienta de automatización, necesitas un .gitignore bien configurado. En entornos de red, un archivo de credenciales expuesto en un repositorio público es un incidente de seguridad grave. Este es el .gitignore recomendado para proyectos Cisco + Ansible:

# ==========================
# .gitignore para redes Cisco + Ansible
# ==========================

# Credenciales y contraseñas
*.vault
vault_password_file
*password*
*secret*
*credentials*
.env

# Archivos de Ansible Vault
group_vars/all/vault.yml
host_vars/*/vault.yml

# Claves SSH y certificados
*.pem
*.key
id_rsa
id_rsa.pub
*.p12
*.pfx

# Backups locales de configuraciones (sin versionar)
*.bak
*.backup
*.old

# Archivos temporales de editores
*.swp
*.swo
*~
.DS_Store

# Logs
*.log
logs/

# Archivos de salida de Ansible
*.retry

# NOTA: Los archivos de inventario (inventory/) generalmente SÍ se versionan
# ya que contienen estructura, no credenciales.
# Lo que NO se versiona son las variables con credenciales:
# group_vars/all/vault.yml y host_vars/*/vault.yml (ya cubiertos arriba)
#
# Solo excluye inventarios si contienen credenciales en texto plano
# (mala práctica — usa Ansible Vault en su lugar)
# inventory/production.yml   ← descomenta solo si es necesario

Un error común es excluir los archivos de inventario del repositorio. En la mayoría de entornos, el inventario sí debe versionarse — contiene estructura (nombres de hosts, grupos, IPs), no credenciales. Lo que nunca debe estar en texto plano en Git son las contraseñas, y para eso existe Ansible Vault. La regla es simple: versiona la estructura, cifra los secretos.

⚠️ Pitfall frecuente antes de versionar: el show running-config de un dispositivo Cisco incluye líneas dinámicas como timestamps, contadores de sesión o el ntp clock-period.

Si las versionas tal cual, cada backup generará un diff ruidoso con cambios irrelevantes. Antes de hacer el commit, filtra o normaliza esas líneas — en el script Python puedes añadir una función de limpieza; en Ansible, un filtro regex_replace en la task de guardado.

Git + Ansible: cómo automatizar el backup de configuraciones Cisco

Esta es una de las aplicaciones más valiosas de Git en redes informáticas: automatizar el backup de las configuraciones de tus dispositivos Cisco y versionarlas en Git. Cada backup queda registrado en el historial con fecha, hora y dispositivo.

Ante cualquier incidente, sabes exactamente qué configuración tenía cada equipo en cada momento. Si prefieres una solución nativa de IOS sin scripts externos, te interesa conocer el enfoque de backup automático con tareas Kron en Cisco IOS como método complementario.

Primero, el playbook de Ansible que extrae el running-config de tus router y switch Cisco:

---
# playbooks/backup-cisco.yml
# Extrae y versiona el running-config de dispositivos Cisco IOS
# Uso: ansible-playbook -i inventory/production.yml playbooks/backup-cisco.yml

- name: Backup de configuraciones Cisco IOS
  hosts: cisco_devices
  gather_facts: false
  connection: network_cli

  vars:
    backup_dir: "backups/{{ inventory_hostname }}"
    backup_file: "{{ backup_dir }}/{{ inventory_hostname }}_{{ ansible_date_time.date }}.conf"

  tasks:

    - name: Crear directorio de backup por dispositivo
      file:
        path: "{{ backup_dir }}"
        state: directory
      delegate_to: localhost

    - name: Obtener running-config del dispositivo
      ios_command:
        commands: show running-config
      register: running_config

    - name: Guardar configuración en archivo local
      copy:
        content: "{{ running_config.stdout[0] }}"
        dest: "{{ backup_file }}"
      delegate_to: localhost

    - name: Verificar si hay cambios respecto al último backup
      command: git diff --quiet HEAD -- "{{ backup_dir }}/"
      register: git_diff_result
      ignore_errors: true
      delegate_to: localhost
      args:
        chdir: "{{ playbook_dir }}/.."

    - name: Añadir backups al staging de Git
      command: git add "{{ backup_dir }}/"
      delegate_to: localhost
      when: git_diff_result.rc != 0
      args:
        chdir: "{{ playbook_dir }}/.."

    - name: Commit con timestamp y nombre del dispositivo
      command: >
        git commit -m "[BACKUP] {{ inventory_hostname }} — {{ ansible_date_time.date }} {{ ansible_date_time.time }}"
      delegate_to: localhost
      when: git_diff_result.rc != 0
      args:
        chdir: "{{ playbook_dir }}/.."

    - name: Push al repositorio remoto
      command: git push origin main
      delegate_to: localhost
      when: git_diff_result.rc != 0
      args:
        chdir: "{{ playbook_dir }}/.."

El inventario de producción para este playbook tiene esta estructura:

# inventory/production.yml
all:
  children:
    cisco_devices:
      children:
        routers:
          hosts:
            ROUTER-EDGE-01:
              ansible_host: 192.168.1.1
              ansible_network_os: ios
              ansible_user: admin
              ansible_password: "{{ vault_cisco_password }}"
              ansible_become: true
              ansible_become_method: enable
              ansible_become_password: "{{ vault_enable_password }}"
            ROUTER-CORE-01:
              ansible_host: 192.168.1.2
              ansible_network_os: ios
              ansible_user: admin
              ansible_password: "{{ vault_cisco_password }}"
              ansible_become: true
              ansible_become_method: enable
              ansible_become_password: "{{ vault_enable_password }}"
        switches:
          hosts:
            SWITCH-CORE-01:
              ansible_host: 192.168.1.10
              ansible_network_os: ios
              ansible_user: admin
              ansible_password: "{{ vault_cisco_password }}"
              ansible_become: true
              ansible_become_method: enable
              ansible_become_password: "{{ vault_enable_password }}"

Las variables vault_cisco_password y vault_enable_password se almacenan en un archivo cifrado con Ansible Vault — nunca en texto plano en el repositorio.

Para programar este backup diario, añade una tarea cron en el servidor de automatización:

# Backup diario a las 02:00 AM
0 2 * * * cd /opt/configs-red && ansible-playbook -i inventory/production.yml playbooks/backup-cisco.yml --vault-password-file ~/.vault_pass >> logs/backup.log 2>&1

El resultado en Git es un historial limpio y trazable de todas tus configuraciones:

$ git log --oneline
a3f91c2 [BACKUP] SWITCH-CORE-01 — 2026-03-20 02:00:47
b82e4d1 [BACKUP] ROUTER-CORE-01 — 2026-03-20 02:00:31
c91a7f3 [BACKUP] ROUTER-EDGE-01 — 2026-03-20 02:00:12
d44b8e0 [UPDATE] ACL IN ROUTER-EDGE-01: bloqueo red 10.50.0.0/24
e13f2a9 [ADD] VLAN 30 Marketing en SWITCH-CORE-01

Git + CI/CD para la red: pipeline completo con GitLab CI

Un pipeline de CI/CD aplicado a redes informáticas convierte cada git push en un proceso de validación automático antes de cualquier despliegue.

El objetivo en entornos maduros es que ninguna configuración llegue a producción sin validación previa. En la práctica, muchos equipos de red todavía operan de forma semi-manual — este pipeline es el estándar al que apuntar, no necesariamente el punto de partida.

Si quieres ver cómo Cisco plantea esta metodología a nivel empresarial, la sesión BRKOPS-2142 de Cisco Live sobre automatización end-to-end con IaC cubre los beneficios de CI/CD y versionado en redes Cisco. Puedes implementarlo por etapas: primero solo validate, luego lint, y cuando el equipo esté listo, el despliegue automatizado.

Este es un .gitlab-ci.yml completo y funcional para un proyecto Git + Ansible de redes:

# .gitlab-ci.yml
# Pipeline CI/CD para despliegue de configuraciones de red con Ansible
# Etapas: validate → lint → test → deploy

stages:
  - validate
  - lint
  - test
  - deploy

variables:
  ANSIBLE_HOST_KEY_CHECKING: "False"
  ANSIBLE_FORCE_COLOR: "True"

default:
  image: cytopia/ansible:latest-tools

validate:syntax:
  stage: validate
  script:
    - echo "Validando sintaxis de playbooks Ansible..."
    - ansible-playbook --syntax-check -i inventory/dev.yml playbooks/backup-cisco.yml
    - ansible-playbook --syntax-check -i inventory/dev.yml playbooks/deploy-vlan.yml
    - ansible-playbook --syntax-check -i inventory/dev.yml playbooks/deploy-acl.yml
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_COMMIT_BRANCH == "dev"'

validate:yaml:
  stage: validate
  image: cytopia/yamllint
  script:
    - echo "Validando formato YAML..."
    - yamllint -c .yamllint playbooks/
    - yamllint -c .yamllint group_vars/
    - yamllint -c .yamllint inventory/dev.yml
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

lint:ansible:
  stage: lint
  script:
    - echo "Ejecutando ansible-lint..."
    - ansible-lint playbooks/
  allow_failure: false
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

test:deploy-dev:
  stage: test
  script:
    - echo "Desplegando en entorno de desarrollo..."
    - ansible-playbook -i inventory/dev.yml playbooks/deploy-vlan.yml
      --vault-password-file $VAULT_PASSWORD_FILE
      --diff
      --check
  environment:
    name: development
  rules:
    - if: '$CI_COMMIT_BRANCH == "dev"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

deploy:production:
  stage: deploy
  script:
    - echo "Desplegando en producción..."
    - ansible-playbook -i inventory/production.yml playbooks/deploy-vlan.yml
      --vault-password-file $VAULT_PASSWORD_FILE
      --diff
  environment:
    name: production
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  allow_failure: false

Puntos clave de este pipeline:

• La variable $VAULT_PASSWORD_FILE se configura como variable protegida en GitLab CI/CD Settings — nunca en el propio archivo.
• El flag --check en la etapa de test ejecuta el playbook en modo simulación, sin hacer cambios reales en los equipos.
• El flag --diff muestra exactamente qué líneas cambiarían en cada dispositivo, ideal para revisión antes del despliegue.
• El when: manual en producción exige que un administrador apruebe explícitamente el despliegue en la interfaz de GitLab — ningún push a main despliega solo.

El flujo completo queda así:

# Flujo completo Git + CI/CD para redes
#
# 1. Ingeniero crea rama y modifica playbook
git switch -c feature/vlan-40-finanzas
vim playbooks/deploy-vlan.yml
git add playbooks/deploy-vlan.yml
git commit -m "[ADD] VLAN 40 departamento Finanzas"
git push origin feature/vlan-40-finanzas

# 2. Se abre Merge Request en GitLab
#    → Pipeline arranca automáticamente:
#       ✅ validate:syntax  — sintaxis OK
#       ✅ validate:yaml    — formato YAML OK
#       ✅ lint:ansible     — buenas prácticas OK
#       ✅ test:deploy-dev  — simulación en lab OK

# 3. Otro administrador revisa y aprueba el MR
# 4. Se fusiona en main
git switch main
git merge feature/vlan-40-finanzas
git push origin main

# 5. Pipeline de main arranca:
#       ✅ validate + lint (de nuevo)
#       ⏸  deploy:production — ESPERANDO APROBACIÓN MANUAL

# 6. Administrador aprueba el despliegue en GitLab UI
#       ✅ deploy:production — VLAN 40 desplegada en producción

Script Python: backup automático de configs Cisco con Git

Si no usas Ansible en tu entorno, este script Python es una alternativa ligera que conecta directamente a tus dispositivos Cisco vía SSH (usando Netmiko), extrae el running-config y hace el commit a Git automáticamente. Es especialmente útil para entornos de laboratorio CCNA o infraestructuras pequeñas:

#!/usr/bin/env python3
"""
backup_cisco_git.py
Backup automático de running-config de dispositivos Cisco IOS
y versionado en Git con commit automático.

Dependencias: pip install netmiko gitpython
Uso: python3 backup_cisco_git.py
Nota: asegúrate de que el repositorio Git esté inicializado
      en REPO_PATH antes de ejecutar el script.
"""

import os
import datetime
from netmiko import ConnectHandler
from git import Repo

REPO_PATH = "/opt/configs-red"
BACKUP_DIR = os.path.join(REPO_PATH, "backups")
GIT_REMOTE = "origin"
GIT_BRANCH = "main"

DEVICES = [
    {
        "device_type": "cisco_ios",
        "host": "192.168.1.1",
        "username": os.environ.get("CISCO_USER"),
        "password": os.environ.get("CISCO_PASS"),
        "secret": os.environ.get("CISCO_ENABLE"),
        "port": 22,
        "hostname": "ROUTER-EDGE-01",
    },
    {
        "device_type": "cisco_ios",
        "host": "192.168.1.10",
        "username": os.environ.get("CISCO_USER"),
        "password": os.environ.get("CISCO_PASS"),
        "secret": os.environ.get("CISCO_ENABLE"),
        "port": 22,
        "hostname": "SWITCH-CORE-01",
    },
]

def conectar_y_extraer(device: dict) -> str:
    """Conecta al dispositivo y extrae el running-config."""
    print(f"  → Conectando a {device['hostname']} ({device['host']})...")
    connection = ConnectHandler(**{k: v for k, v in device.items() if k != "hostname"})
    connection.enable()
    config = connection.send_command("show running-config")
    connection.disconnect()
    return config

def guardar_config(hostname: str, config: str) -> str:
    """Guarda la configuración en archivo local. Devuelve la ruta del archivo."""
    device_dir = os.path.join(BACKUP_DIR, hostname)
    os.makedirs(device_dir, exist_ok=True)
    fecha = datetime.datetime.now().strftime("%Y-%m-%d")
    filepath = os.path.join(device_dir, f"{hostname}_{fecha}.conf")
    with open(filepath, "w") as f:
        f.write(config)
    print(f"  ✓ Config guardada: {filepath}")
    return filepath

def commit_git(repo: Repo, archivos_modificados: list, timestamp: str):
    """Añade los archivos modificados y hace commit en Git."""
    if not archivos_modificados:
        print("\n✓ Sin cambios respecto al último backup. No se crea commit.")
        return
    repo.index.add(archivos_modificados)
    mensaje = f"[BACKUP] Configs automáticas — {timestamp}"
    repo.index.commit(mensaje)
    print(f"\n✓ Commit creado: {mensaje}")
    origin = repo.remote(name=GIT_REMOTE)
    origin.push(refspec=f"{GIT_BRANCH}:{GIT_BRANCH}")
    print(f"✓ Push realizado a {GIT_REMOTE}/{GIT_BRANCH}")

def main():
    timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M")
    print(f"\n{'='*50}")
    print(f"BACKUP CISCO GIT — {timestamp}")
    print(f"{'='*50}\n")
    repo = Repo(REPO_PATH)
    archivos_modificados = []
    for device in DEVICES:
        try:
            config = conectar_y_extraer(device)
            filepath = guardar_config(device["hostname"], config)
            rel_path = os.path.relpath(filepath, REPO_PATH)
            changed = [item.a_path for item in repo.index.diff(None)]
            if rel_path in changed or rel_path in repo.untracked_files:
                archivos_modificados.append(rel_path)
                print(f"  ✓ Cambios detectados en {device['hostname']}")
            else:
                print(f"  — Sin cambios en {device['hostname']}")
        except Exception as e:
            print(f"  ✗ ERROR en {device['hostname']}: {e}")
            continue
    commit_git(repo, archivos_modificados, timestamp)
    print(f"\n{'='*50}")
    print("Backup completado.")
    print(f"{'='*50}\n")

if __name__ == "__main__":
    main()

Para ejecutarlo, las credenciales se pasan como variables de entorno — nunca hardcodeadas en el script:

export CISCO_USER="admin"
export CISCO_PASS="tu_password"
export CISCO_ENABLE="tu_enable_secret"

python3 backup_cisco_git.py

El script detecta automáticamente si ha habido cambios en la configuración respecto al último backup guardado en Git. Si no hay cambios, no crea ningún commit, manteniendo el historial limpio y significativo.

Lo que has aprendido — y el siguiente paso

Usar Git para redes informáticas es hoy una competencia indispensable para cualquier profesional de redes moderno, y especialmente para quienes se preparan para el CCNA 200-301.

En un ecosistema IT donde la Infraestructura como Código y las metodologías DevOps se imponen como estándar, saber versionar eficazmente tus configuraciones de red ya no es opcional: es una necesidad profesional.

Los comandos que hemos explorado — desde git init para iniciar un proyecto hasta git merge para integrar cambios en equipo — constituyen tu caja de herramientas diaria como administrador de redes.

La gestión de ramas te permite probar cambios en aislamiento antes de su implementación en producción, eliminando errores catastróficos. Las herramientas avanzadas como git diff, git stash y git rebase refinan tu control y optimizan tu productividad.

Pero aquí está la clave: la integración de Git con herramientas como Ansible y los pipelines de CI/CD es donde esta guía pasa de ser teoría a ser práctica real. Cada commit desencadena validaciones automáticas, los rollbacks se ejecutan en segundos y el historial completo de tu infraestructura permanece accesible en todo momento.

Esta filosofía — el repositorio Git como única fuente de verdad — es la base del GitOps moderno, un estándar que cada vez más empresas adoptan en sus equipos de red.

Empieza hoy mismo: inicializa un repositorio Git en tu entorno de laboratorio para el CCNA, aplica las convenciones de commit que hemos visto y experimenta con el flujo de ramas. Es la mejor forma de interiorizar estos conceptos antes del examen — y de aplicarlos desde el primer día en producción.

Preguntas frecuentes sobre Git para redes informáticas

¿Cuáles son los comandos Git esenciales para redes?

Los comandos fundamentales para gestionar configuraciones de red con Git son: git init para crear un repositorio, git add para añadir archivos al área de preparación, git commit para guardar los cambios con un mensaje descriptivo, git push y git pull para sincronizar con un repositorio remoto, git status para comprobar el estado del proyecto y git log para consultar el historial completo de cambios. Juntos, estos comandos te permiten seguir, documentar y compartir eficazmente las configuraciones de tus equipos Cisco.

¿Cómo crear un nuevo repositorio Git para configuraciones de red?

Para crear un repositorio, dirígete a la carpeta del proyecto y ejecuta:

git init

Esto inicializa un nuevo repositorio local. A continuación, vincúlalo a un repositorio remoto (GitHub o GitLab) con:

git remote add origin https://github.com/tu-empresa/configs-red.git

Y envía tu primer commit con:

git push -u origin main

Para entornos de red, se recomienda crear una estructura de directorios separando routers, switches y firewalls antes de inicializar el repositorio.

¿Cómo usar ramas de Git para gestionar configuraciones de red?

Git te permite trabajar en varias versiones de tus configuraciones sin interferir con la rama principal de producción.

Los pasos básicos son: crear una rama con git branch nombre-rama, cambiar a ella con git switch nombre-rama, realizar tus cambios y commits, y fusionarla en main tras la validación con git merge nombre-rama.

Las ramas son especialmente útiles para probar nuevas VLANs, ACLs o cambios de enrutamiento en un entorno de prueba antes de implementarlos en producción.

¿Cómo ver los cambios en las configuraciones de red con Git?

Para visualizar los cambios en tus configuraciones, tienes tres comandos principales: git status para ver qué archivos han sido modificados, git diff para mostrar exactamente qué líneas han cambiado (muy útil para comparar versiones de archivos de configuración Cisco), y git log --oneline para consultar el historial completo de commits de forma resumida.

Puedes también usar git diff HEAD~1 routers/router-01.conf para comparar la versión actual de un archivo con la versión del commit anterior.

¿Cómo configurar Git para un entorno de red?

Antes de usar Git, configura tu identidad con git config --global user.name "Tu Nombre" y git config --global user.email "tu.email@empresa.com".

Para entornos de red es imprescindible añadir un archivo .gitignore que excluya los archivos confidenciales: contraseñas de enable secret, claves SSH, tokens de API de Cisco DNA Center y archivos de credenciales de Ansible Vault. Esta precaución evita que información sensible quede expuesta en el repositorio remoto.

¿Cómo resolver conflictos de Git en configuraciones de red?

Un conflicto surge cuando dos administradores modifican las mismas líneas de un archivo de configuración en ramas diferentes. Git marca las zonas en conflicto con los marcadores <<<<<<<, ======= y >>>>>>>.

Para resolverlo: abre el archivo con tu editor, elige la versión correcta eliminando los marcadores, ejecuta git add nombre-archivo para marcarlo como resuelto y finaliza con git commit. Si no estás listo para resolver los conflictos de inmediato, usa git merge --abort para cancelar la fusión y volver al estado anterior.

¿Cómo usar Git con GitHub o GitLab para equipos de red?

GitHub y GitLab funcionan como repositorios remotos centralizados para tus configuraciones de red.

Tras crear un repositorio en la plataforma elegida, vincúlalo a tu proyecto local con git remote add origin URL-del-repositorio. Usa git push para subir tus cambios y git pull para sincronizar los cambios de tus compañeros.

Para equipos de red, GitLab es especialmente recomendable por su integración nativa con pipelines CI/CD, lo que permite automatizar la validación y el despliegue de configuraciones cada vez que se hace un push a la rama main.

¿Cuáles son las mejores prácticas de Git para administradores de red?

Las mejores prácticas de Git para entornos de red son: realizar commits frecuentes y con mensajes descriptivos usando el formato [TIPO] Descripción (por ejemplo, [ADD] VLAN 10 en SWITCH-CORE-01), trabajar siempre en ramas separadas antes de fusionar en main, ejecutar git pull antes de empezar cualquier sesión de trabajo para evitar conflictos, usar un archivo .gitignore bien configurado para proteger los datos confidenciales, y establecer un proceso de revisión de código mediante Pull Requests antes de cualquier despliegue en producción.

Estas prácticas garantizan un flujo de trabajo limpio, trazable y profesional alineado con los estándares NetDevOps actuales.