Une introduction à Git pour le matériel avec Altium Designer

Introduction

Il y a quelques années, je suis temporairement passé d'un travail dans un environnement de startup hyper-caféiné à un emploi d'ingénieur dans une entreprise plus expérimentée et aguerrie. J'ai alors réalisé la connexion binomiale entre la culture technique et les outils. Notre manière de penser et de travailler est façonnée par les outils à notre disposition, tout comme nos besoins et nos coutumes influencent les outils que nous choisissons.

La nouvelle entreprise où je travaillais n'était pas habituée aux imprimantes 3D, aux logiciels de suivi des bugs en interne, ou même à un bon CMS. Tout cela était plutôt démodé. Cela a eu une influence significative sur ce que mes collègues et moi créions au quotidien.

Un exemple inclurait les dernières décennies, où l'industrie est passée des boîtiers TO220 aux D2PAK. Dans le même temps, les ingénieurs se sont équipés de fers à souder à haute puissance de crête, comme ceux fabriqués par JBC.

Un jeune ingénieur ayant accès à un laboratoire bien équipé considérerait-il même un CI populaire en TO220 dans cette décennie ? Je ne le pense pas. Il est tellement plus facile de travailler avec des D2PAK et de ne pas avoir à manipuler des vis, des rondelles et du papier isolant, à condition d'avoir un fer à souder de dernière génération. Ce simple changement peut orienter un ingénieur vers la conception de cartes plus plates, ce qui peut souvent conduire à des produits plus esthétiquement agréables selon les normes modernes.

Git est un exemple rare d'un outil qui a complètement bouleversé toute une industrie. Il y a dix ans, les managers en génie logiciel auraient été considérés comme fous d'adopter une approche avancer rapidement et casser des choses. Git pour la conception de matériel et de PCB l'a rendu possible en permettant le suivi des révisions, le contrôle des versions et le retour en arrière des modifications de conception. Les développeurs sont désormais assurés que leurs efforts sur les projets open source peuvent toujours être attribués et vérifiés, grâce à une fonctionnalité appelée Git blame. Il y a une décennie, être reconnu pour votre contribution aux projets open source était laissé à la politique. Ce sont tous des exemples de changements pour lesquels nous pouvons remercier Git.

Bien que de par sa nature même, l'industrie électronique évolue plus lentement que le logiciel, bon nombre des innovations se répercutent sur notre travail quotidien. Altium Designer®, avec l'introduction d'Altium 365® et de Concord Pro™ cette année, a montré la voie dans l'industrie, les autres acteurs clés peinant à suivre, parfois avec des fonctionnalités sorties il y a plus d'une décennie. Git pour la conception de matériel et de PCB est l'une des technologies qui alimentent ce changement.

Qu'est-ce que Git ?

Très simplement, Git est un système de contrôle de version (VCS). C'est un logiciel (y compris les protocoles sous-jacents et les formats de données) utilisé par les développeurs de logiciels pour suivre et gérer les modifications de code. Si vous êtes un développeur de logiciels travaillant dans cette décennie, vous ne dupliquez pas des dossiers sur votre bureau pour essayer des choses, vous utilisez très probablement un VCS basé sur Git.

Bien que Git soit massivement populaire pour le suivi des modifications de code dans le développement logiciel, il peut être utilisé pour suivre les modifications de n'importe quel ensemble de fichiers. Ces fichiers n'ont pas besoin de contenir du code, ils peuvent être vos fichiers de conception de PCB, documentation de conception, fichiers de fabrication de PCB, et tout autre fichier dont vous aurez besoin pour votre projet. Git pour le matériel est une extension naturelle de l'écosystème Git à la conception mécanique, la conception de PCB, le firmware, et bien plus encore.

Git est librement disponible pour un usage commercial. Il est open-source et distribué sous la licence publique générale GNU. Chaque répertoire Git est une entité séparée et est, en lui-même, un dépôt contenant un historique complet de ses éléments. Chaque fichier placé dans un dépôt Git est entièrement traçable jusqu'à chaque bit, par qui, et quand. Les dépôts Git ne nécessitent pas d'accès réseau, chaque dépôt étant complètement indépendant des serveur(s) qui prennent le nom de distant(s).

Il ne devrait donc pas être surprenant que ce soit actuellement le VCS le plus populaire au monde. La plupart des analyses de parts de marché montrent Git à plus de 75%, et l'alternative la plus populaire, SVN, est en déclin depuis 2012. Le nombre d'offres d'emploi nécessitant SVN (un VCS hérité, également pris en charge par Altium Designer) est également en déclin tandis que Git gagne en popularité.

Histoire de Git

Git a été créé et écrit en 2005 par Linus Torvalds, l'homme, la légende, le créateur et développeur du noyau Linux, pour suivre le développement de son propre noyau. La communauté Linux avait obtenu l'utilisation gratuite d'un logiciel commercial appelé BitKeeper. En avril 2005, l'auteur de BitKeeper a retiré la licence après qu'un membre éminent de l'équipe Linux et inventeur du serveur de fichiers Samba, Andrew Tridgell, a commencé à travailler sur un client open-source basé sur le protocole de BitKeeper (prétendument) reverse-engineered. La licence BitKeeper interdit expressément le reverse-engineering.

Ainsi, Linus Torvalds a décidé de créer son propre système de contrôle de version, inspiré de manière pas si lâche par BitKeeper, car aucune des alternatives restantes n'était même proche de répondre à ses exigences.

Torvalds a décidé que le nouveau logiciel serait très différent des CVS (Concurrent Version Systems) populaires à l'époque. Il a réalisé que les systèmes actuels pourraient prendre beaucoup de temps à appliquer des patches, et comme il avait besoin d'appliquer des centaines de patches à la fois lors de la synchronisation avec son équipe, leur performance était loin d'être acceptable. Il a établi une série d'exigences :

• Un flux de travail distribué similaire à ce que BitKeeper permettait. L'utilisateur devrait pouvoir travailler hors ligne et synchroniser plus tard.
• Protégé contre les accidents tels que la corruption de données
• Sécurisé contre les attaques malveillantes
• Capable de calculer des patches en moins de deux secondes

Le travail sur l'écriture de Git a commencé au début du mois d'avril 2005. Le 16 juin 2005, la version 2.6.12 du noyau Linux, la raison pour laquelle le logiciel était nécessaire en urgence, a été publiée. Le développement et la maintenance de Git ont ensuite été confiés à Junio Amano, qui a contribué et contribue encore à son développement, et est largement crédité de rendre le logiciel facile à utiliser ; Git 1.0 a été publié en décembre 2005.

Convention de Nomination

Pourquoi Git ? Un nom étrange, c'est le moins qu'on puisse dire ! Comme la plupart des gens au Royaume-Uni le savent, le terme est souvent donné à quelqu'un qui est un peu effronté ou, selon le Oxford Online Dictionary, "une personne désagréable ou méprisable". Les significations supplémentaires rapportées sont "idiot" (argot du 18e au 19e siècle (UK)) ou "enfant bâtard" (argot du milieu du 18e au 19e siècle (US)), qui s'intégreraient tout à fait poétiquement dans son mythe du génie solitaire se cachant pour créer une œuvre d'art qui changerait le monde.

Torvalds a donné plusieurs raisons pour nommer son système "Git", à choisir selon ce que l'utilisateur ressent le jour même, ou probablement comment il se sentait à différents moments lors de l'écriture du système ! Il le décrit souvent comme "le stupide traqueur de contenu" dans la documentation officielle, et la définition de Git étant :

• "Une combinaison aléatoire de 3 lettres qui ne peut pas être prononcée".
• Une mauvaise prononciation de "get" !
• Traqueur d'informations global s'il fonctionne selon le plan
• Stupide, méprisable et despicable quand ce n'est pas le cas.

Ah, l'humour des programmeurs.

Inconvénients

Git n'est pas parfait, cependant, et il présente certains inconvénients. La structure de données difficile à saisir et la nomenclature étrange en font sans aucun doute partie. Cela inclut Git pour les projets matériels, où la même structure de fichiers et opérations sont imposées.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Demande de Pull, Tag, Upstream, Fork, Rebase, Origin, Fetch et HEAD (toujours écrit en majuscules, je ne sais pas pourquoi) font partie des termes les plus étranges que vous pouvez vous attendre à trouver dans le monde du logiciel.

Il peut être difficile de comprendre comment configurer un dépôt en tant que logiciel côté serveur, et de comprendre la relation entre les dépôts locaux et distants ainsi que les opérations pour les maintenir synchronisés. Git tend à être beaucoup plus complexe à apprendre et à utiliser que SVN, en partie parce qu'il est beaucoup plus puissant et efficace.

Heureusement, Altium Designer et Concord Pro prennent en charge la plupart de ces problèmes. Alors que nous avons un accès complet à la puissance de Git via la ligne de commande, l'interface utilisateur et l'intégration stricte de Concord Pro rendent son utilisation facile et intuitive. En même temps, Altium 365 prend en charge tous les problèmes côté serveur.

Comment fonctionne Git pour le matériel ?

Git peut sembler... très étrange ! La nomenclature, principalement, reflète un flux de travail qui diffère substantiellement du copier-coller, de la compression et des emails auxquels de nombreux ingénieurs sont habitués.

Branchements (et Fusions)

Le modèle de branchement est peut-être la fonctionnalité la plus populaire qui distingue Git d'un autre VCS comme SVN. Git peut avoir plusieurs branches, à la fois locales et distantes. Comme la branche d'un arbre se bifurque à partir du tronc ou les unes des autres, ainsi les branches de Git poussent à partir d'autres branches. Le "tronc" de l'arbre, ou la branche principale, est appelé master. Les branches peuvent être facilement créées, fusionnées et supprimées. Voici comment ces opérations fonctionnent :

• Chaque branche est indépendante, et lorsque vous travaillez à distance, vous n'avez pas à marcher sur les pieds de qui que ce soit. Vous pouvez même avoir plusieurs branches vous-même, chaque branche contenant une variation légèrement différente de votre propre conception logicielle ou matérielle, et elles peuvent être changées dans le même répertoire sans avoir à fermer et rouvrir les fichiers manuellement.
• Dans le monde du logiciel, la règle générale est d'avoir une branche de production, appelée master, et une seconde branche de travail en cours appelée develop et autant de petites branches que nécessaire pour de nouvelles fonctionnalités et corrections. La même approche peut être adoptée pour les projets matériels. En fait, il existe de nombreux dépôts GitHub avec des conceptions de PCB et d'autres projets spécifiquement pour le matériel.
• Toutes les branches n'ont pas à être fusionnées dans la branche master. Souvent, les développeurs se rendent compte que la nouvelle fonctionnalité n'est pas tout à fait un éclair de génie, et la branche peut simplement être supprimée lorsqu'elle n'est plus nécessaire.

[Mode nerd ACTIVÉ]

Alors, comment cette fonctionnalité astucieuse fonctionne-t-elle ? Une branche est essentiellement un pointeur vers un commit. Un commit est un ensemble de modifications de fichiers, d'ajouts ou de suppressions poussés dans le dépôt. Le commit a une somme de contrôle cryptographique SHA-1 de 40 caractères qui est écrite dans un fichier. Chaque commit inclut également un pointeur vers le commit parent d'où il provient.

Il y a de nombreuses étapes intermédiaires supplémentaires, par exemple, les fichiers sont convertis en blobs binaires avec somme de contrôle et organisés dans des répertoires à travers un arbre binaire. La somme de contrôle de l'arbre est également calculée. Comme tout est haché cryptographiquement, il n'y a aucun moyen de modifier (ou de corrompre) les données ou l'historique sans changer la somme de contrôle du dernier commit. Le hachage cryptographique rend l'historique de Git quelque peu permanent, alors soyez poli en écrivant des messages de commit !

[Mode nerd DÉSACTIVÉ]

Flux de travail dans Git pour le matériel

Grâce à la nature distribuée de Git pour le matériel et le système de branchement avancé, ainsi qu'à une multitude d'autres fonctionnalités, les utilisateurs sont libres d'adopter n'importe quel flux de travail.

Parmi les plus populaires, le modèle de *Flux de travail Centralisé* est souvent utilisé lorsque les personnes ayant de l'expérience avec le système de contrôle de version centralisé commencent à utiliser Git (qui est *décentralisé*) pour la première fois. Le *Flux de travail Centralisé* repose presque exclusivement sur la branche master, où tous les commits sont poussés et récupérés, faisant ainsi de Git un mimétisme du comportement de SVN et des systèmes de fichiers distants.

Le workflow Feature Branching est une évolution du *Workflow Centralisé*. Le travail de développement est effectué sur des branches séparées qui sont ensuite fusionnées dans une branche principale. Je suis un fervent défenseur de ce modèle en ingénierie électronique, et j'attends avec impatience qu'Altium annonce leur support de branches pour pouvoir en profiter. Des exemples de branches de fonctionnalités pourraient être “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption”, ou “reduce_thermal_drift”.

Dans le workflow GitFlow, peut-être le plus complexe parmi les workflows populaires, la branche principale ne contient que des versions de conception complètes, vous pouvez la considérer comme board_v_1.0, board_v_1.1, etc. Le développement est réalisé sur une branche séparée appelée develop, et les fonctionnalités et corrections découlent de la branche develop. Seule la branche develop peut être fusionnée dans la principale une fois qu'elle est prête.

Décentralisation et Vitesse

Git est plus rapide que d'autres systèmes de contrôle de version pour plusieurs raisons. Chaque utilisateur peut cloner le dépôt original, et des commits peuvent être régulièrement effectués sur des branches locales et envoyés moins fréquemment au dépôt distant. D'autres VCS qui ne sont pas aussi décentralisés sont limités par la capacité du serveur distant, qui doit considérablement ralentir pour satisfaire toutes leurs demandes.

Cette approche locale d'abord est particulièrement cruciale dans l'industrie électronique, car les fichiers peuvent être assez volumineux. Il n'est pas rare qu'une conception de PCB atteigne des dizaines de mégaoctets, surtout avec des centaines de corps 3D. Les fichiers de code source, en revanche, ont tendance à être de quelques centaines de Ko tout au plus.

Dans la dernière entreprise pour laquelle j'ai travaillé, nous avions un dépôt SVN hébergé dans les bureaux principaux, accessible via un VPN, où nous stockions les fichiers de projet et la documentation. Cela prenait une éternité pour effectuer la moindre opération, et notre connexion internet limitée était fréquemment saturée par toutes les demandes pour gérer les milliers de fichiers.

Git est également écrit en langage C, ce qui signifie que son surcoût est minimal par rapport à d'autres langages de haut niveau. Selon l'opération, Git peut être de quelques fois à des centaines de fois plus rapide que SVN.

L'approche décentralisée, privilégiant le hors-ligne, rend également Git beaucoup plus léger sur le réseau. Même si votre entreprise n'a pas accès à la large bande, vous pouvez pousser les données à l'heure du déjeuner ou après le travail, sans perte de performance dans le travail quotidien.

Sur Concord Pro, vous pouvez profiter de tous les avantages d'Altium 365 lorsque vous avez accès à une connexion internet, puis emporter votre licence Altium Designer et continuer à travailler hors ligne.

Zones de Staging

Lorsque vous travaillez avec Git, il est essentiel de réaliser que les fichiers passent par trois étapes avant qu'ils ne puissent être réellement considérés comme étant sous contrôle de version :

1. Non suivi
2. En préparation
3. Validé

Non suivi est lorsque le fichier existe sur le disque, mais est hors du système de contrôle de version. Le fichier non suivi peut ensuite être en préparation, ce qui signifie qu'il a été ajouté au système de contrôle de version mais pas encore validé. À ce stade, les modifications en préparation peuvent être validées. Le système de préparation est utilisé pour préparer la validation, mais cette fonctionnalité est utilisée principalement dans l'opération en ligne de commande.

Lors de l'utilisation de Git via Altium, grâce à l'interface utilisateur graphique qui simplifie l'opération, l'approche de préparation est appliquée automatiquement en arrière-plan lorsque vous enregistrez les modifications sur le serveur.

Création d'un dépôt

Les dépôts sont automatiquement créés côté serveur lorsque vous créez un nouveau projet. Dans la fenêtre ci-dessous, je crée un nouveau projet de PCB à partir d'un modèle au sein de mon espace de travail Fermium LTD. Dès que je crée le projet, il sera accessible dans mon espace de travail Altium 365, et la plateforme créera automatiquement un dépôt Git pour le nouveau projet.

Configuration initiale du dépôt

Les dépôts créés avec Concord Pro sont automatiquement configurés, de sorte que seuls les fichiers essentiels sont déjà validés dans le dépôt Git du projet, tandis que les sauvegardes locales et les fichiers LOG ne le sont pas. Il serait généralement nécessaire de configurer un fichier appelé ".Gitignore" de manière appropriée et de prendre soin de ne pas valider des fichiers inutiles, mais Concord Pro s'en occupe.

Configuration des identifiants

Pour accéder aux dépôts Git, il serait généralement nécessaire de configurer des clés SSH et des identifiants utilisateur à la fois côté serveur et côté client. Concord Pro s'occupe de cela automatiquement lorsqu'un nouvel utilisateur est ajouté.

Clonage de dépôts

Le clonage est le processus par lequel Git réplique le dépôt distant en une copie locale. Cloner manuellement de grands dépôts contenant des fichiers binaires, tels que les fichiers PcbDoc et SchDoc, nécessiterait normalement une opération en ligne de commande de niveau expert avec Git. Altium Designer et Concord Pro clonent automatiquement le dépôt sur votre machine locale en arrière-plan lorsque vous ouvrez un projet distant.

Résolution de conflits et comparaison des modifications

Concord Pro vous permet de comparer les modifications entre différentes révisions, locales et distantes, via le panneau de gestion de stockage. Dans l'exemple suivant, j'ai ajouté un objet de note textuelle et j'ai commité les modifications localement, mais je ne les ai pas poussées vers le distant.

Cela nous donne la fonctionnalité complète nécessaire dans une plateforme Git pour le matériel.

Conclusions

Git est un outil formidable, et git pour le matériel offre aux concepteurs de PCB un flux de travail complet pour le contrôle de version, le partage et la gestion des révisions. Ce système populaire a contribué à façonner la culture des programmeurs modernes. Maintenant, avec Altium Designer® et la plateforme Altium 365®, les concepteurs peuvent accéder aux fonctionnalités de Git pour la conception de PCB.

Vous pouvez commencer un essai d'Altium 365 aujourd'hui, chargé avec des projets d'exemple, pour vivre pleinement le développement électronique au style du 21e siècle. Vous avez d'autres questions ? Parlez à un expert chez Altium aujourd'hui.