Todo el módulo se ha basado en una idea: el diseño es código. Antes de seguir, una glosa por si Git te suena solo de oídas: Git es un sistema de control de versiones, una especie de “máquina del tiempo” para archivos de texto. Lo escribió Linus Torvalds en 2005 para gestionar el propio código del kernel de Linux, y hoy es el estándar de control de versiones de casi todo el software. Guarda el historial completo de cambios, te deja volver a cualquier punto anterior y permite abrir ramas (líneas de trabajo paralelas) para probar ideas sin tocar la versión que funciona. Los .scad de OpenSCAD y los .yaml de Ergogen son texto plano, y el texto plano se versiona con Git de maravilla. Esto te da historial, ramas para experimentar, etiquetas de versión y, gracias a GitHub, una forma de enseñar tus piezas en 3D a un cliente sin que instale nada. Vamos a montar un repositorio CAD como Dios manda.

Por qué Git encaja con CAD paramétrico

Con un CAD binario (un .f3d de Fusion o un .FCStd de FreeCAD), Git solo ve “el archivo cambió”, sin más detalle. Con OpenSCAD y Ergogen, Git ve cada línea modificada: qué variable cambiaste, qué cutout añadiste. Eso significa:

• Diffs legibles: ves exactamente qué pasó entre dos versiones.
• Ramas baratas: pruebas una pared más gruesa en una rama y, si no funciona, la descartas.
• Reproducibilidad: cualquiera clona el repo y regenera el STL idéntico.

Estructura de carpetas recomendada

Una organización clara evita el caos de tener caja_final_v2_BUENA.scad. Esta estructura funciona bien para un taller:

mi-proyecto/
├── src/                  # fuentes editables
│   ├── caja.scad
│   ├── config.scad
│   └── lib/
│       ├── cutouts.scad
│       └── tornilleria.scad
├── ergogen/              # configs de teclado
│   └── teclado.yaml
├── export/               # STL/DXF generados (¿versionar?)
│   ├── caja-base.stl
│   └── caja-tapa.stl
├── docs/                 # fotos, notas, datasheets
├── LICENSE
├── README.md
└── .gitignore

La idea: src/ es la verdad (lo editable), export/ es derivado. Como los STL se regeneran desde el código, mucha gente prefiere no versionarlos para no inflar el repo. Otros sí versionan el STL de cada release para que un cliente lo descargue sin tener OpenSCAD. Una solución intermedia: ignorar export/ en el día a día y adjuntar los STL solo a las releases etiquetadas (ver más abajo).

El .gitignore para CAD

Conviene ignorar los archivos generados y la basura de los programas. El .gitignore es un archivo donde listas los patrones de ficheros que Git debe ignorar, para que no acaben en el historial. Un .gitignore típico:

# Geometría generada (se regenera desde src/)
export/
*.stl
*.3mf
*.gcode

# OpenSCAD
*.csg
*.echo
*.bak

# Ergogen / Node
node_modules/
output/

# Sistema operativo
.DS_Store
Thumbs.db

Si decides versionar los STL de las releases, quita la línea *.stl o usa una excepción (!export/release/*.stl).

Flujo básico con Git

Inicializas y haces el primer commit:

git init
git add .
git commit -m "Estructura inicial del proyecto"

Para experimentar sin romper lo que funciona, trabaja en ramas:

git switch -c pared-mas-gruesa
# editas config.scad: grosor_pared = 3
git commit -am "Probar pared de 3 mm para ASA"
# si convence, la fusionas; si no, la descartas
git switch main
git merge pared-mas-gruesa

Escribe mensajes de commit útiles: “Ajustar holgura USB-C a 0.3 para PETG” dice mucho más que “cambios”.

Tags de versión

Cuando una pieza está lista para imprimir o entregar, etiquétala. Un tag marca un punto del historial como versión estable:

git tag -a v1.0 -m "Carcasa Heltec V3, validada en PETG"
git push origin v1.0

Usa versionado semántico (el convenio de numerar las versiones como mayor.menor, donde cada cifra comunica el tipo de cambio) adaptado al hardware:

• v1.0 -> v1.1: cambio menor compatible (un cutout nuevo, más ventilación).
• v1.0 -> v2.0: cambio que rompe compatibilidad física (cambian las medidas, ya no encaja el PCB de antes).

Así, si un cliente te dice “imprímeme la v1.2”, sabes exactamente qué código corresponde.

Visualización online para enseñar a clientes

Aquí está la ventaja que mucha gente no conoce: GitHub renderiza archivos STL directamente en el navegador. Si subes un .stl al repositorio, al abrirlo en GitHub aparece un visor 3D interactivo (rotar, hacer zoom) sin que el cliente instale nada. Esto es ideal para enseñar una pieza antes de imprimirla.

Para sacarle partido:

1. Sube el STL de la versión que quieres mostrar (o adjúntalo a una release).
2. Comparte el enlace al archivo en GitHub.
3. El cliente lo gira en su navegador y te da el visto bueno.

Si quieres algo más vistoso, hay visores web embebibles basados en Three.js (una librería de JavaScript para mostrar gráficos 3D en el navegador, como los de muchos servicios de impresión) que puedes incrustar en una página propia. Pero para el flujo de taller, el visor nativo de GitHub suele bastar.

Releases con archivos adjuntos

Las Releases de GitHub combinan un tag con archivos adjuntos. Es el lugar perfecto para publicar los STL listos para imprimir de una versión concreta, manteniéndolos fuera del historial diario pero accesibles:

1. Creas la release sobre el tag v1.0.
2. Adjuntas caja-base.stl y caja-tapa.stl.
3. Escribes una nota con el material recomendado y los ajustes de impresión.

Buenas prácticas finales

• Commits pequeños y descriptivos: un cambio lógico por commit.
• El README manda: documenta qué imprime cada archivo, en qué material y con qué orientación.
• Incluye la LICENSE: como vimos en el primer artículo del módulo, elige conscientemente bajo qué términos compartes.
• Ramas para experimentos: nunca pruebes ideas arriesgadas directamente en main.
• Etiqueta cada versión entregada: tu yo del futuro y tus clientes te lo agradecerán.

Con esto cierras el módulo: sabes diseñar de forma paramétrica con OpenSCAD, generar teclados con Ergogen, elegir la licencia correcta y, ahora, gestionar todo ese trabajo con Git de forma profesional y reproducible.