Git est un outil merveilleux qui peut multiplier l’impact de votre projet ou rendre votre projet plus facile à gérer d’un ordre de grandeur. Certains d’entre nous, les hackers, ne savent pas encore comment utiliser Git en ligne de commande, mais un exemple relatable de l’utilité d’un certain outil pourrait être un bon début. Aujourd’hui, j’aimerais vous donner un cours accéléré sur Git – vous montrant pourquoi et comment mettre un PCB KiCad dans un référentiel Git, pour ensuite le partager avec le monde.
KiCad fonctionne à merveille avec Git. Les fichiers schématiques et PCB de KiCad sont lisibles par l’homme, en particulier par rapport à d’autres formats de fichiers PCB. KiCad crée différents fichiers à des fins différentes, chacun d’eux avec un rôle bien défini, et vous pouvez donner un sens à chaque fichier dans votre dossier de projet. De plus, vous pouvez même modifier les fichiers KiCad dans un éditeur de texte ! C’est exactement le genre de cas d’utilisation auquel Git va comme un gant.
Pas seulement pour les développeurs de logiciels
De quoi parle Git, alors ? Fondamentalement, Git est un outil qui vous aide à suivre les modifications de code dans un projet et à partager ces modifications entre vous. Destiné au développement du noyau Linux comme première cible, c’est pour cela qu’il a été conçu, mais sa flexibilité s’étend bien au-delà des projets logiciels. Nous, les hackers de matériel, pouvons l’utiliser de différentes manières – nous pouvons stocker des fichiers de PCB et d’autres logiciels de conception, des articles de blog, de la documentation de projet, des notes personnelles, des fichiers de configuration et tout ce qui correspond même vaguement au mode opératoire de Git.
Le premier avantage que vous retirerez de l’utilisation de Git est une sauvegarde de votre projet. En fait, si vous téléchargez vos modifications git quelque part, vous obtenez deux copies supplémentaires de votre projet – une stockée dans votre local .git dossier, et un téléchargé à un endroit comme GitHub ou GitLab. En effet, un projet stocké dans Git avec un miroir en ligne se conforme automatiquement au principe de sauvegarde 3-2-1. De plus, vous obtenez des sauvegardes historiques à portée de main. Vous avez repensé votre PCB il y a longtemps et vous avez maintenant un besoin urgent de vous référer à une version antérieure ? Tant que vous avez conservé vos modifications dans Git, elles sont accessibles en une seule commande.
De nombreuses personnes stockent également des fichiers de configuration dans Git – vous avez peut-être entendu parler de cette pratique appelée dotfiles. Cela vous aide à garder une trace de toutes les modifications de configuration que vous apportez. Si vous avez déjà débogué un logiciel complexe (par exemple, un serveur Web) en recombinant des paramètres dans son fichier de configuration, vous saurez à quel point il peut être douloureux d’oublier un changement qui fonctionnait auparavant – et de perdre une configuration méticuleusement adaptée. fichier est une douleur à un tout autre niveau. Avec quelques commandes Git à votre actif, vous évitez un monde de douleur que vous n’auriez peut-être jamais imaginé pouvoir éviter.
Souvent, nous, les hackers, avons besoin de l’aide les uns des autres – et dans de tels cas, les capacités de collaboration de Git sont inégalées. Disons que vous vous retrouvez à travailler sur un projet PCB avec un autre hacker à travers le monde. Avec Git, vous n’avez besoin que d’une seule commande pour télécharger vos dernières modifications, et votre collègue n’a besoin que d’une seule commande pour les télécharger. Si vous avez tous les deux apporté des modifications d’une manière conflictuelle (par exemple, modifié la même empreinte d’une manière différente), Git dispose d’une boîte à outils riche pour la résolution des conflits d’ensemble de modifications, libérant ainsi un temps précieux que vous pourriez tous les deux passer à discuter de la conception de haut niveau. problème.
Hacker, rencontrez Git – Git, rencontrez Hacker
Pour commencer, vous avez un projet PCB et vous avez installé un shell Git sur le système d’exploitation de votre choix. Je suppose également que vous connaissez les bases de votre terminal – passer d’un répertoire à l’autre et ouvrir des fichiers, nous n’aurons pas besoin de beaucoup plus. Git a besoin de quelques petites variables configurées avant de pouvoir commencer – réglons cela et utilisons cela comme une opportunité de tester cela git Fonctionne également dans la console de votre choix.
Pour suivre vos modifications, Git veut connaître votre nom et votre adresse e-mail – ceux-ci n’ont pas besoin d’être réels. Si vous poussez vos modifications vers GitHub/GitLab/etc, le nom et l’e-mail seront accessibles à toute personne pouvant télécharger le contenu du référentiel à partir duquel vous les avez téléchargés, c’est-à-dire généralement n’importe qui. J’utilise mon surnom et mon ancienne adresse e-mail publique pour cela, à des fins de collaboration et de « contactez-moi à propos de ce projet » – vous pouvez faire de même, ou simplement utiliser les valeurs par défaut de John Doe si vous ne téléchargerez jamais. Voici les commandes que vous devez exécuter, extraites d’ici :
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Étant --global, ces modifications ne doivent être effectuées qu’une seule fois sur chaque machine que vous utilisez pour le travail Git. En plus de ces deux éléments, il est utile de faire savoir à Git quel éditeur de texte vous préférez pour effectuer des modifications rapides – ceux-ci seront appelés de temps en temps. Sous Linux, vous constaterez peut-être que votre éditeur par défaut pour git commit est déjà défini sur Vi – si vous ne savez pas quoi :wq! représente, n’hésitez pas à courir courir git config --global core.editor nano pour une option plus conviviale. Sous Windows, vous voudrez faire les choses un peu différemment.
Maintenant, vous êtes prêt à commencer. Dans votre terminal, déplacez-vous dans le dossier où votre projet PCB est stocké. Taper git init et appuyez sur Entrée. C’est tout – votre dossier de projet est maintenant un référentiel Git !
Ajout de vos modifications
À partir de là, Git ne garde pas encore une trace de vos fichiers de projet. Courir git statuset voyez un tas de fichiers marqués comme « non suivis ». git status vous indique utilement ce qu’il faut faire pour commencer à les suivre – en fait, cette commande fait pas mal de prise en main pour les nouveaux arrivants de Git, comme vous pouvez le voir sur la sortie. Ajoutons les fichiers qui nous intéressent – c’est-à-dire tout sauf le .kicad_prl dossier et le -backups/ annuaire!
$ git add jolly_wrencher.svg $ git add jolly_wrencher.kicad_mod $ git add jolly_wrencher_pcb.kicad_pro $ git add jolly_wrencher_pcb.kicad_pcb $ git add jolly_wrencher_pcb.kicad_sch $ git status
Ces fichiers ont été ajoutés à la liste que Git surveille, mais ils ne sont pas encore intégrés à l’historique Git du projet d’une manière qui compte. Pour cela, nous devons faire un commit, qui enregistre un groupe de modifications de fichiers. En démarrant un référentiel comme celui-ci, vous ferez généralement un commit « initial » – pour cela, vous pouvez exécuter git commit -m "Initial commit"où le -m Le paramètre est un message lisible par l’homme décrivant la signification des modifications. Vous pouvez aussi faire git commit et écrivez le message dans un éditeur séparé – voyez ce qui vous convient le mieux. Étant donné que les fichiers n’ont pas été validés auparavant, ils seront stockés dans leur intégralité.
Un peu d’engagement
Un commit est une sorte d' »unité de travail », un moyen de regrouper logiquement les changements. Vous pouvez naviguer entre les commits dans l’historique de votre projet à différentes étapes du développement de votre projet, séparer certains ajustements contenus dans les commits dans une branche différente afin que vous puissiez faire coexister plusieurs versions différentes de votre projet de manière transparente, transférer les commits entre les référentiels, les exporter et les envoyer par e-mail , et bien plus.
Il est logique de conserver des changements logiquement distincts dans différents commits. Supposons que vous améliorez la sérigraphie sur votre PCB et que vous ajoutez également un fichier de licence. Tout d’abord, vous ajoutez votre .kicad_pcb fichier et validez-le avec le message « sérigraphie : pinouts ajoutés » ; ensuite, vous ajoutez votre LICENSE.txt fichier et validez-le en tant que « licence ajoutée ». Cela vous aide à avoir un aperçu de l’historique de votre projet, à suivre les erreurs et une myriade d’autres choses.
Si tu cours git log, vous verrez la liste des commits. En utilisant leur hachage, vous pouvez vous déplacer entre les commits lorsque vous avez besoin d’une ancienne version de votre projet. Pour cela, faites git checkout HASHCHARS, où « HASHCHARS » correspond à au moins sept premiers caractères (peut-être plus !) de votre hachage de validation. Pour revenir au dernier état de votre projet, faites git checkout HEAD.
Pas besoin de tout suivre
git status nous montre encore le .kicad_prl et le répertoire de sauvegarde que nous n’avons pas besoin de suivre – ces deux-là ne contiennent pas de modifications significatives. Pour ignorer ces deux types de fichiers, créez un .gitignore fichier (nom commençant par un point) dans le répertoire principal de votre projet, et placez-y ces deux entrées :
*.kicad_prl *-backups/
Comme vous pouvez le voir, vous pouvez y faire une correspondance de modèle très simple, mais vous pouvez également mettre les noms de fichiers de projet réels – je ne voulais pas les taper, et la version plus générique sera pratique si vous voulez copier- pâte. git status cessera déjà d’afficher ces fichiers, et au fur et à mesure que vous ajoutez et validez le .gitignore fichier, ces deux entrées resteront. Vous voulez un fichier gitignore spécifique à KiCad qui couvre la plupart des cas que vous rencontrerez ? GitHub en propose un.
Git ne comprend pas les fichiers binaires – il est conçu pour les fichiers texte lisibles par l’homme qui changent de manière significative. Les fichiers KiCad PCB répondent à ces critères – beaucoup d’autres fichiers ne le font pas. Le fait est que chaque version d’un fichier binaire restera indéfiniment comme une copie à l’intérieur de votre .git dossier, restant longtemps après que vous ayez mis à jour le fichier binaire avec une nouvelle version. Vous ne voulez pas stocker un .zip qui change fréquemment dans le référentiel git de votre projet, et vous ne voulez pas non plus y stocker de fichiers gerber. Cela prend juste plus d’espace et de temps.
Fonctionnalités supplémentaires sans frais
Les capacités de gestion des versions de git sont pratiques dans le développement de PCB, et il existe de nombreuses subtilités qui le rendent encore plus confortable à utiliser. Par exemple, si vous souhaitez passer plus rapidement d’une version de projet à l’autre, vous pouvez attacher des balises aux commits. Avez-vous développé une v2 de votre PCB, mais devez-vous toujours vous référer aux fichiers v1 pour des raisons de support client ? Fais git tag v2 pour marquer le commit actuel comme « v2 », et faire git tag commit v1 HASHCHARS pointant vers un commit où votre PCB était encore à v1. Maintenant, vous pouvez faire git checkout v1 et git checkout v2 pour passer d’une version à l’autre au besoin.
Disons, hypothétiquement, que vous avez commis une README.md fichier – une bonne pratique (n’hésitez pas à utiliser mon modèle PCB README !). Disons également, pour les besoins de l’argument, que vous venez d’ajouter quelques images dans votre répertoire de projet et de les lier dans le README. Supposons que vous ayez également modifié le README pour ajouter des modifications totalement indépendantes qui appartiennent à un commit séparé – peut-être avez-vous modifié un connecteur sur le PCB et reflété cela dans le README. Comment séparez-vous les modifications logiquement différentes que vous venez d’apporter au même fichier ? Utilisation git add --patch README.md pour sélectionner et choisir de manière interactive les parties du fichier à ajouter.
Vous avez commité quelque chose et vous voulez modifier le message du dernier commit ? Utilisation git commit --amend. Besoin d’ajouter/supprimer/modifier des fichiers dans le dernier commit ? Ajoutez vos modifications et commit --amend. Vous avez apporté des modifications à un fichier et souhaitez vous en débarrasser au lieu d’en ajouter ? Utilisation git checkout path/to/file – vous perdrez ces modifications car le fichier reviendra à sa version actuellement suivie. Oh, vous pouvez aussi utiliser --patch avec git checkout pour l’annulation partielle des modifications.
Git a beaucoup de sous-commandes utiles. Si vous souhaitez voir les modifications actuelles apportées à vos fichiers de projet dans la console, utilisez git diff. Avez-vous déjà ajouté certaines des modifications et elles ne s’afficheront pas ? Utilisation git diff --cached. Ces deux commandes acceptent les noms de fichiers pour une vue d’ensemble plus ciblée. Il y a beaucoup de complexité dont Git est capable, étant un outil viable pour les plus grands efforts de développement de logiciels distribués. Vous n’avez en fait pas besoin d’utiliser l’une des fonctionnalités sophistiquées si vous ne le souhaitez pas non plus.
Étape suivante : télécharger
Comme vous pouvez le voir, je n’ai pas couvert le téléchargement vers un référentiel en ligne ou le travail avec d’autres ; ce sont des sujets avec quelques mises en garde importantes. J’aimerais également couvrir GitLab ainsi que GitHub, afin que vous ne soyez pas enfermé dans un seul écosystème. Je n’ai pas non plus couvert les branches – un projet PCB typique n’a pas besoin de cela, mais nous pourrions en parler dans un prochain épisode. Pourtant, vous pouvez l’apprendre au fur et à mesure. Vous êtes maintenant équipé pour utiliser Git pour des projets simples !
