Git et Github : Guide du débutant pour les débutants complets

Malgré ce que la télévision et les films nous disent, la vie de développeur de logiciels n'inclut pas de rester assis dans une pièce sombre, notre clavier éclairé uniquement par la lueur du moniteur, l'idée d'interagir avec un autre être humain répugnante. Non, la vie de développeur de logiciels est sociale et collaborative, parfois jusqu'à la frustration. C'est pourquoi nous avons git et Github.

Git est un logiciel de contrôle de version qui rend la collaboration avec des coéquipiers très simple… une fois que vous avez dépassé la courbe d'apprentissage initiale. Cela peut être intimidant, mais c'est pourquoi je suis ici !

Qu'est-ce que Git ?

Eh bien, ce n'est pas seulement la façon dont nous, les sudistes, chassons les vermines de nos porches, je vais vous le dire.

Comme je l'ai dit plus haut, Git est un logiciel de contrôle de version. Il a été créé par Linus Torvalds, le gars qui a inventé Linux. Vous n'avez pas besoin d'exécuter Linux pour utiliser git, vous pouvez également l'utiliser sur Windows et Mac.

Git vous permet de suivre facilement chaque révision que vous et votre équipe faites pendant le développement de votre logiciel. Vous partagez tous un référentiel de code sur lequel vous travaillez indépendamment, puis fusionné. Vous n'avez pas non plus besoin d'être connecté tout le temps car le projet est à la fois enregistré localement sur chaque machine et à distance (probablement sur Github).

Git est spécial (et pratiquement obligatoire) car vous pouvez revenir à n'importe quelle version précédente de votre code, bifurquer et développer une fonctionnalité spécifique sans affecter quoi que ce soit ni personne d'autre, et maintenir la sécurité contre la corruption des données en raison de sa nature distribuée.

Il fournit également un cryptage et une compatibilité entre les systèmes d'exploitation faciles à mettre en œuvre, ainsi que des flux de travail asynchrones et non linéaires afin que, où que vous soyez, vous puissiez travailler sur certains aspects de votre projet.

Fondamentalement, si vous n'utilisez pas git, vous codez avec une main attachée dans le dos.

Vocabulaire requis

Lorsque vous commencez à utiliser git, cela peut être intimidant. Les commandes et les concepts peuvent sembler totalement étrangers si vous n'avez jamais utilisé aucune forme de contrôle de version dans le passé. Vous les ramasserez très vite, cependant.

Dépôt:

Souvent appelé repo . Un référentiel est la collection de fichiers et de dossiers que vous utilisez git pour suivre. Le référentiel comprend l'historique complet des modifications apportées par votre équipe au projet. C'est la grande boîte dans laquelle vous et votre équipe jetez votre code.

Github :

La solution de stockage à distance la plus populaire pour les dépôts git. Il vous permet également de définir des autorisations d'accès pour les projets, de suivre et de soumettre des bogues, d'accepter des demandes de fonctionnalités, de vous abonner aux notifications de référentiel et d'utiliser une interface graphique, plutôt que d'utiliser la ligne de commande. Les dépôts par défaut sont publics, mais les comptes payants peuvent avoir des comptes privés.

S'engager:

Considérez cela comme une sauvegarde de votre travail. Lorsque vous vous engagez dans un référentiel, c'est comme si vous rassembliez les fichiers tels qu'ils existent à ce moment-là et que vous les mettiez dans une capsule temporelle. Le commit n'existera que sur votre machine locale jusqu'à ce qu'il soit poussé vers un référentiel distant.

Pousser:

Pousser est le pain au beurre de l'engagement. S'engager jette vos fichiers dans la capsule temporelle, et pousser est ce qui lance la capsule dans l'espace. Le push consiste essentiellement à synchroniser vos commits sur le cloud (encore une fois, probablement Github). Vous pouvez également pousser plusieurs commits à la fois. Vous pouvez travailler hors ligne, engager beaucoup de travail, puis tout transférer sur Github lorsque vous serez de retour dans la civilisation avec ce doux et doux wifi.

Branche:

Vous pouvez considérer votre dépôt git comme un arbre. Le tronc de l'arbre, le logiciel qui passe en ligne, s'appelle la branche principale. C'est celui qui passe en direct. Les branches de cet arbre sont, eh bien, appelées branches. Ce sont des instances distinctes du code qui découlent de la base de code principale. Vous pouvez bifurquer vers une seule fonctionnalité ou un correctif expérimental. En vous branchant, vous pouvez préserver l'intégrité du logiciel et avoir un moyen de revenir en arrière si vous faites quelque chose de totalement dingue. Cela vous permet également de travailler sur votre tâche sans trébucher sur le chemin de votre équipe (ou sur le vôtre).

Fusionner:

Lorsqu'une branche est peaufinée, exempte de bogues (pour autant que vous puissiez en juger, du moins) et prête à faire partie de la base de code principale, elle sera fusionnée dans la branche principale. La fusion est exactement ce que cela ressemble: intégrer deux branches ensemble. Tout code nouveau ou mis à jour deviendra une partie officielle de la base de code. Toute personne qui bifurque à partir du point de fusion aura également ce code dans sa branche.

Cloner:

Le clonage d'un dépôt est à peu près exactement ce que cela ressemble. Il prend l'intégralité du référentiel en ligne et en fait une copie exacte sur votre machine locale. Vous devrez le faire pour un certain nombre de raisons, notamment le démarrage au milieu d'un projet avec une nouvelle équipe, l'échange de postes de travail ou le redémarrage à partir d'un référentiel corrompu.

Fourchette:

Le fork ressemble beaucoup au clonage, mais au lieu de dupliquer un référentiel existant sur votre machine locale, vous obtenez un référentiel entièrement nouveau de ce code sous votre propre nom. Cette fonctionnalité est principalement utilisée pour prendre une base de code existante et prendre une toute nouvelle direction avec elle, ce qui arrive souvent dans les logiciels open source ; les développeurs voient une idée de base qui fonctionne, mais veulent l'utiliser différemment. Forking permet que cela se produise. Vous pouvez également jouer dans le référentiel d'un autre développeur comme s'il s'agissait de votre propre bac à sable personnel. Et si vous faites quelque chose que vous pensez qu'ils pourraient aimer, vous pouvez faire une pull request pour qu'il soit fusionné.

Demande de tirage :

Une demande d'extraction est lorsque vous soumettez une demande pour que les modifications que vous avez apportées (soit sur une branche soit sur un fork) soient extraites (ou fusionnées) dans la branche principale du référentiel. C'est le grand moment. C'est là que la magie opère. Si la pull request est approuvée, vous aurez officiellement contribué au logiciel et Github affichera à jamais exactement ce que vous avez fait. Cependant, si la demande de tirage est refusée pour une raison quelconque, le négateur sera en mesure de donner des informations sur les raisons pour lesquelles la demande a été refusée et ce que vous pouvez faire pour la faire accepter.

Mise en route et commandes requises

Ce n'était pas trop mal, n'est-ce pas ?

Droit. Maintenant que vous avez une idée claire de ce qu'est git, il est temps de creuser et de vous salir les mains.

Je devrais profiter de cette occasion pour noter, cependant, que je vais supposer que vous utilisez la ligne de commande pour interagir avec git. Bien sûr, il existe des clients git graphiques (et Github vous permet même de faire à peu près tout via son interface Web), mais pour les besoins de cet article, nous n'allons pas nous en préoccuper. Vous ferez une poignée de choses en dehors du terminal, mais la ligne de commande sera votre nouveau BFF. C'est donc aussi ce que nous allons faire.

Comment installer Git

Git n'est (probablement) pas installé sur votre ordinateur, nous devons donc l'y installer. Heureusement, l'installation de git est super facile, que vous soyez sous Linux, Mac ou Windows.

Pour Linux, ouvrez le terminal et tapez sudo apt-get install git-all (si vous êtes sous Ubuntu. Sinon, il existe une liste de toutes les commandes d'installation de packages Linux pour l'autre distribution sur laquelle vous vous trouvez.)

Sous Windows, c'est tout aussi simple. Vous téléchargez le programme d'installation et l'exécutez.

Sur Mac, il vous suffit d'ouvrir le terminal et de taper git . Si git n'est pas installé, vous verrez ceci :

Une fois que vous avez cliqué sur Installer, vous êtes prêt à partir.

Voir? Hyper facile !

Utiliser Git

C'est ici que le plaisir commence. Maintenant que vous avez installé git, il est temps de… git-r-done ! Ha ! Mais il est vraiment temps de creuser et d'apprendre à commencer à utiliser cet incroyable petit morceau de sorcellerie en ligne de commande. Et quel meilleur endroit pour commencer que Github ?

Alors allez-y et inscrivez-vous pour votre nouveau compte Github (ou connectez-vous si vous en avez déjà un, et je serai avec vous dans une seconde).

Github est gratuit pour les dépôts publics, et vous pouvez en avoir des privés pour un prix. (Pour info : vous pouvez obtenir des dépôts privés gratuits chez Bitbucket, qui est un endroit moins connu mais génial). Pour la plupart, l'option gratuite sur Github convient à la plupart des gens (et elle fonctionne aussi comme un CV vivant !), mais certains clients et employeurs auront besoin de confidentialité et de sécurité, il est donc bon d'avoir des options.

Après cela, vous êtes prêt à configurer votre premier dépôt ! Après avoir vérifié votre e-mail et tous ces trucs amusants.

Vous voudrez d'abord configurer le référentiel dans Github. Vous pouvez le faire sur votre ordinateur, puis le télécharger également, mais il est plus simple de le faire d'abord sur le Web.

Notez que je ne m'inquiète pas d'une licence ou d'un .gitignore dans ce référentiel. Parce que ce n'est pas un vrai logiciel, je n'ai pas à m'en soucier, mais dans les cas de production, .gitignore vous permet, évidemment, d'ignorer les fichiers dans le répertoire de votre référentiel. Et vous pouvez en savoir plus sur la licence dont votre logiciel a besoin ici.

Cependant, j'initialise le référentiel avec un fichier README, que vous devez utiliser pour conserver la documentation de base du projet. J'ai tendance à les utiliser comme outil de suivi des changements majeurs, des listes de tâches et de différents types de notes pendant que je travaille. Mais c'est sur des projets personnels. Différents chefs d'équipe auront des attentes différentes.

Maintenant que le référentiel existe sur Github, il est temps de le transférer sur votre machine locale via le clonage. À droite de votre dépôt, juste au-dessus de la liste des fichiers, vous verrez un bouton vert indiquant « Cloner ou télécharger ». Cliquez dessus et vous verrez ceci :

Puisque nous sommes en train de cloner, nous pouvons tout ignorer sauf la partie sur le clonage avec HTTPS. Vous n'aurez rien à configurer. Vous aurez juste besoin d'entrer votre nom d'utilisateur et votre mot de passe lorsque vous pousserez.

Cependant, vous devez d'abord configurer l'emplacement où vous souhaitez que votre référentiel vive sur votre ordinateur local. Ouvrez votre terminal. (Utilisateurs de Windows, recherchez et ouvrez un programme appelé Windows Powershell. Je vous suggère également de cliquer avec le bouton droit de la souris et de sélectionner « Exécuter en tant qu'administrateur ».)

La première commande que vous devez apprendre est ls . Cela listera tout dans le répertoire actuel. Pour simplifier les choses, faisons simplement vivre notre dossier dev dans le répertoire personnel de l'ordinateur. Vous pouvez utiliser mkdir dev pour créer un répertoire nommé dev . Assez simple, non? Si vous ls à nouveau, vous verrez le nouveau dossier répertorié.

Ensuite, vous voulez vous déplacer dans votre nouveau répertoire en utilisant cd dev , qui est la commande pour changer de répertoire . Tu vois, la ligne de commande n'est pas effrayante du tout ! Si vous avez besoin de revenir au répertoire précédent, il vous suffit d'utiliser cd .. .

Une fois que vous êtes dans votre nouveau dossier dev, il est temps de git ce parti a commencé. Hé hé hé.

Commencez par copier l'URL qui s'affiche après avoir cliqué sur le bouton vert « Cloner ou télécharger » sur Github. Cela ressemblera à quelque chose comme ceci : https://github.com/bjk1337/myfirstrepo.git

Commandes pour cloner un référentiel Git à partir de Github

• git clone https://github.com/bjk1337/myfirstrepo.git
• ls
• cd myfirstrepo - ou quel que soit le nom que vous avez donné à votre repo
• ls

Après cela, votre terminal devrait ressembler à ceci, affichant votre fichier README que vous avez configuré sur Github. Félicitations! Vous venez d'utiliser Git pour la toute première fois et vous êtes maintenant prêt à commencer à développer.

Le Nitty Gitty Graveleux

Maintenant que vous avez un dépôt sur votre machine, vous devez apprendre à l'utiliser. Alors avançons un peu et disons que vous travaillez depuis un certain temps sur un projet sympa et que vous avez des fichiers dans le répertoire. Il est temps de s'engager et de les pousser vers Github.

Ajout et validation dans un référentiel Git

• git status – Cette commande vous montrera quels fichiers n'ont pas été ajoutés à la liste pour le prochain commit. Dans la plupart des applications de terminal, les fichiers non ajoutés/ajoutés seront respectivement rouge/vert.
• git ajouter. – en ajoutant un . à la fin de la commande, vous dites à git de tout inclure dans le répertoire. Si vous souhaitez ajouter un seul fichier, utilisez simplement son nom de fichier. Tels que functions.php .
• git status - Selon si vous avez utilisé le fichier . ou le nom du fichier, tout ce que vous avez ajouté devrait être vert maintenant.
• git commit -m "ajouter trois fichiers vides" - Lorsque vous validez ces fichiers, vous devez également laisser un message rapide pour que vos coéquipiers (ou votre futur vous-même) sachent exactement ce qu'il y avait dans ce commit. Les conventions git standard disent que vous devez être aussi concis et précis que possible, et commencer le message en utilisant le présent du verbe.

Votre terminal contiendra maintenant beaucoup de texte, et il devrait ressembler à ceci. Mais maintenant vous savez ce que tout cela signifie !

Pousser vers un référentiel Git distant comme Github

Pousser vers un repo est encore plus facile que cela.

• git status – Vous devriez toujours vérifier à quoi ressemblent les choses et vous assurer que vous êtes sur la bonne branche.
• git pousser
• Entrez votre nom d'utilisateur et votre mot de passe pour Github - Attention, le champ du mot de passe restera vide, même pendant que vous tapez. C'est bon. Tapez-le simplement et appuyez sur Entrée. Si vous avez utilisé SSH, vous sauterez cette étape.

Vous pouvez accéder à votre compte Github et vérifier le dépôt, et vos fichiers seront là, les messages de validation et tout !

Branchement et fusion

Les deux dernières commandes que vous devrez maîtriser traitent du branchement et de la fusion. Comme je l'ai dit ci-dessus, travailler sur une branche protège la base de code principale, et une fois que vos modifications sont toutes parfaites, vous pouvez les fusionner à nouveau.

Ils peuvent être un peu délicats, donc il faudra peut-être un peu d'encouragement pour les amener à bien jouer.

• git checkout -b "branch1" - Cette commande créera à la fois une nouvelle branche que vous intitulez et vous y échangera en tant que branche de travail. Il combine à la fois les commandes git checkout et git branch en une seule ligne de code pratique.
• touch awesome.html - il s'agit simplement d'une commande de remplissage pour créer un nouveau fichier html que je fusionnerai dans le maître.
• Et comme avant, vous allez git status, git add awesome.html, git commit -m "create awesome.html"
• git status vous permettra à nouveau de voir que tout est comme il se doit.

Si vous essayez de le pousser avant de fusionner, vous recevrez un message indiquant que vous devez définir l'origine du référentiel. Origin est une étrange convention de dénomination pour ce que votre ordinateur considère comme le référentiel distant. Donc, en gros, vous lui dites simplement que, oui, c'est bien de pousser cette branche vers Github comme elle l'a fait pour le maître. Voici un bon fil sur git origin de Stack Overflow.

Avec cela à l'écart, il vous dira qu'il est allé à branch1 -> branch1.

Vous pouvez revenir à la branche master avec git checkout master (il n'y a pas de checkout -b cette fois parce que vous ne l'utilisez que lors de la création d'une nouvelle branche, pas d'échange. J'ai mélangé mes commandes dans la capture d'écran ci-dessous et j'ai essayé git branch master Cela n'a pas réussi car le maître existait déjà.

• git status – Comme toujours.
• git merge branch1 – Puisque tout va bien dans cette branche, nous pouvons continuer et fusionner.
• Si nous git à nouveau status , nous verrons que nous sommes en avance sur origin/master de 1 commit. Cela signifie que nous n'avons pas poussé tous les changements que nous avons apportés à Github.
• git push pour synchroniser les choses !

Vérifiez votre compte Github - vous verrez tout ce que vous avez fait y est reflété. Vous pouvez voir les différents messages de commit, le nombre de branches et de commits que nous avons créés, ainsi que tous les contributeurs au dépôt et ce qu'ils ont fait aussi.

Et c'est tout! Toutes nos félicitations! Vous venez de basculer votre workflow git de base. Vous pouvez faire beaucoup, beaucoup, beaucoup plus de choses complexes que cela avec git, mais cela est assez proche de ce que vous utiliserez probablement sur une base quotidienne quand vous êtes juste ... gitting commencé.

Oh, encore une chose !

Le Github Repo, myfirstrepo , que j'ai utilisé pour cet article est toujours en ligne. N'hésitez pas à le vérifier, à jouer avec, à le forker, à le cloner ou à tout ce que vous pensez qui vous habituera à utiliser git. S'amuser! (Et merci d'avoir supporté avec moi et tous mes jeux de mots git.)

Image miniature de l'article par MchlSkhrv / shutterstock.com