Git para No-Programadores: El fin del archivo 'Final_Final_v3.docx'

Hace poco me embarqué en una misión suicida: unificar y estandarizar toda la documentación operativa de la empresa. Desde el Procedimiento de rendiciones de gastos hasta el Reglamento Interno.

Creé un sistema de codificación robusto (XT-PR-SGI-01, XT-FM-SGI-02), definí dueños de procesos y fechas de revisión. Para controlarlo, hice lo que cualquier gerente haría: abrí un Google Sheet.

El resultado se veía así:

Código	Nombre	Rev	Estado	Archivo
XT-PR-SGI-01	Procedimiento gestión documental	0	Por aprobar	[Link a Drive]
XT-PR-SGI-02	Procedimiento Estados de Pago	0	Por aprobar	[Link a Drive]
XT-PR-SGI-09	Solicitud Feriado Legal	1	Obsoleto	[Link a Drive]

Se ve ordenado, ¿verdad? Es una trampa.

Ese Excel es un cementerio de enlaces. No me dice qué cambió entre la Rev. 0 y la Rev. 1 del procedimiento de vacaciones. No me dice quién autorizó el cambio. Y lo peor: el archivo enlazado es editable. Si mañana alguien entra al Drive y borra el párrafo 4 del procedimiento de Estados de Pago, el Excel seguirá diciendo “Vigente”, pero mi operación legal estará descubierta.

Como Business Engineer, llegué a una conclusión: Los documentos de una empresa son su Código Fuente. Y deben tratarse con las mismas herramientas.

El problema del “Guardar como…”

En el mundo corporativo, el control de versiones es pasivo. Confiamos en el historial de versiones de Google Drive o SharePoint. El problema es que esos historiales son autocorrecciones, no decisiones. Guardan cada vez que respiras, creando 500 versiones basura donde solo corregiste un tilde. Encontrar el momento exacto en que cambió una regla de negocio es buscar una aguja en un pajar.

Los desarrolladores de software resolvieron esto con Git. Una tecnología que transforma la documentación en un activo inmutable y auditable.

¿Qué es Git?

Git es un controlador de versiones. Un software que mantiene un historial de cambios en un archivo o en una carpeta.

Git intimida porque se asocia a pantallas negras y comandos verdes. Pero la lógica de negocio detrás es brillante y necesaria para cualquier operación madura.

Intuición (Diccionario Gerencial)

Olvida la informática por un minuto. Piensa en Git así:

Repositorio = La caja fuerte digital.
Branch (Rama) = Una fotocopia del borrador para rayar sin dañar el original.
Commit = Una hoja foliada y firmada ante notario (inmutable).
Pull Request = La ceremonia de aprobación (donde se discuten los cambios).
Merge = El sello final de “Aprobado para publicación”.

Recuerda estos términos para lo que sigue.

Arquitectura de un sistema documental basado en Git

No basta con instalar Git. Necesitas una estructura. Así es como organicé el repositorio de la empresa para salir del caos del Drive:

1
/repo-documentacion-operativa
2
├── /src (Código fuente - Donde escribimos)
3
│   ├── /finanzas
4
│   │   ├── XT-PR-SGI-02-estados-pago.md
5
│   │   └── XT-PR-SGI-11-facturacion.md
6
│   ├── /rrhh
7
│   │   └── XT-PR-SGI-09-feriado-legal.md
8
│   └── /templates
9
│       └── formato-oficial.md
10
├── /dist (Distribución - PDFs Generados)
11
│   ├── XT-PR-SGI-02-Rev1.pdf
12
│   └── XT-PR-SGI-11-Rev0.pdf
13
└── changelog.md

Importante (Separación de poderes)

Observa que separo src (el borrador editable) de dist (el PDF final). Nadie edita el PDF. El PDF es una consecuencia de compilar el Markdown, igual que una app es consecuencia de compilar el código.

Los 3 pilares de la “Documentación como código”

1. Markdown: El formato universal

Word es un archivo binario complejo lleno de basura oculta. Git no puede leerlo bien. La solución es Markdown (.md). Texto plano puro. Es ligero, abre en cualquier dispositivo y permite ver las diferencias (“Diffs”) línea por línea.

Comparativa de auditoría:

Word: “Se modificó el archivo contrato.docx (14 MB)”. No sabes qué pasó.

Git + Markdown:

1
El pago se realizará a 30 días fecha factura.
2
El pago se realizará a 45 días fecha recepción conforme.

Sabes exactamente qué política cambió.

2. El Commit: La firma notarial

En lugar de “guardar”, hacemos Commits. Un Commit es un paquete de cambios deliberado y firmado criptográficamente. Requiere un mensaje obligatorio.

commit a1b2c3d
Author: Julio Catalán <hola@juliocatalan.com>
Date:   Mon Jan 20 18:27:45 2026

    fix(rrhh): Actualizar días de feriado progresivo por nueva ley

Y si quieres ver exactamente qué cambió (la diferencia), la consola te lo muestra así:

1
commit a1b2c3d
2
Author: Julio Catalán <hola@juliocatalan.com>
3

4
    fix(rrhh): Actualizar días de feriado progresivo por nueva ley
5

6
--- a/src/rrhh/XT-PR-SGI-09-feriado-legal.md
7
+++ b/src/rrhh/XT-PR-SGI-09-feriado-legal.md
8
@@ -10,5 +10,5 @@
9
 Los días de feriado progresivo se otorgan cada 3 años.
10
 Los días de feriado progresivo se otorgan según el nuevo esquema de la Ley N° 21.XXX.

Si en 2 años hay un juicio laboral, puedo viajar en el tiempo al commit a1b2c3d y demostrar exactamente qué decía el reglamento ese día y quién lo cambió. Eso es blindaje corporativo.

3. Pull Request: La ceremonia de aprobación

Aquí es donde muere la burocracia del correo electrónico (“¿Me revisas el adjunto?”).

Si el Jefe de Finanzas quiere cambiar el procedimiento de gastos:

Crea una Rama (Branch) llamada ajuste-viaticos-2026.
Edita el archivo Markdown.
Abre un Pull Request (PR) proponiendo fusionar sus cambios con la rama main (oficial).

El sistema muestra el “Antes” y el “Después”. Yo, como Gerente, puedo comentar líneas específicas en la misma plataforma: “¿Estás seguro de bajar el monto de cena? Revisa la inflación”. Solo cuando apruebo el PR (clic en “Merge”), el cambio se vuelve oficial. La discusión queda guardada para siempre asociada al cambio.

Caso real: El plan estratégico de capacitaciones

Para que veas el impacto financiero de esto, usemos un documento real: el Plan estratégico de capacitaciones 2026. Este documento define inversiones críticas. En su versión original (Markdown), la matriz de capacitación para profesionales se ve así:

1
# 1. Profesionales (Ingenieros, Arquitectos)
2

3
| Habilidad | Urgencia | Formación | Modalidad y Proveedor |
4
| :--- | :--- | :--- | :--- |
5
| **Gestión avanzada de proyectos (PMI)** | Alta | Diplomado | Online (Clase Ejecutiva UC).|
6
| **Herramientas BIM y modelado 3D** | Alta | Curso online | Online, Academia Archicad.|
7
| **Legislación y normativa chilena** | Media | Taller | Presencial, experto local.|

El “Diff” que ahorra dinero

Imagina que en abril revisamos el presupuesto y decidimos cambiar la estrategia de BIM. En el sistema antiguo (PDF/Word), alguien editaría el texto y guardaría el archivo como “V2”. El cambio pasaría desapercibido entre tanto texto.

En Git, cuando el Jefe de Oficina Técnica propone el cambio, yo veo esto en mi pantalla de aprobación (Pull Request):

1
| Habilidad | Urgencia | Formación | Modalidad y Proveedor |
2
| :--- | :--- | :--- | :--- |
3
| **Gestión avanzada de proyectos (PMI)** | Alta | Diplomado | Online (Clase Ejecutiva UC).|
4
 | **Herramientas BIM y modelado 3D** | Alta | Curso online | Online, Academia Archicad.|
5
 | **Herramientas BIM y modelado 3D** | Alta | Mentoria Interna | Presencial, Jefe de Oficina Técnica. Sin costo. |
6
| **Legislación y normativa chilena** | Media | Taller | Presencial, experto local.|

Al ver ese rojo (lo que sale) y ese verde (lo que entra), no estoy “revisando formato”. Estoy viendo inmediatamente una decisión de ahorro de costos. Apruebo el cambio (Merge) con total certeza del impacto financiero.

Automatización: De texto plano a PDF corporativo

No deberíamos preocuparnos de formatear documentos manualmente. Si escribimos en Markdown, ¿cómo le entregamos un documento bonito con logo y pie de página al auditor o al empleado?

Usamos Pipelines (CI/CD). Configuré una acción en GitHub/GitLab que funciona así:

Alguien aprueba un cambio en XT-PR-SGI-02.md.
Automáticamente se dispara un script (usando una herramienta llamada Pandoc).
El script toma el texto, le pega la plantilla corporativa (Logo, Cabecera, Versión), y genera el PDF.
El sistema sube el nuevo PDF a la carpeta /dist o lo envía por correo a los interesados.

Quizás veas el siguiente código y pienses: “Yo no voy a escribir eso”. Y tienes razón. Este es el script que tu equipo técnico configura una sola vez. Para ti, el proceso será transparente: aprobarás un documento en la web y, mágicamente, un PDF perfecto con tu logo llegará a tu correo. La complejidad técnica queda oculta.

# Ejemplo simplificado del comando que corre el servidor
pandoc src/rrhh/XT-PR-SGI-02.md \
  -o dist/XT-PR-SGI-02.pdf \
  --template=templates/corporativo.tex \
  --variable version="Rev 1.2"

Resultado: Nadie puede “romper el formato” por error. Todos los documentos salen visualmente idénticos porque los genera una máquina, no un humano peleando con los márgenes de Word.

¿Cómo vender esto a la Gerencia?

No les hables de Git, ni de Markdown, ni de ramas. Háblales de Riesgo y Control.

Integridad: “Nadie puede cambiar una coma de un contrato sin que quede un registro inborrable de quién fue y cuándo.”
El “deshacer” infinito: “¿Borraron el manual de operaciones por error? ¿La nueva política no funcionó? Git permite viajar en el tiempo y restaurar la versión exacta del 14 de febrero de 2024 en 10 segundos. El error humano deja de ser fatal.”
Eficiencia: “Se acabaron los correos con Adjunto V4 final revisado. Siempre hay un solo lugar donde está la última versión oficial.”

Conclusión

El Google Sheet fue un buen inventario, pero no es un sistema de gestión. Pasar a Documentation as Code es doloroso al principio. Requiere disciplina. Pero cuando tienes 50 procedimientos y 200 empleados, la disciplina es lo único que escala.

Deja de gestionar documentos. Empieza a gestionar la verdad de tu empresa.