Revisiones y cambios
Git y KiCad: qué meter en el repositorio
Versiona las fuentes y genera lo demás, con la excepción de las entregas, lo que Git aporta de verdad al hardware, lo que no puede hacer y dónde cae la frontera.
KiCad guarda sus esquemas y sus placas como texto. Git versiona bien el texto. Así que meter un proyecto de KiCad en Git es una cosa sensata, y muchos equipos lo hacen con éxito.
La pregunta que merece tiempo no es si usar Git. Es qué meter dentro, porque la diferencia entre un repositorio que ayuda y uno que se convierte en un lastre de 4 GB es casi por completo una decisión sobre su contenido.
Qué va en el repositorio
La regla es la misma que gobierna cualquier sistema de compilación: versiona las fuentes, genera lo demás.
| Versionar | Por qué |
|---|---|
*.kicad_sch, *.kicad_pcb, *.kicad_pro | El diseño. Texto, comparable, irreemplazable |
*.kicad_sym, *.kicad_mod del proyecto | El diseño depende de ellos |
*.kicad_dru, reglas de diseño | Forman parte de la intención del diseño |
fp-lib-table, sym-lib-table | Sin ellas el proyecto abre mal |
| Scripts que generan las salidas | El proceso de generación es parte de la fuente |
| README, notas de diseño, decisiones | Texto, pequeño, y el fichero más valioso de ahí dentro |
| No versionar | Por qué |
|---|---|
*-backups/, *.kicad_prl, *.bak | Estado local y autoguardados |
*.net | Se genera desde el esquema |
| Salidas de fabricación, en el día a día | Generadas; grandes; cambian en cada exportación |
| Librerías de modelos 3D | Binarios grandes que casi nunca cambian |
| Cualquier cosa de un proveedor que puedas volver a descargar | Tamaño sin beneficio |
Un .gitignore acorde son cinco minutos de trabajo y evita la queja más común sobre el ECAD en Git, que es el tamaño del repositorio.
La excepción de las entregas
La tabla de arriba dice que no se versionen las salidas de fabricación. Hay una excepción importante.
Una entrega no es lo mismo que el trabajo diario. Lo que fue al fabricante es evidencia, y una evidencia que se puede regenerar no es evidencia: la regeneración depende de versiones de herramienta, del estado de las librerías y de ajustes que pueden haberse movido todos.
Así que no versiones salidas en cada exportación, pero sí versiona, o archiva de otro modo, el paquete exacto que liberaste, etiquetado con la entrega. Las etiquetas de Git marcan eso bien. Que los ficheros vivan dentro del repositorio o al lado es una decisión de almacenamiento; lo que importa es que queden congelados e identificables.
Qué te da Git de verdad
Un histórico que sobrevive a las personas. Cada estado, con autor, fecha y mensaje. Sólo eso ya es más de lo que tienen la mayoría de los proyectos de hardware.
Ramas para explorar. Probar un layout alternativo sin poner en peligro el diseño principal. Para el trabajo de esquema resulta cómodo; para el de layout menos, por lo que viene más abajo.
Etiquetas para las entregas. v1.0-rev-c es una marca permanente y recuperable sobre un estado exacto de todo el proyecto.
Comparaciones de texto honestas del esquema. No siempre fáciles de leer, pero una red cambiada o un valor cambiado se ven, y eso es muchísimo mejor que comparar dos PDF a ojo.
Un motivo para escribir una frase sobre cada cambio. El mensaje de commit es el registro de cambio más barato que existe.
Qué no hace Git por el hardware
Nada de esto son defectos de Git; son consecuencias de que sea un sistema de versionado de ficheros de propósito general y no una herramienta de hardware.
Las comparaciones de layout no se leen. El fichero es texto, así que Git te enseñará una diferencia, pero unos cientos de líneas de coordenadas cambiadas no le dicen a una persona qué se ha movido. Hace falta una comparación geométrica, y vive fuera de Git.
Fusionar layouts es arriesgado. Que dos personas editen la misma tarjeta y se fusione no es una operación fiable. En la práctica los equipos bloquean la placa —un editor cada vez—, lo que funciona, pero es una convención que Git no impone.
No existe el concepto de pieza. Git versiona ficheros. No sabe que C12 es una instancia de un condensador que además se usa en otras cuatro tarjetas, así que «¿dónde más usamos esta pieza?» es una búsqueda de texto, no una consulta.
No hay estado de aprobación. Un commit no es una aprobación y una etiqueta no es una firma. Quién revisó esto, y contra qué, es una pregunta que Git no puede responder.
No hay vínculo con el mundo físico. A Git le da igual qué commit corresponde a las tarjetas del cajón. Ese mapeo lo tienes que mantener tú, en los nombres de las etiquetas y en las notas de entrega.
Los binarios son su punto débil. Hojas de características, modelos 3D, PDF exportados: Git guarda cada versión entera. Es lo que convierte los repositorios en monstruos. Hay extensiones para ficheros grandes, y funcionan, a cambio de más configuración.
Una disposición que funciona
/hardware
/orion-tpc
orion-tpc.kicad_pro
orion-tpc.kicad_sch
orion-tpc.kicad_pcb
/lib símbolos y huellas del proyecto
/docs notas de diseño, decisiones, justificaciones
/scripts scripts de exportación
.gitignore
/entregas
/orion-tpc-rev-c salidas congeladas, etiquetadasDos convenciones lo hacen funcionar en la práctica. Una tarjeta por directorio, para que su histórico se lea de forma aislada. Y una convención de mensajes de commit que diga qué cambió en términos de ingeniería: «R33 10k→4k7, corrige la caída de la referencia del ADC» le gana a «actualizar esquema» por una distancia que sólo se ve dos años después.
Dónde cae la frontera
Git es fuerte en la fuente del diseño: esquema, layout, librerías, scripts, notas. Es su terreno natural y lo hace bien.
Es débil en todo lo que va de piezas y configuraciones en vez de ficheros: qué componente se usa dónde, qué revisión se liberó, quién la aprobó, de qué está hecha una tarjeta dada. Esas preguntas no son preguntas de fichero, y un sistema de versionado de ficheros las responde con torpeza o no las responde.
Por eso casi todos los montajes que funcionan usan las dos cosas: Git para la fuente del diseño y algo distinto para los datos de componentes y de configuración. El error es esperar que cualquiera de los dos cubra el tramo entero.
XKEMA está en el segundo lado de esa frontera. No guarda ficheros nativos de ECAD y no sustituye a Git: tus .kicad_sch y .kicad_pcb deben estar en control de versiones, y Git hace bien ese trabajo.
Lo que guarda XKEMA es el lado de componentes, BOM y configuración: registros de componente compartidos, BOM y tarjetas versionadas, y la documentación y las salidas de fabricación liberadas que las acompañan.
Control de revisiones hardware Cómo liberar una PCB de KiCad para fabricación Control de revisiones hardware: guía práctica Git, PDM o PLM: elegir por modelo