La dernière fois, je vous ai montré comment créez un référentiel Git local autour de votre projet PCB. Cela seul vous fournit des sauvegardes locales, vous aidant à ne jamais perdre les modifications que vous apportez à vos fichiers et à toujours être en mesure de revoir l'historique de votre projet au fur et à mesure de son développement.
Cependant, une partie encore plus importante de l'utilité de Git est la possibilité de télécharger nos créations sur l'un des différents services d'hébergement de référentiel Git en ligne et de le maintenir à jour à tout moment avec une seule commande shell. J'aimerais vous montrer comment télécharger votre projet sur GitHub et GitLab, en particulier !
résumer
Tout d'abord, récapitulons ce qui se passe dans la création d'un référentiel. Voici une séquence de commandes auxquelles vous pouvez vous référer - ces commandes ont été expliquées dans le dernier article, elles sont donc là au cas où vous auriez besoin d'une feuille de triche.
# setting up identity - these are public, and can be fake git config --global user.name "John Doe" git config --global user.email [email protected] # initializing a repository git init . git branch -M main # before your first commit, you add your .gitignore file # then, add files as needed - use 'git status' to check in git add board.kicad_pcb [...] git add README.md # or, given proper .gitignore, you can just do this: git add . # put your added changes into a commit git commit # an editor will open to write your commit message
Que faire si vous n'avez pas de projet PCB à portée de main ? Voici un référentiel avec une carte Jolly Wrencher SAO que vous pouvez le télécharger sous forme d'archive .zip via l'interface GitHub. C'est déjà un référentiel - si vous souhaitez tester ces commandes mais que vous n'avez pas encore de projet PCB à portée de main, vous pouvez librement pousser ce référentiel vers votre propre compte GitHub ou GitLab en tant qu'exercice de test ! Si vous souhaitez recommencer à zéro et pratiquer également la partie "création du référentiel", supprimez simplement le .git répertoire à la racine du projet.
Quelle est la différence?
GitHub et GitLab agissent tous deux comme des interfaces pour votre référentiel. Ils fournissent également un endroit supplémentaire pour vider votre code - vous pouvez également simplement utiliser un lecteur flash ou un serveur avec un compte SSH. Mais l'hébergement vous donne une interface Web où d'autres personnes peuvent jeter un œil à votre code et à son README afin qu'elles sachent si votre code les intéresse, vous posent des questions, partagent leurs propres modifications de code avec vous, téléchargent tous les fichiers supplémentaires associés (comme gerbers) que vous avez peut-être téléchargés et faire une myriade d'autres choses utiles. Vous n'avez besoin d'utiliser aucune de ces fonctionnalités - vous pouvez toutes les désactiver, mais elles sont là dès qu'elles peuvent vous être utiles.
GitHub est la plate-forme la plus connue et a été un pionnier à bien des égards. Une grande partie des actions de piratage logiciel et matériel à petite échelle se déroulent sur GitHub, et de nombreux référentiels auxquels vous pourriez être intéressé à contribuer seront également là. Il y a beaucoup de tutoriels qui fonctionnent avec GitHub, et des outils amusants comme cette interface utilisateur GitHub en ligne de commande nous avons couvert.
GitLab est une plate-forme moins connue mais non moins utile que vous pouvez utiliser pour votre code, vos PCB et vos documents, et elle présente des avantages importants par rapport à GitHub. Tout d'abord, le logiciel GitLab lui-même est entièrement open-source, vous pouvez donc l'auto-héberger, et beaucoup le font. Ce n'est pas le seul service auto-hébergé, mais c'est l'un des plus importants et des plus complets. Tout comme WordPress étant à la fois une suite logicielle et une plate-forme, vous n'avez pas à l'auto-héberger. Si vous voulez un endroit pour héberger vos référentiels, vous pouvez aller sur gitlab.com et enregistrez un compte, tout comme les gens le font avec GitHub.
Il existe une variété d'interfaces pour l'hébergement de référentiels accessibles par navigateur en ligne - Gitea est une autre que vous rencontrerez de temps en temps et peut facilement s'auto-héberger, et il existe une multitude d'autres interfaces que les gens utilisent au fil des ans. En connaissant le fonctionnement de deux de ces frontaux de premier plan, leurs points communs et leurs différences, vous vous retrouverez rapidement dans n'importe quel autre frontend.
L'inscription sur les deux sites Web est un peu similaire. Formulaire d'inscription de GitHub est excessivement flashy - il est clair qu'ils ont investi pas mal d'argent et d'efforts pour le faire, mais il n'est pas clair si c'était le bon choix. Processus d'enregistrement de Gitlab est beaucoup plus calme et ressemble généralement plus à ce que vous attendez d'un site Web ordinaire. À certains moments, les deux vous demanderont de confirmer votre adresse e-mail - après cela, votre compte sera prêt à être utilisé.
Création de référentiel
Sur les deux plates-formes, vous devrez d'abord créer un référentiel et l'enregistrer auprès de la plate-forme. Vous ne pouvez pas simplement télécharger du code sur votre compte à partir de la ligne de commande sur un coup de tête - le référentiel correspondant doit être créé côté plate-forme avant de pouvoir le télécharger. Heureusement, il existe des outils en ligne de commande pour vous aider dans l'étape de "création" !
Les processus de Github et de Gitlab sont similaires, chacun offrant des fonctionnalités de qualité de vie. Sur les deux, le bouton "Nouveau référentiel" est assez apparent, et en cliquant dessus, vous êtes invité à saisir le nom du référentiel - sur GitHub, également une description facultative. Sur GitLab, vous voudrez utiliser l'option "Créer un projet vierge". Les options pour ajouter un README, .gitignore et la licence peut être utile. Si vous n'en avez pas dans le référentiel, n'hésitez pas à cocher ces cases ou à appuyer sur ces boutons ; ne cochez aucun d'entre eux si vous utilisez les fichiers Jolly Wrencher comme exercice, à moins que vous ne recherchiez un ajustement de difficulté dans votre parcours d'apprentissage Git.
GitHub et GitLab vous donnent tous deux utilement un tas d'instructions en ligne de commande sur la façon de procéder au téléchargement de votre référentiel local. La moitié de ces instructions concernent l'ajout d'un README très simple et la réalisation de votre premier commit. Avoir un fichier README dans votre dossier de projet PCB est une bonne pratique, bien qu'en avoir un vide ou une seule ligne soit peut-être un peu décevant pour les visualiseurs de votre référentiel. Si vous ne vous souciez pas du fait que les gens consultent votre référentiel, ne vous en souciez pas.
Les lignes importantes sont les git remote et git push ceux, avec git branch Être utile. C'est là que la magie du téléchargement se produit. git remote est la commande que vous utilisez pour gérer vos miroirs Git distants, c'est-à-dire non locaux, pour un référentiel donné, et git push est la commande que vous utilisez pour envoyer les modifications de votre référentiel vers un miroir. git branch -M main renomme votre branche principale en 'main' - la plupart des tutoriels utilisent aujourd'hui 'main', ce qui vous facilitera un peu la vie.
Un petit détour d'authentification
Avant de pouvoir pousser, cependant, nous devons trier l'authentification - comme dans, comment montrer à la plate-forme que la personne qui exécute cette ligne de commande est une personne autorisée à télécharger des données dans ce référentiel. Les deux plates-formes y parviennent de différentes manières. Pour GitHub, le combo habituel login-plus-password ne suffira pas - étant une plate-forme où les gens partagent le code utilisé par des millions de personnes, principalement textuellement et sans vérification, ils ont renforcé leurs défenses et mis plus de responsabilités sur nos épaules.
Vous avez deux voies pour télécharger sur GitHub. Soit tu y vas la route HTTPS, et puis toi créer un jeton que vous utilisez à la place de votre mot de passe. Alternativement, vous suivez la route SSH, ce qui signifie que vous générez et téléchargez une clé publique que vous utilisez pour l'authentification. Ce sont deux options sécurisées et elles sont primordiales si quelqu'un d'autre dépend de l'absence de logiciels malveillants dans votre code. Cela dit, on pourrait dire qu'ils sont exagérés pour télécharger quelques PCB. Ces deux options sont quelque chose que vous peut faire une fois et oublier, GitHub propose de courts didacticiels pour vous aider à configurer l'une de ces méthodes, ainsi que des outils tels que GitHub Desktop ou GitHub CLI. s'en occuper pour vous.
GitLab, cependant, n'hésite pas à vous laisser télécharger en utilisant le même mot de passe que celui que vous avez utilisé pour créer votre compte. L'utilisation de clés au lieu de mots de passe présente des avantages en matière de sécurité : elles ne sont pas brutales, elles peuvent être facilement révoquées et compromettre une clé SSH ne met pas en danger l'intégralité de votre compte. De plus, vous pouvez (et devriez) protéger vos clés par mot de passe. Il y a aussi un confort indéniable à n'utiliser qu'un mot de passe - vous n'avez pas besoin de stocker un jeton ou d'enregistrer une clé SSH pour chaque machine à partir de laquelle vous souhaitez travailler.
Les clés SSH sont sympas. Pour " votre propre ordinateur ", ils sont à bien des égards plus agréables que l'authentification par mot de passe. Si vous êtes sous Linux, vous obtenez des clés SSH gratuitement, et je vous recommande de comprendre comment les utiliser - vous utilisez probablement déjà votre clé pour SSH dans votre sympathique Raspberry Pi ; il en va de même pour MacOS. Sous Windows, il existe des tutoriels sur la façon de générer une clé SSH que vous pouvez utiliser avec Git.
Enfin, le téléchargement
Après avoir trié le moyen d'authentification, vous devriez être prêt à télécharger votre code. Pointons votre configuration de référentiel Git local au bon endroit. Vous indiquerez à Git que ce référentiel local correspond à un référentiel distant, familièrement appelé 'distant'.
Si vous avez une télécommande, elle s'appelle généralement "origine" - c'est juste une convention, vous pouvez la nommer comme bon vous semble ; vous pouvez avoir plusieurs télécommandes, mais si vous l'appelez "origine", la compatibilité du didacticiel sera encore meilleure. GitHub et GitLab vous donneront tous deux l'URL à utiliser comme URL distante, selon que vous avez choisi l'authentification HTTPS ou SSH - GitLab ne vous donnera pas d'URL SSH tant que vous n'aurez pas téléchargé une clé SSH, alors que GitHub se fera un plaisir de vous donner les URL mais vous ne pourrez pas les utiliser.
Quel que soit votre choix, exécutez la commande git remote add origin YOUR_URL, en remplaçant VOTRE_URL par l'URL que vous utilisez, bien sûr. Cela indique à votre référentiel Git où télécharger, et vous n'êtes plus qu'à une commande d'avoir vos fichiers en miroir en ligne. Au début, cette commande sera git push -u origin main - pour toutes les poussées ultérieures, il sera juste aussi court que git push.
Si vous avez décidé d'ajouter un README, un fichier de licence ou un .gitignore fichier, vous voudrez réellement faire git pull avant de git push. En effet, ces fichiers ont été ajoutés par GitHub/GitLab en tant que commits séparés dans votre référentiel, et ils n'existent pas encore dans votre référentiel local, ce qui signifie que vous avez deux référentiels avec un historique de validation divergent. Dans ce cas, votre référentiel absorbera les modifications en amont et les enregistrera au-dessus de votre fichier.
Après avoir fait le premier push dans votre référentiel, vous pouvez maintenant ouvrir votre page de référentiel GitHub/GitLab dans le navigateur et voir vos fichiers téléchargés là-bas. La prochaine fois que vous apporterez et validerez vos modifications, les synchroniser avec votre ordinateur sera un simple git push une façon.
Quelques rappels
Si vous poussez puis utilisez commit --amend pour arranger les choses, vous voudrez git push --force, puisque le dernier commit aurait été modifié, régénérant son hachage et le rendant incohérent avec le dernier commit que vous venez de pousser dans le référentiel distant. Cela dit, forcer les poussées est généralement déconseillé, et vous feriez mieux de faire un commit supplémentaire par la suite. Ceci est surtout pertinent si vous travaillez avec d'autres, car ils peuvent avoir extrait de votre référentiel entre vous en poussant le commit d'origine et celui modifié.
Si jamais vous avez besoin de télécharger votre référentiel sur un autre ordinateur, la commande que vous pouvez utiliser est git clone suivi de l'URL. L'option "Télécharger ZIP" est viable, mais vous n'avez pas toujours une interface utilisateur Web à portée de main - par exemple, sur des installations sans tête, comme un Raspberry Pi, vous pourriez configurer avec un logiciel auto-écrit ou fourni utilement.
Pour moi personnellement, comme j'utilise beaucoup la ligne de commande, je trouve git clone être une option beaucoup plus rapide par rapport au téléchargement ZIP. Si le référentiel est public, l'utilisation de l'URL HTTPS pour le cloner ne nécessitera aucune authentification - en fait, sur GitHub et GitLab, vous pouvez git clone l'URL du référentiel telle que vous la voyez dans votre navigateur. Essaie git clone https://github.com/CRImier/jolly_wrencher_sao par exemple.
Partagé pour que tout le monde puisse apprendre
GitHub et GitLab sont tous deux de bonnes options pour un pirate informatique qui cherche à garder quelques projets PCB en ligne, et vous pouvez toujours faire tourner un serveur privé si besoin est. Le processus de téléchargement peut être un peu compliqué à configurer, mais une fois que vous l'avez configuré, vous êtes à trois commandes d'obtenir la version la plus récente de votre conception de PCB en ligne et disponible pour toutes les personnes intéressées. La prochaine fois, j'aimerais montrer comment deux hackers ou plus peuvent collaborer sur des projets PCB en utilisant Git !
Jeu de briques
Snake
Pacman
Bubble