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í:

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 auditable, y que bien configurada es muy difícil de adulterar.

¿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.

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
│   │   └── XT-PR-SGI-10-reglamento-interno.md
9
│   └── /templates
10
│       └── formato-oficial.md
11
├── /dist (Distribución - PDFs Generados)
12
│   ├── XT-PR-SGI-02-Rev1.pdf
13
│   └── XT-PR-SGI-11-Rev0.pdf
14
└── changelog.md

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ó, salvo que alguien haya activado el control de cambios y nadie lo haya aceptado a ciegas.
• 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, con un mensaje obligatorio y un identificador calculado a partir de su contenido: si alguien altera una coma del pasado, el identificador cambia y la alteración queda a la vista.

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

    fix(rrhh): jornada ordinaria de 42 horas por Ley 21.561

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): jornada ordinaria de 42 horas por Ley 21.561
5

6
--- a/src/rrhh/XT-PR-SGI-10-reglamento-interno.md
7
+++ b/src/rrhh/XT-PR-SGI-10-reglamento-interno.md
8
@@ -10,5 +10,5 @@
9
 La jornada ordinaria de trabajo es de 44 horas semanales.
10
 La jornada ordinaria de trabajo es de 42 horas semanales, desde el 26 de abril de 2026.

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, con dos condiciones que conviene cumplir desde el primer día. Git no firma los commits por defecto (el campo “Author” dice lo que el usuario configuró), así que la identidad la garantiza la plataforma donde vive el repositorio, con su registro de accesos, o la firma de commits si la activas. Y la historia de Git sí se puede reescribir: la rama main tiene que estar protegida para que nadie, ni siquiera un administrador apurado, pueda sobrescribirla.

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:

1. Crea una Rama (Branch) llamada ajuste-viaticos-2026.
2. Edita el archivo Markdown.
3. 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í:

1. Alguien aprueba un cambio en XT-PR-SGI-02.md.
2. Automáticamente se dispara un script (usando una herramienta llamada Pandoc).
3. El script toma el texto, le pega la plantilla corporativa (Logo, Cabecera, Versión), y genera el PDF.
4. 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.

1. Integridad: “Nadie puede cambiar una coma de un procedimiento sin que quede registro de quién fue y cuándo.”
2. 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.”
3. Eficiencia: “Se acabaron los correos con Adjunto V4 final revisado. Siempre hay un solo lugar donde está la última versión oficial.”

Dónde esto no calza

Para no venderlo como solución universal: no todo documento de la empresa debe vivir en Git. Los contratos que se negocian con una contraparte que trabaja en Word, los documentos con diseño gráfico complejo o los formularios que firma un tercero seguirán viviendo mejor en sus herramientas. Y el mayor obstáculo no es técnico: es que un jefe de área que nunca vio una rama acepte revisar cambios en una plataforma nueva. Lo que me funcionó fue empezar por un solo tipo de documento (los procedimientos internos), dejar que la gente edite desde el navegador de la plataforma sin instalar nada, y mostrar el primer diff en una reunión. Nadie se convence con la teoría; se convencen viendo en rojo y verde qué cambió en su propio procedimiento.

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.