Una introducción a Git para hardware con Altium Designer

Introducción

Hace unos años, transicioné temporalmente de trabajar en un ambiente de startup hipercafeinado y moderno a un trabajo de ingeniería en una empresa más experimentada y con más trayectoria. Fue entonces cuando me di cuenta de la conexión binomial entre la cultura técnica y las herramientas. Cómo pensamos y cómo trabajamos está moldeado por las herramientas disponibles para nosotros, ya que nuestras necesidades y costumbres influyen en las herramientas que elegimos.

La nueva empresa en la que trabajé no estaba acostumbrada a las impresoras 3D, software de seguimiento de errores interno, o incluso un buen CMS. Todo era bastante anticuado. Esto tuvo una influencia significativa en lo que mis colegas y yo creamos diariamente.

Un ejemplo incluiría las últimas dos décadas, donde la industria ha transitado de paquetes TO220 a D2PAK. Al mismo tiempo, los ingenieros se han equipado con soldadores de alta potencia pico, como los fabricados por JBC.

¿Consideraría un joven ingeniero acceder a un laboratorio bien equipado y aún así elegir un CI popular en un TO220 en esta década? No lo creo. Es mucho más fácil trabajar con D2PAKs y no tener que lidiar con tornillos, arandelas y láminas aislantes, siempre que tengas un soldador de última generación. Este simple cambio puede orientar a un ingeniero hacia el diseño de placas más planas, lo que a menudo puede llevar a productos más estéticamente agradables según los estándares modernos.

Git es un ejemplo raro de una herramienta que ha dado vuelta a toda una industria. Hace diez años, los gerentes de ingeniería de software habrían considerado locos adoptar un enfoque de moverse rápido y romper cosas. Git para el diseño de hardware y PCB lo ha hecho posible al habilitar el seguimiento de revisiones, control de versiones y revertir cambios de diseño. Los desarrolladores ahora están seguros de que sus esfuerzos en proyectos de código abierto siempre pueden ser atribuidos y verificados, gracias a una característica llamada Git blame. Hace una década, ser reconocido por tu contribución a proyectos de código abierto quedaba a la política. Estos son todos ejemplos de cambios por los que podemos agradecer a Git.

Aunque por su propia naturaleza, la industria electrónica se mueve más lento que el software, muchas de las innovaciones están filtrándose a nuestro trabajo diario. Altium Designer®, con la introducción de Altium 365® y Concord Pro™ este año, ha liderado el camino en la industria, con otros jugadores importantes luchando por mantenerse al día, a veces con características lanzadas hace más de una década. Git para el diseño de hardware y PCB es una de las tecnologías que impulsan ese cambio.

¿Qué es Git?

Muy simplemente, Git es un sistema de control de versiones (VCS). Es un software (incluyendo los protocolos subyacentes y formatos de datos) utilizado por desarrolladores de software para rastrear y gestionar cambios en el código. Si eres un desarrollador de software trabajando en esta década, no duplicas carpetas en tu escritorio para probar cosas, lo más probable es que uses un VCS basado en Git.

Aunque Git es enormemente popular para rastrear cambios de código en el desarrollo de software, puede ser utilizado para rastrear cambios en cualquier conjunto de archivos. Estos archivos no necesitan contener código, pueden ser tus archivos de diseño de PCB, documentación de diseño, archivos de fabricación de PCB y cualquier otro archivo que necesites para tu proyecto. Git para hardware es una extensión natural del ecosistema de Git hacia el diseño mecánico, diseño de PCB, firmware y mucho más.

Git está disponible gratuitamente para uso comercial. Es de código abierto y distribuido bajo la licencia pública general de GNU. Cada directorio de Git es una entidad separada y es, en sí mismo, un repositorio que contiene un historial completo de sus elementos. Cada archivo colocado en un repositorio de Git es completamente rastreable hasta cada bit, por quién y cuándo. Los repositorios de Git no requieren acceso a la red, siendo cada repositorio completamente independiente de los servidor(es) que toman el nombre de remoto(s).

Por lo tanto, no debería sorprender que actualmente sea el VCS más popular del mundo. La mayoría de los análisis de cuota de mercado muestran a Git por encima del 75%, y la alternativa más popular, SVN, ha estado en declive desde 2012. El número de vacantes de trabajo que requieren SVN (un VCS legado, también soportado por Altium Designer) también está en declive mientras que Git ha estado ganando popularidad.

Historia de Git

Git fue creado y escrito en 2005 por Linus Torvalds, el hombre, la leyenda, el creador y desarrollador del kernel de Linux, para rastrear el propio desarrollo del kernel. La comunidad de Linux había sido concedida el uso gratuito de un software comercial llamado BitKeeper. En abril de 2005, el autor de Bitkeeper retiró la licencia después de que un miembro prominente del equipo de Linux e inventor del servidor de archivos Samba, Andrew Tridgell, comenzara a trabajar en un cliente de código abierto basado en el protocolo de BitKeeper (supuestamente) ingeniería inversa. La licencia de BitKeeper prohíbe expresamente la ingeniería inversa.

Así, Linus Torvalds decidió crear su propio sistema de control de versiones, inspirado no tan libremente en BitKeeper, ya que ninguna de las alternativas restantes estaba ni cerca de cumplir con sus requisitos.

Torvalds decidió que el nuevo software sería muy diferente de los populares CVS (Sistemas de Versiones Concurrentes) en uso en ese momento. Se dio cuenta de que los sistemas actuales podrían tardar mucho en aplicar parches, y como necesitaba aplicar cientos de parches a la vez al sincronizarse con su equipo, su rendimiento estaba lejos de ser aceptable. Se le ocurrió una serie de requisitos:

• Un flujo de trabajo distribuido similar a lo que BitKeeper habilitaba. El usuario debería poder trabajar sin conexión y sincronizarse más tarde.
• Protegido contra accidentes como la corrupción de datos
• Seguro contra ataques maliciosos
• Capaz de computar parches en menos de dos segundos

El trabajo en la escritura de Git comenzó a principios de abril de 2005. El 16 de junio de 2005, se lanzó la versión 2.6.12 del kernel de Linux, la razón por la cual el software era necesario con urgencia. Posteriormente, el desarrollo y mantenimiento de Git fueron entregados a Junio Amano, quien contribuyó y aún contribuye a su desarrollo, y es ampliamente reconocido por hacer el software fácil de usar; Git 1.0 fue lanzado en diciembre de 2005.

Convención de Nombres

¿Por qué Git? ¡Un nombre extraño, por decir lo menos! Como la mayoría de las personas en el Reino Unido saben, el término a menudo se da a alguien que es un poco atrevido o, según el Oxford Online Dictionary, "una persona desagradable o despreciable". Otros significados reportados incluyen "tonto" (argot del siglo XVIII al XIX (Reino Unido)) o "hijo bastardo" (argot de mediados del siglo XVIII al XIX (EE. UU.)), ambos encajarían bastante poéticamente en su mito del genio solitario ermitaño escondiéndose para crear una obra de arte que cambiaría el mundo.

Torvalds ha dado varias razones para nombrar su sistema "Git", para ser elegido según lo que el usuario esté sintiendo ese día, o probablemente cómo se sentía él en diferentes momentos al escribir el sistema. A menudo lo describe como "el rastreador de contenido estúpido" en la documentación oficial, y la definición de Git como:

• "Una combinación aleatoria de 3 letras que no se pueden pronunciar".
• ¡Una pronunciación incorrecta de "get"!
• Rastreador de información global si funciona según lo planeado
• Estúpido, despreciable y desagradable cuando no lo hace.

Oh, el humor de los programadores.

Desventajas

Sin embargo, Git no es perfecto y tiene algunas desventajas. La estructura de datos difícil de comprender y la extraña nomenclatura están sin duda entre ellas. Esto incluye Git para proyectos de hardware, donde se imponen la misma estructura de archivos y operaciones.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Pull Request, Tag, Upstream, Fork, Rebase, Origin, Fetch y HEAD (siempre escrito en mayúsculas completas, no tengo idea de por qué) están entre algunos de los términos más extraños que puedes esperar encontrar en el mundo del software.

Puede ser difícil entender cómo configurar un repositorio como software del lado del servidor, y entender la relación entre los repositorios locales y remotos junto con las operaciones para mantenerlos sincronizados. Git tiende a ser mucho más complejo que SVN para aprender y usar, parcialmente debido a que es mucho más poderoso y eficiente.

Afortunadamente, Altium Designer y Concord Pro se encargan de la mayoría de estos problemas. Mientras tenemos acceso completo al poder de Git a través de la línea de comandos, la interfaz de usuario y la integración estricta de Concord Pro lo hacen fácil e intuitivo de operar. Al mismo tiempo, Altium 365 se encarga de todos los problemas del lado del servidor.

¿Cómo Funciona Git para Hardware?

Git puede parecer... ¡muy extraño! La nomenclatura, principalmente, refleja un flujo de trabajo que difiere sustancialmente del clásico copiar y pegar, comprimir y enviar correos electrónicos a los que muchos ingenieros están acostumbrados.

Ramas (y Fusiones)

El modelo de ramificación es quizás la característica más popular que separa a Git de otro VCS como SVN. Git puede tener múltiples ramas, tanto locales como remotas. Como la rama de un árbol se bifurca del tronco o entre sí, así las ramas de Git brotan de otras ramas. El "tronco" del árbol, o la rama principal, se llama master. Las ramas pueden crearse, fusionarse y eliminarse fácilmente. Así es como funcionan estas operaciones:

• Cada rama es independiente, y cuando trabajas de manera remota, no tienes que estorbar a nadie. Incluso puedes tener múltiples ramas tú mismo, cada rama conteniendo una variación ligeramente diferente de tu propio diseño de software o hardware, y se pueden cambiar dentro del mismo directorio sin tener que cerrar y volver a abrir archivos manualmente.
• En el mundo del software, la regla general es tener una rama de producción, llamada master, y una segunda rama de trabajo en progreso llamada develop y tantas ramas pequeñas como sean necesarias para nuevas características y correcciones. El mismo enfoque se puede tomar con proyectos de hardware. De hecho, hay muchos repositorios de GitHub con diseños de PCB y otros proyectos específicamente para hardware.
• No todas las ramas tienen que fusionarse en la rama master. A menudo los desarrolladores descubren que la nueva característica no es precisamente una chispa de genialidad, y la rama simplemente puede ser eliminada cuando ya no se requiera.

[Modo nerd ACTIVADO]

Entonces, ¿cómo funciona esta ingeniosa característica? Una rama es esencialmente un puntero a un commit. Un commit es un conjunto de cambios de archivos, adiciones o eliminaciones empujadas al repositorio. El commit tiene una suma de comprobación criptográfica SHA-1 de 40 caracteres que se escribe en un archivo. Cada commit también incluye un puntero al commit padre del que se originó.

Hay muchos pasos intermedios adicionales, por ejemplo, los archivos se convierten en blobs binarios con suma de comprobación y organizados en directorios a través de un árbol binario. La suma de comprobación del árbol también se calcula. Dado que todo está cifrado criptográficamente, no hay forma de alterar (o corromper) los datos o la historia sin cambiar la suma de comprobación del último commit. El cifrado criptográfico hace que la historia de Git sea algo permanente, ¡así que sé educado al escribir mensajes de commit!

[Modo nerd DESACTIVADO]

Flujos de trabajo en Git para Hardware

Gracias a la naturaleza distribuida de Git para hardware y el avanzado sistema de ramificación, así como a un conjunto de otras características, los usuarios son libres de adoptar cualquier flujo de trabajo.

Entre los más populares, el modelo de *Flujo de Trabajo Centralizado* es uno que a menudo se utiliza cuando las personas que tienen experiencia con el sistema de control de versiones centralizado comienzan a usar Git (que es *descentralizado*) por primera vez. El *Flujo de Trabajo Centralizado* se basa casi exclusivamente en la rama master, donde todos los commits son enviados y obtenidos, haciendo que Git imite el comportamiento de SVN y los sistemas de archivos remotos.

El flujo de trabajo de Feature Branching es una evolución del *Flujo de Trabajo Centralizado*. El trabajo de desarrollo se realiza en ramas separadas que luego se fusionan en una master. Soy un entusiasta proponente de este modelo en ingeniería electrónica, y estoy esperando ansiosamente que Altium anuncie su soporte de ramas para aprovecharlo. Ejemplos de ramas de características podrían ser “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption” o “reduce_thermal_drift”.

En el flujo de trabajo GitFlow, quizás el más complejo entre los flujos de trabajo populares, la rama master solo contiene lanzamientos de diseño completos, puedes pensar en ello como board_v_1.0, board_v_1.1, etc. El desarrollo se realiza en una rama separada llamada develop, y las características y correcciones provienen de la rama develop. Solo develop puede fusionarse en master una vez que esté listo.

Descentralización y Velocidad

Git es más rápido que otros sistemas de control de versiones por varias razones. Cada usuario puede clonar el repositorio original, y los commits pueden realizarse regularmente en ramas locales y enviarse al remoto con menos frecuencia. Otros VCS que no son tan descentralizados están limitados por la capacidad del servidor remoto, lo que tiene que reducir considerablemente la velocidad para satisfacer todas sus solicitudes.

Este enfoque local primero es particularmente crucial en la industria electrónica, ya que los archivos pueden ser bastante grandes. No es raro que un diseño de PCB tenga decenas de megabytes de tamaño, especialmente con cientos de cuerpos en 3D. Los archivos de código fuente, por otro lado, tienden a ser de unos pocos cientos de KBytes como máximo.

En la última empresa para la que trabajé, teníamos un repositorio SVN alojado en las oficinas principales, accesible a través de una VPN, donde almacenaríamos los archivos del proyecto y la documentación. Tomaría una eternidad realizar cualquier operación, y nuestra conexión a internet limitada frecuentemente se saturaba por todas las solicitudes para gestionar los miles de archivos.

Git también está escrito en el lenguaje C, lo que significa que su sobrecarga es mínima en comparación con otros lenguajes de alto nivel. Dependiendo de la operación, Git puede ser desde unas pocas veces hasta cientos de veces más rápido que SVN.

El enfoque descentralizado y primero sin conexión también hace que Git sea mucho más ligero en la red. Incluso si tu empresa no tiene acceso a banda ancha, puedes enviar los datos a la hora del almuerzo o después del trabajo, sin pérdida de rendimiento en el trabajo diario.

En Concord Pro, puedes disfrutar de todos los beneficios de Altium 365 cuando tienes acceso a una conexión a internet, luego lleva tu licencia de Altium Designer y continúa trabajando sin conexión.

Áreas de Preparación

Al trabajar con Git, es esencial darse cuenta de que los archivos pasan por tres etapas antes de que realmente puedan considerarse bajo control de versiones:

1. No rastreado
2. Preparado
3. Confirmado

No rastreado es cuando el archivo existe en disco, pero está fuera del sistema de control de versiones. El archivo no rastreado puede entonces ser preparado, lo que significa que ha sido agregado al sistema de control de versiones pero aún no confirmado. En este punto, los cambios preparados pueden ser confirmados. El sistema de preparación se utiliza para prepararse para la confirmación, pero la característica se utiliza principalmente en operación de línea de comandos.

Al usar Git a través de Altium, gracias a la interfaz gráfica de usuario que simplifica la operación, el enfoque de preparación se aplica automáticamente en segundo plano cuando guardas los cambios en el servidor.

Creando un Repositorio

Los repositorios se crean automáticamente en el lado del servidor cuando creas un nuevo proyecto. En la ventana a continuación, estoy creando un nuevo proyecto de PCB a partir de una plantilla dentro de mi espacio de trabajo de Fermium LTD. Tan pronto como cree el proyecto, será accesible en mi espacio de trabajo de Altium 365, y la plataforma creará automáticamente un repositorio Git para el nuevo proyecto.

Configuración Inicial del Repositorio

Los repositorios creados con Concord Pro se configuran automáticamente, por lo que solo los archivos esenciales ya están confirmados en el repositorio Git del proyecto, mientras que las copias de seguridad locales y los archivos LOG no lo están. Típicamente sería necesario tanto configurar un archivo llamado ".Gitignore" apropiadamente como cuidar de no confirmar archivos innecesarios, pero Concord Pro se encarga de eso.

Configuración de Credenciales

Para acceder a los repositorios Git, generalmente sería necesario configurar las claves SSH y las credenciales de usuario tanto en el lado del servidor como en el cliente. Concord Pro se encarga de esto automáticamente cuando se agrega un nuevo usuario.

Clonación de Repositorios

La clonación es el proceso mediante el cual Git replica el repositorio remoto en una copia local. Clonar manualmente grandes repositorios con archivos binarios, como los archivos PcbDoc y SchDoc, normalmente requeriría una operación de línea de comandos a nivel experto. Altium Designer y Concord Pro clonan automáticamente el repositorio a tu máquina local en segundo plano cuando abres un proyecto remoto.

Resolución de Conflictos y Comparación de Cambios

Concord Pro te permite comparar cambios entre diferentes revisiones, tanto locales como remotas, a través del panel del gestor de almacenamiento. En el siguiente ejemplo, he añadido un objeto de nota de texto y he realizado los cambios localmente, pero no los he empujado al remoto.

Esto nos brinda la funcionalidad completa necesaria en una plataforma de Git para hardware.

Conclusiones

Git es una herramienta formidable, y git para hardware ofrece a los diseñadores de PCB un flujo de trabajo completo para el control de versiones, compartición y gestión de revisiones. Este sistema popular ha ayudado a moldear la cultura de los programadores modernos. Ahora, con Altium Designer® y la plataforma Altium 365®, los diseñadores pueden acceder a las características de Git para el diseño de PCBs.

Puedes comenzar una prueba de Altium 365 hoy mismo, cargada con proyectos de ejemplo, para experimentar completamente el desarrollo electrónico al estilo del siglo XXI. ¿Tienes más preguntas? Habla hoy mismo con un experto de Altium.