Git et Github de base pour les concepteurs, les apprenants visuels et tous les autres.

1. Quelle est la méthode de version: Parlons un peu de Git. Qu' est-ce que Git ? Git est le contrôle de version et qu'est-ce que le contrôle de version ? Le contrôle de version est essentiellement un contrôle d'historique. C'est comme un défaire. Il vous permet de revenir dans votre projet si vous avez fait quelque chose vous souhaitez ne pas avoir fait et que vous voulez revenir à ce qu'il était. contrôle de version vous permet de le faire. C' est une machine à remonter le temps à cet égard. Si vous n'avez jamais vu les années 80 classiques tourner vers le futur, c'est la machine à remonter le temps qu'ils ont et ce film. Je vais le référencer peut-être une ou deux fois et donc si tu ne l'as pas vu, tu dois aller le regarder. Ce que Git va faire, c'est te laisser revenir dans le temps. Il va stocker des instantanés de votre projet à un moment donné, puis à mesure que vous parcourez votre projet et que vous commettez de plus en plus d'instantanés, vous avez ces différents points dans le temps que vous pouvez revenir à, si vous décider que vous voulez annuler quelque chose. Ce n'est pas tout, ce contrôle de version fait cependant. Ce qui est vraiment génial dans le contrôle de version est de gérer la façon dont plusieurs contributeurs interagissent dans un projet. Ici, nous avons trois contributeurs. Ils poussent tous des contributions à une base de code centrale ou à n'importe quel projet vraiment ou il s'appelle le référentiel et c'est la version parfaite ou du moins la dernière de votre projet. Une chose que vous pouvez voir sur ce modèle ici est qu'il est très de gauche à droite. C' est unidirectionnel et ces contributeurs n'ont pas vraiment un excellent moyen d'interagir les uns avec les autres et de partager du code et des choses comme ça. En tant que contributeur, si vous voulez expérimenter un peu avec votre projet, vous devrez en faire une copie complète et jouer avec lui, puis revenir et pousser vos contributions à la version parfaite. Git comme une réponse à cela, il établit cette idée de contrôle de version distribué et ce que c'est, est un moyen de briser ce flux linéaire et d'introduire quelque chose qui est un peu plus collaboratif. Donc, ici, vous avez trois contributeurs et non seulement ils sont capables de pousser leur code au repo, mais ils peuvent aussi le partager entre eux. Ils peuvent partager les uns avec les autres, ils peuvent pousser jusqu'au repo, ils peuvent même tirer du repo, ils peuvent tirer les uns des autres, mais comme vous pouvez le voir, cela peut devenir assez déroutant. Les choses vont partout et sans aucun moyen de gérer cela, vous pouvez avoir beaucoup de problèmes sur un projet. C' est là que ce flux de travail intervient, et c'est là que nous allons aborder ce sujet et les leçons. 2. Rendez-vous et courez: Ce que je vais te montrer maintenant, c'est comment descendre sur ta machine. Probablement la façon la plus simple de le faire est si vous allez sur Mac.GitHub.com. GitHub est conçu pour un client vraiment génial à utiliser avec git. Je vais passer par une façon plus simple de l'utiliser, parce qu'il y a beaucoup de choses ici et si vous ne comprenez pas exactement ce que vous faites, ça peut devenir assez fou. Je vais vous guider étape par étape dans le terminal, qui est la fenêtre sur le fonctionnement interne de votre ordinateur. Si vous avez déjà vu des films de hacker des années 80, c'est ce qu'ils ont utilisé pour pirater le mainframe. Mais le moyen le plus simple de s'installer est de télécharger le client GitHub à partir de Mac. Ne vous inquiétez pas d'ouvrir l'application, hésitez pas à y aller et fouiller autour. Si vous n'avez pas déjà de configuration de Git repos, vous ne verrez vraiment rien d'intéressant qui se passe, mais il regroupe tout le logiciel Git avec, alors allez-y et installez cela. Si vous ne voulez pas télécharger cela, vous pouvez simplement aller sur le site officiel de Git, git.scm.com et le télécharger là aussi, suivez les instructions, c'est assez facile de le faire démarrer. Une fois que vous l'avez téléchargé, vous pouvez ouvrir le terminal. Vous pouvez soit commander de l'espace pour extraire le Finder rapide là, soit vous pouvez parcourir vos applications dans le terminal, voir le terminal des utilitaires juste là, et ouvrir cela. Par défaut, il va vous déposer dans votre dossier utilisateur. Je crée un répertoire appelé espace de travail, pour contenir beaucoup de mes projets actifs. Allons-y maintenant, c'est réglé pour cette démo, mais en général il y aurait un tas de projets ici. Alors créons un nouveau répertoire et on l'appellera premier repo, on y va et je vais juste mettre quelque chose là-dedans. Ouvrons l'édition de texte, et nous allons mettre un monde bonjour, sauvegardez ça. Hello.txt, voilà, et tout ce qui fait vraiment est de mettre quelque chose dans ce répertoire pour que nous puissions faire un repo Git pour cela. La façon la plus simple de faire un repo Git est de taper Git init, et c'est court pour initialisé. La première chose que je vais vouloir faire est d'entrer dans le répertoire que j'ai créé. Si vous n'avez jamais utilisé le terminal auparavant, il y a beaucoup de commandes qui vous permettent de créer des répertoires, supprimer des répertoires, créer des fichiers, supprimer des fichiers, sauter autour de la structure des répertoires. Je vais vous donner quelques notions de base au cours de cette leçon, et ce sont des choses qui sont très utiles. Le premier dont je vais vous parler est CD, qui a changé de répertoire. Donc, je vais sur CD dans l'espace de travail, et ce que je viens de faire là-bas a été essentiellement dit de mon utilisateur. Donc si je reviens à l'utilisateur ici, où êtes-vous ? Tu vois que c'est Tilde, c'est le squiggly là-bas. Tilde est votre dossier personnel, testy est le nom d'utilisateur pour mon compte test ici dans lequel je travaille pour cette démo, et là je suis petite maison et il y a mon espace de travail et j'ai créé le premier repo. Donc, quand j'ai dit espace de travail CD, j'étais dans tilde, qui est mon répertoire personnel ici, et j'ai dit changer le répertoire à l'espace de travail et je suis là, et maintenant je vais sur CD dans le premier repo. CD, premier repo, pas d'espace. Une fois que je suis là, je peux taper ls, ce qui signifie liste et je peux voir mon fichier hello que j'ai créé, et maintenant j'ai un endroit pour commencer mon Git Repo. La première chose que je vais faire est de dire git init. Chaque fois que je tape des commandes que Git est censé reconnaître, je vais les préfacer avec le mot-clé Git là-bas. Je ferai des choses comme git add, git clone, git commit, la plupart des choses qui ne fonctionnent que dans le programme Git. Git init est le premier que vous allez utiliser. Il a initialisé le dépôt Git vide, donc avec cette commande, nous suivons un fichier. Maintenant, si je vais apporter des modifications à ce fichier, il sera suivi par Git et c'est le tout début de votre expérience Git. 3. Le fait de mettre en scène: Parcouvrons certaines des étapes de base que vous allez utiliser pendant que vous demandez à GIT de vous aider à enregistrer les modifications apportées à votre projet. Nous avons parlé de cette idée de prendre des instantanés dans le temps de vos projets au cas où vous vouliez y revenir. Chaque fois que vous prenez un de ces instantanés, vous validez vos modifications à ce repo GitHub. Jetons donc un coup d'oeil à ce qui se passe. Il y a quelques étapes qui se déroulent dans ce processus d'appel d'offres. Donc, d'abord, vous tapez votre code, vous créez un nouveau contenu, peu importe ce que vous faites. Vous obtenez plusieurs fichiers ensemble, disons que vous décidez que vous êtes prêt à commettre. Vous êtes arrivé à un endroit où votre projet fonctionne, ou vous êtes à un stade où vous êtes prêt à tracer une ligne dans le sable en quelque sorte et à prendre un instantané à temps. Vous êtes arrivé à la partie de mise en scène de votre projet, ce que vous allez faire est de dire, hey GIT, j'ai ces fichiers particuliers que je voudrais me préparer à commettre. Vous ne voudrez peut-être pas valider tous vos fichiers. Ainsi, le processus de transit vous permet d'ajouter de manière sélective ce que vous souhaitez valider. Ensuite, vous allez passer à la commettre réellement. J' aime dans ces deux étapes à préparer quelque chose pour l'expédition où vous l'emballez dans une boîte, et quand vous engagez votre plafond et que vous dites, « Rappelez-vous toutes ces choses, prenez un instantané de ce point dans temps. » Donc, chaque fois que vous traversez et faites l'un de ces commits, vous emballez un moment dans le temps et que GIT se souvienne de cela pour vous. Donc maintenant, nous avons un peu parlé de ce processus d'ajout, de mise en scène , de validation, regardons à quoi cela ressemble pendant que vous êtes dans le terminal travaillant avec GIT. J' ai fait une mise à jour du fichier Helloworld. Alors faisons un statut Git et voyons ce que Git a à dire sur notre projet ici. Donc, vous voyez ces deux entrées rouges sont le fichier hello.rtf, que vous attendez à être modifié puisque nous avons travaillé dessus, puis cet autre fichier non suivi, .ds store, qui est un fichier système qu'Apple utilise pour suivre la façon dont vous avez configuré votre dossier et lorsque vous le regardez dans la fenêtre du Finder, toute façon, ce n'est pas le fichier que vous soumettez généralement à un repo. n'y a pas besoin de transmettre ça à d'autres développeurs. C' est là que ce processus d'ajout est utile. Il va vous permettre d'ajouter sélectivement des choses à votre repo plutôt que juste ce qui est dans le dossier car il peut y avoir ce fichier que vous ne verrez pas normalement, il va pointer avant, il y a d'autres invisibles que vous ne voyez pas normalement et qui pourraient être validés sans que vous le sachiez. Donc, faisons juste un git add hello.rtf, faisons un état git, voyons ce qui se passe. Alors on y va. Vous pouvez voir que hello.rtf est en vert maintenant et ds stocke toujours en rouge, il est répertorié comme un fichier non suivi. Donc c'est bien. On ne veut pas suivre celui-là. Celui que nous voulons suivre a été ajouté en mise en scène pour être engagé. Alors maintenant, allons de l'avant et validons ce fichier. Lorsque vous validez un fichier, nous devons laisser un message, vous devez dire ce que vous avez fait, quel code vous ajoutez, je veux dire, pas nécessairement le code, dans notre exemple, ce pourrait être une recette, il pourrait même être des fichiers Photoshop. Vous pouvez obtenir à peu près n'importe quoi à votre repo, que vous laissez un message, donc le tiret m est abrégé pour le message. Le message doit être entre guillemets, mis à jour bonjour message.Ensuite, je vais appuyer retour. Je récupère tout un tas de trucs de Git. Vous n'avez pas vraiment à faire trop attention à cela tant qu'il n'y a pas d'erreur alors ça va, donc maintenant je peux faire le statut Git. Tout ce que je vois est par fichier de magasin ds, il est sur la bonne voie. Donc c'est un petit pas là-dedans, j'ai travaillé dessus, je l'ai ajouté, et puis je l'ai engagé, j'ai ce fichier est coincé le fichier sur une boîte disant, hey, c'est ce que j'ai l'intention de commettre. C' est ce que j'ai l'intention de laisser derrière moi, puis j' enroule cette boîte et j'ai laissé un message dessus, et il est pris comme un instantané, c'est un moment que Git va se souvenir pour moi. Il y a une autre chose sur laquelle je voudrais attirer votre attention. Si vous allez faire un commit, disons que nous avons ajouté quelque chose de plus ici, nous reprenons notre processus. On y va. Je commet Git, si j'oublie de taper le raccourci du tableau de bord, Git va toujours vouloir un message pour moi et voici ce qui va se passer. Je vais entrer dans cette chose appelée VIM et est l'un des plus anciens éditeurs de texte là-bas, ça remonte beaucoup en arrière, et ça peut être un peu étrange à utiliser. Donc, vous commencez par ce message, il dit s'il vous plaît entrer le message de validation pour vos modifications. Vous pouvez le lire assez bien. Ce que vous feriez, c'est quelque chose comme ça que vous dites daté [inaudible] Vous remarquerez que je suis un mode d'insertion. Il s'agit d'un mot insert en bas. Ça va te laisser taper. Lorsque vous basculez de cela, vous êtes juste en mode lecture. Pour sortir, vous tapez un deux-points. Oups pas là cependant. Vous appuyez sur la touche d'échappement pour sortir du mode d'insertion. On y va. Tapez un deux-points et écrivez w pour écrire, et q pour quitter. Vous voudrez peut-être écrire cela parce que si jamais vous êtes déformé dans ce VimWorld, cela ne fonctionne pas. Si vous n'avez pas passé le temps, il peut être difficile de vous en sortir, et cela peut être frustrant. Donc écrivez deux-points WQ. Rappelez-vous que, appuyez sur Entrée, je suis ramené à ma fenêtre de terminal, et j'obtiens le même message que je suis habitué à voir quand je fais un tiret de commit git m. je suis ramené à ma fenêtre de terminal, et j'obtiens le même message que je suis habitué à voir quand je fais un tiret de commit gitm. accidentellement se déformer dans cet univers VIM, nous voulons échapper au côlon WQ, retour. Ça vous sortira. 4. Créer des futures alternatives - Branching et Merging dans Git: Jusqu' à présent, nous avons parlé de ce qu'est le contrôle de version, ce qu'est Git, comment l'installer, comment mettre en scène et valider des fichiers. Nous allons passer à autre chose et parler de quelques-unes des caractéristiques clés vraiment géniales de Git, le concept de tête, puis la pratique de ramification et de fusion. Cela nous donne la chance d'utiliser aussi nos excellentes métaphores de voyage dans le temps « Retour vers le futur ». Alors on y va. Vous êtes familier avec ça. Nous continuons, nous faisons des instantanés à points clés de notre projet afin de préserver ces états. Si on jette un coup d'oeil à cette chronologie, ça s'appelle maître. Il s'agit de la chronologie par défaut que vous obtenez lorsque vous initialisez un repo Git. Vous pouvez voir ici si je fais un statut Git sur le maître de branche. Alors que nous faisons ces changements et les engageons, nous sommes protégés contre un véritable autocollant par la capacité de Git de nous laisser revenir à un point précédent de notre projet et recommencer à zéro. Maintenant, tu vois le petit triangle que j'ai fait apparaître. C' est là que nous en sommes dans cette chronologie. C' est le concept de tête dans Git, c' est votre machine à remonter le temps, c'est là que vous êtes maintenant dans votre projet. Au fur et à mesure que vous allez, vous apportez des changements. La tête est là où vous êtes en ce moment. Parlons donc de ramification. C' est là que nous entrons dans nos métaphores Retour vers le futur. Retour vers le futur est centré autour de Marty McFly, un adolescent en 1985. Ses parents sont des shmacks et les choses ne vont pas si bien. Il veut emprunter la voiture pour sortir sa petite amie, mais le patron de son père l'a empruntée et l'a détruit. Donc dans le film, ce qui se passe, c'est que Marty remonte dans le temps à 1955 parce que tout cela aurait pu être évité si son père avait seulement demandé à sa mère l'enchantement sous la danse de la mer et qu'ils étaient tombés amoureux. Il retourne en 1955 et met en place un ensemble de circonstances dans lesquelles ils se rencontrent à la danse sous la mer et ont eu leur premier baiser et tomber amoureux. Il crée un avenir alternatif et quand il revient à 1985, tout est génial. Donc, dans nos projets, nous faisons des choses comme ça. Nous créons une nouvelle succursale et dans cette succursale est notre avenir alternatif. Nous travaillons sur notre projet, tout va bien et quand nous sommes à un point où nous voulons le fusionner dans la branche principale, qui est notre branche parfaite, nous le faisons en utilisant une fusion. Alors maintenant, dans Retour vers l'avenir, nous sommes de retour à 1985, tout va bien. George est un écrivain à succès, Loraine est toujours amoureuse de George, et Marty a maintenant un camion génial. Ce modèle de ramification et de fusion est au cœur d'un bon flux de travail Git. Il vous permet d'avoir la liberté d' expérimenter, d'essayer ces nouvelles fonctionnalités sans fusionner votre chronologie principale. Vous pouvez voir ce modèle où vous montez, vous essayez quelque chose de nouveau, cela fonctionne, vous le remettez, vous remontez, vous ajoutez la fonction suivante, cela fonctionne, vous le remettez. C' est à peu près le cœur du bon flux de travail Git. 5. Traire dans le temps terminaux - Déplacer le rendez-vous: Nous y voilà. Nous allons jeter un oeil pratique à ce que nous venons d'apprendre. On va voir bouger la tête, faire des ramifications et fusionner. La première chose que je vais faire est de voir ici. Faites une init git et configurez ce dépôt git. J' ai commencé avec un nouveau pour cet exemple et je vais faire un fichier hello.txt. Je dis toucher hello.txt et vous pouvez voir ici dans la fenêtre du Finder que j'ai à git repo et hello.txt. Maintenant, vous ne pouvez pas voir this.git et this.ds_store. J' ai choisi d'afficher les fichiers cachés, il y a des fichiers système qui normalement vous ne verrez pas en tant qu'utilisateur. Si vous Google cela, il y a un vraiment facile si vous pouvez copier coller cette commande dans votre fenêtre de terminal et il affichera ces fichiers pour vous. J'aime l'avoir dessus. La première chose que je vais faire est de configurer un fichier .gitignore. On y va. Maintenant, je peux ouvrir ces deux dans Sublime Text. On y va. Sublime Text est un excellent éditeur de texte, ils ont beaucoup de plugins pour cela. C' est également gratuit pour un téléchargement d'essai et je recommande l'utiliser si vous voulez juste essayer quelque chose. Commencez par gitignore. La première chose que je mets dans un fichier gitignore et ce que fait ce fichier est il dit à git de ne pas suivre les fichiers que vous listez explicitement ici. Habituellement, j'ajoute gitignore deux le fichier gitignore. Ensuite, secondairement, this.ds_store, c'est un fichier système que Mac utilisait pour suivre changements dans le dossier et c'est assez d'une explication pour dire que vous n'avez pas besoin de le suivre dans votre repo GitHub. J' ai ces deux choses là-dedans et maintenant je vais commencer avec mon hello.txt. Ce que je vais illustrer est une série de commits et ensuite comment vous pouvez vous déplacer dans ceux-ci. Disons que j'ai une bonne idée pour un poème et que je vais sauver ça. J' aime beaucoup ces deux lignes. Faisons un petit diagramme ici. Nous allons dire que c'est notre premier commit. Je vais commencer à construire une petite chronologie juste pour illustrer où nous en sommes dans ce truc. Je vais le sauver, aller par ici, faire le statut git, et ça dit que je suis sur le maître de branche. C' est mon premier commit et c'est un hello.txt est le fichier non suivi. Nous allons faire git ajouter hello.txt. Maintenant, nous pouvons commettre, git commit - m pour le message. Je vais dire, en ajoutant les deux premières lignes de mon nouveau poème. On y va, donc je l'ai engagé. Maintenant, je peux vérifier cela et voir git a une commande appelée log. Si vous faites git log, vous verrez le commit que vous venez de faire. Il a ce numéro de commit long fou qui est unique à ce commit et il indique qui l'a fait, quand ils l'ont fait, puis donne le message de commit. C' est génial lorsque vous travaillez dans un groupe car vous pouvez suivre tous les différents commits et jeter un oeil à l'historique. Faisons un peu plus sur le poème ici. « Le monde est si haut. » Ouais, c'est vraiment bien, j'aime ce poème. Commisons à nouveau, faisons un second commit. Je vais appeler celui-ci B et je vais faire une petite flèche pour montrer où on est ici. Ajoutez celui-ci, faites le statut git. Modifié hello.txt, donc nous allons faire git add hello.txt, git commit -m pour le message, en ajoutant la troisième ligne et ensuite nous validons cela. Regardons le journal et voyons ce que nous avons. Il y a notre premier commit ici, en ajoutant les deux premières lignes de mon nouveau poème. Ensuite, vous voyez celui que nous venons de faire, donc il les énumère depuis le plus récent vers le bas. Tout, d'accord. Jusqu'à présent, si bien, continuons. Nous avons une autre ligne du poème. Je vais commettre celui-ci ici, il passera par le statut git habituel, git add, git commit. Git nous allons le consigner et voir ce que nous avons ici. Nous avons tous les trois. Cela devrait tout avoir du sens et vraiment probablement obtenir un peu ennuyeux écrire maintenant. Disons que j'ai une seconde réflexion sur cette dernière ligne. J' aimerais peut-être le changer, mais je l'ai déjà engagé. Non, que puis-je faire pour revenir au-delà de ce commit ? Eh bien, je peux aller me réinitialiser et voici un terme que vous reconnaîtrez HEAD. Je pourrais prendre le HEAD et le réinitialiser à un autre point sur cette chronologie. Je le montre en disant [inaudible] qui est un peu squigggly dans le coin supérieur gauche par le quai de l'ESC sur Mac, n'importe où. Cela dit, prenez la tête et retournez en arrière, retournez vers le dernier commit. Voilà, maintenant mes changements sont sur scène après cette réinitialisation, et vous pouvez voir que rien n'a vraiment changé ici cependant. Mais si nous regardons le journal git, vous verrez que j'ai celui qui dit ajouter les deux premières lignes et d'ajouter la troisième ligne. Mais ce commit est parti. Donc nous avons annulé ce commit. Nous sommes remontés dans le temps sur notre petite machine à remonter le temps appelée tête. Disons que je ne veux pas garder cette dernière ligne du tout. Faisons ça. Nous allons changer ça pour quelque chose qui a un peu plus de sens. On y va. Je le sauve. Ensuite, je git ajouter et je git commit et je git log et vous pouvez le voir. La quatrième ligne, voilà. Disons que je ne suis pas content de ça non plus. Si je veux souffler toute cette dernière ligne, tout ce commit C que j'ai fait. Je ne m'inquiète pas de garder des dossiers. Je peux faire une réinitialisation git - -hard, puis lui donner un index pour la tête, HEAD~1. Ce que cela va faire est de souffler tout dans ce commit et de déplacer la tête vers le dernier commit. Donc, une fois que j'appuie sur retour ici, vous verrez le changement de texte dans le pavé de texte ou le texte sublime. Fais ça et quand je vais ici, boum, parti, effacé de l'histoire. Essayons la somme de ramification maintenant. Évidemment, j'ai beaucoup de problèmes avec cette ligne suivante et j'utilise un exemple ridiculement simplifié ici. Mais c'est principalement parce que je veux me concentrer sur la façon de bouger avec cette chronologie plutôt que des applications pratiques de validation de code en ce moment. Faisons une branche. C'est un exemple parfait de quand vous voudrez peut-être utiliser une branche si vous essayez d' éviter de gâcher les trois lignes parfaites que vous avez jusqu'à présent. On va ouvrir une succursale ici. Pour ce faire, faites un checkout git -b. Nous n'avons pas encore vérifié la caisse, alors vérifions la caisse. Checkout est comment vous vous déplacez entre les branches et git. Il peut également être utilisé comme une commande abrégée pour créer une nouvelle branche. Donc, si je dis git checkout -b, qui est abrégé pour branche, et que je lui donne un nom. On l'appellera quatrième ligne. Voyez ça, j'ai passé à une nouvelle branche, quatrième ligne. Me voilà, écris ici. Une question de fait, appelons ça A, enregistrez-le et faisons un état git. Cela montre qu'il est modifié principalement parce que je viens de passer d'un C à un A. Alors ajoutons, regardez ça, ça se sent plutôt bien. Allons de l'avant et commettons ceci. Sauvegardez d'abord. On voit, d'accord. Je vais texter git add hello.txt, git commit -m, «  Je pense que je l'ai compris ! » On y va. Faisons git log. Vous verrez tous mes derniers commits ici, y compris celui de la nouvelle branche. Maintenant, nous sommes heureux avec le poème. Mais on est dans une nouvelle branche. Pourquoi ne pas le fusionner dans la branche principale ? Nous faisons cela, maintenant je vais mettre ce diagramme vaut la peine d'attendre. On va essayer de ramener ça ici et de le fusionner et ensuite on pourra continuer. Ce modèle pourrait sembler familier deux vous cependant, parce que c'est exactement ce que nous avons regardé dans les diapositives là-bas. On va y aller. Sauvegardez ça. Faisons git. Eh bien, maintenant nous avons fait des changements, donc il va vouloir que nous nous engagions à nouveau. Ajouter git commit, c'est un message de validation assez boiteux. Ne fais pas ça. Maintenant, nous pouvons git checkout maître. vois qu'on va passer au maître de branche. Maintenant, regardez ce qui se passe lorsque je passe à hello.txt. Ça va revenir à l'endroit où on s'était arrêté quand on a commencé notre succursale. Boum. Tu vois ça ? Donc maître n'est pas au courant de ce que nous avons fait sur cette autre branche, sur notre chronologie alternative. Pour rassembler ces deux choses, nous allons faire un git. Nous avons fait la caisse, nous allons faire une fusion git. Comment on appelle cette dernière branche, quatrième ligne. Ce que cela va faire, git va faire une copie de cette branche et la fusionner dans master. C' est ce que je ferais si j'étais satisfait de ce que j'avais fait dans ma branche. Essayons. Maintenant, quand je vais ici. Boom, on a tout en maître. Puis le cercle de la vie continue. Je peux continuer ici et etc. C'est les bases du workflow git juste là. Vous créez quelque chose, vous le commettez, l'action, la sauvegarde. Vous branche, vous créez quelque chose, vous le commettez, vous le fusionnez. Si j'allais continuer de cette façon, je pourrais monter ici et commencer une autre branche ici. Vous avez l'idée et continuez comme ça. C' est la base du flux de travail. Il devient juste un peu plus impliqué lorsque nous commençons à ajouter GitHub et d'autres choses plus tard. Mais pas beaucoup. Si tu comprends ça, tu auras git. Comment ça va à la moitié ou à la ligne pour tout envelopper. 6. Configurez votre compte GitHub: Il est temps d'obtenir votre propre compte GitHub. Je viens de me rendre sur le site GitHub et de remplir mes informations ici. Maintenant, j'ai mon nouveau compte. Prends le gratuit pour l'instant. Si vous le souhaitez, vous pouvez obtenir un micro compte. Vous ne pouvez pas avoir de comptes privés sur le libre, ils doivent tous être visibles publiquement. Si vous voulez travailler sur quelque chose qui contient matériel confidentiel ou autre chose que vous ne faites pas, que vous aimeriez pouvoir cacher du monde extérieur, alors vous devrez payer pour cela. Mais pour l'instant, je vais juste finir ça ici. Je suis là. Voyons voir ça, disons, « Non merci ». C' est votre tableau de bord que vous obtenez, et il a un petit pas à travers ici qui vous emmène aux documents et dit que c'est la façon dont vous faites cette fonctionnalité, c'est ainsi que vous le faites. On va le faire tout de suite. Ça vaut la peine de s'en sortir définitivement. Certainement apprendre quelque chose. La première chose que nous allons faire est de parcourir comment vous créez un nouveau référentiel. Maintenant, vous l'avez fait localement auparavant avec Git init dans votre répertoire et votre espace de travail. Maintenant, nous allons le faire dans le Cloud sur GitHub et vous montrer comment vous pouvez le ramener à votre ordinateur. Vous pouvez également démarrer localement, puis le pousser vers votre GitHub. Il a commencé le repo comme ça. Je couvrirai ça dans une minute. Mais c'est probablement le moyen le plus simple d'y aller. Vous cliquez sur le grand bouton vert et le bon vieux GitHub dit, « Comment voulez-vous l'appeler ? » Ce sera le repo de notre projet. Je vais l'appeler livre de recettes. Cela doit être public et je vais cliquer sur « Initialiser ce dépôt avec un README ». Je vais te montrer pourquoi dans une minute. On y va. Voici mon tout nouveau référentiel de livres de cuisine. Il s'agit du fichier README par défaut, lorsque vous accédez à la page de votre compte GitHub. Vous pouvez vérifier cela en allant à n'importe quel autre repo GitHub là-bas sur Internet. Il montre ce fichier Readme.md et MD signifie markdown. Markdown est une façon abrégée d'écrire du HTML. GitHub le comprend et l'analysera et l'écrira comme ceci. Nous allons travailler dans ce fichier README pour cette classe. Allez-y, obtenez une configuration de compte GitHub, et nous allons revenir aux diapositives et parler un peu la façon dont nous allons interagir avec GitHub et commencer à partager du contenu entre eux. En fait, nous approchons de la fin de la leçon, nous avons encore quelques unités à aller, mais je dirais que nous avons dépassé la mi-parcours et c'est là que ça va vraiment s'amuser. Obtenez votre compte et je vous verrai dans la prochaine vidéo. 7. Cloning et forgeage - An Overview of GitHub Workflow: On y va. Nous allons jeter un oeil à GitHub. GitHub est essentiellement juste un repo Git qui est sur github.com. GitHub a mis en place un ensemble de fonctionnalités qui vous aident à travailler sur des projets en équipe. C' est aussi un réseau social pour les projets open source. Deux des principaux composants du workflow GitHub sont le clonage et le forking. Le clonage ne fait qu'une copie. C' est comme ce que cela ressemble, ce que vous voulez faire est d'obtenir des choses de votre repo GitHub vers votre environnement de développement local afin que vous puissiez travailler dessus. Lorsque vous effectuez cette copie, GitHub nomme automatiquement l'origine du repo. C'est une télécommande. Comme vous pouvez le voir, il est loin de votre environnement de développement local. Maintenant, vous avez toujours un repo Git comme nous l'avons vu précédemment localement et vous pouvez le dire sur n'importe quel nombre de télécommandes. Dans un projet, vous pouvez avoir une télécommande pour déployer du code de transit, vous pouvez en avoir une pour déployer du code de production, vous pouvez même donner à d'autres ordinateurs membres de l'équipe une adresse distante et leur envoyer du code. Ces télécommandes sont appelées. Ici, vous verrez une version un peu différente de cette branche, créer, valider, fusionner, cycle que nous avons vu auparavant. Lorsque nous arrivons à notre commit et que nous sommes prêts à le fusionner, au lieu de le fusionner dans notre branche principale, ce que nous allons faire est de pousser ce contenu sur notre télécommande et de le fusionner là-haut. Lorsque cela a été fusionné avec la branche principale, nous allons ensuite retirer cette nouvelle branche maître dans notre projet et recommencer ce cycle. Et si c'est quelqu'un d'autre repo GitHub ? Tu n'y auras pas accès. Sauf si, bien sûr, vous êtes administrateur sur ce projet. Que se passe-t-il lorsque vous essayez de pousser le contenu vers ce repo ? Tu ne pourras pas le faire parce que tu n'as pas de droits d'accès. Dans cette condition, vous devrez soumettre ce qu'on appelle une demande d'extraction. Essentiellement, une requête pull est juste un avis que vous donnez à quiconque possède ce repo qui dit, « Hé, j'ai créé ce contenu. Allez-vous le faire entrer dans le projet ? » La fonction qu'ils servent est qu'ils empêchent essentiellement tout le monde dans le monde de pousser le contenu dans le projet d'un propriétaire sans leur permission. Dans un projet basé sur l'équipe, il donne également un ensemble supplémentaire d'yeux au code qui est fourni qui code généralement le contenu. Quelqu' un d'autre devra examiner ce qui va être soumis et l'accepter pour inclusion. C' est donc un bon filtre pour garder les choses propres. Une petite note ; lorsque vous soumettez des demandes d'extraction, essayez de les garder aussi concis que possible. Ne faites pas beaucoup de travail pour quiconque va devoir examiner cette demande de tirage. Espérons que les autres membres de votre équipe vous offriront la même courtoisie afin que vous n'ayez pas à lire une requête gigantesque pour l'inclure dans le projet. Maintenant, si cette demande d'extraction est approuvée, le processus se poursuit de la même façon que nous l'avons vu. Il serait fusionné dans la branche master et vous tiriez ce nouveau maître vers le bas et l'incorporer dans votre projet. Seulement maintenant, il peut contenir des soumissions d'autres membres de l'équipe. Ainsi, vous obtiendrez non seulement votre fonctionnalité, mais toutes les autres fonctionnalités qui ont été développées pendant que vous travaillez sur la vôtre. Forking, c'est un peu comme le clonage. C' est juste faire une copie de quelqu'un d'autre repo là-haut sur GitHub. Vous commencez avec leur repo GitHub, vous le fork, et maintenant vous avez leur repo GitHub et votre repo GitHub. Forking fonctionne bien lorsque vous voulez prendre un projet open source, faire vôtre et le prendre dans votre propre direction. Sur un projet, je vais souvent fourcher le repo de sorte que j'ai cette mesure de révision ajoutée. Je vais pousser ma branche là-haut, l' examiner, puis soumettre une demande de traction au dépôt principal. Vous obtenez un peu de magie GitHub quand vous faites cela. Les deux repos seront conscients l'un de l'autre. GitHub a développé plusieurs fonctionnalités qui rendent la révision et la fusion du code ou un contenu. J' utilise le code et le contenu de façon interchangeable. Il fera des choses, comme vous faire savoir si les demandes médiocres peuvent être fusionnées facilement ou s'il y a un problème. Vous verrez un peu plus à ce sujet quand je vous montrerai l'exemple en direct. On va mettre tout ça ensemble et tu verras comment ça marche, le local et le distant. Il va intégrer toutes les choses dont nous avons parlé jusqu'à présent. Nous avons parlé de Git, contrôle de version distribué, nous avons installé Git, nous avons initialisé un repo Git localement. Nous avons examiné la ramification, la mise en scène et l'engagement. Nous savons ce qu'est HEAD et nous savons ce qu'est la fusion. Nous avons parlé de pousser, ce que sont les télécommandes, de clonage, forking et de requêtes de traction. Voyons comment tout ça fonctionne ensemble. Nous allons commencer par un dépôt de projet maître. Nous allons bifurquer cela et avoir notre propre repo, que nous allons ensuite cloner dans nos environnements locaux pour que nous puissions travailler dessus. Nous allons faire notre travail, nous allons pousser jusqu'à notre fourche, puis soumettre une demande de traction au dépôt principal du projet. Une fois que c'est correct, nous pouvons le retirer localement avec toutes les modifications qui ont été soumises par d'autres membres de l'équipe. Ce cycle se répète et se répète. Alors préparez-vous. On va le faire en direct maintenant. Après cette prochaine vidéo, vous devriez être prêt à contribuer à notre projet. 8. Cloner un GitHub repo - Live démo: Commençons par une démo en direct. Ici, je suis dans mon nouveau dépôt GitHub que j'ai mis en place, en particulier pour ce projet. Je l'appelle « cuisiner avec Marc ». C' est là que je vais garder certaines de mes recettes. Je n'ai pas de dépôt, alors commençons un nouveau maintenant. On va appeler ce toast, et je vais mettre ma recette de toast ici. Il va par défaut au public. Si vous voulez un dépôt privé, vous devez payer pour cela. Donc nous sommes publics depuis que je veux partager ma recette de pain grillé avec le monde entier. Je vais initialiser ceci avec un fichier README, ce qui est une bonne idée. Au moins, le dépôt a quelque chose dedans. Ensuite, il suffit de cliquer sur le grand bouton vert, et voilà. Maintenant, on va aller par ici. Je vais cloner ça dans mon environnement de développement local. Vous obtenez clone et collez cette adresse là. Vous vous souvenez de la télécommande de la dernière série de diapositives ? C' est la télécommande ici dans laquelle je suis. J' ai donc dû cloner ceci sur mon bureau, et dès que je le ferai, Git va écrire dans son adresse distante. Laisse-moi le faire, ça aura plus de sens. Donc ça l'a fait tomber, vérifions la fenêtre du Finder ici, et ça devrait nous dire, bien sûr, qu'il y a des toasts. Donc, si je dis git remote, je dois changer les répertoires dans le repo réel maintenant. Je fais ça à chaque projet. CD en toast. Maintenant, je fais git remote, et ça va me montrer l'origine. Donc, c'est la télécommande que je l'ai, les noms à l'origine par défaut, vous pouvez le changer à tout ce que vous voulez. J' aime suivre la convention de dénomination d'origine et en amont, juste parce que cela m'aide à garder clairement dans mon esprit où exactement je pousse le contenu à plus tard. Maintenant, je peux faire une télécommande git -v pour verbeux. Ce drapeau signifie être verbeux, dites-moi plus. Ensuite, vous verrez que l'origine a cette adresse, cookingwithmarc/toast.git, qui est ce que nous copions collé. Vous pouvez donc utiliser ces origines ou ces télécommandes. Vous indiquez à votre dépôt GitHub ces adresses, et cela vous permettra de leur envoyer du contenu. Je peux pousser jusqu'à mon repo GitHub. Je peux mettre l'adresse du repo de quelqu'un d'autre là-dedans, et y pousser. C' est une façon vraiment soignée. Est au cœur de cette notion de contrôle de version distribué. Jetons un coup d'oeil au fichier README, nous allons faire quelques modifications ici. Ceci est un fichier Markdown, md signifie Markdown. C' est une façon d'écrire du HTML en raccourci. Donc, si vous êtes familier avec H1, H2, H3 comme niveaux d'en-tête, même si vous avez seulement travaillé dans une application de traitement de texte auparavant, vous êtes familier avec cette idée. Donc, vous pouvez dire à Markdown de rendre un H1 avec un hashtag, deux hashtags comme un H2, trois comme H3 etc. Voici mes ingrédients. Faisons ça en tant que H3. Tout endroit qui a un saut de ligne, va être rendu comme un nouveau paragraphe. Voyons, est-ce que j'ai mon toast ici ? Je sauve ça. Allons ici, et nous allons faire toute cette branche créer un processus de validation de scène. J' ai déjà commencé à créer sans démarrer une nouvelle branche. Alors commençons une nouvelle branche. Nous appellerons cette sortie de recette. Git checkout -b pour la recette de branche. Donc, si nous faisons un état git, il dit que le README a été modifié, et vous pouvez voir ici quand nous avons commencé la branche, nous avons porté ce fichier README modifié dessus. Donc, je vais dire git add, readme.markDown, faire un git commit -m pour le message. Statut git rapide jusqu'à ce que tout soit cool. Donc maintenant je vais pousser ça jusqu'à mon repo d'origine. Donc, je vais dire git push à l'origine. Comment appelons-nous cette branche ? Recette. On y va. GitHub va me demander de m' authentifier avec le nom d'utilisateur et le mot de passe chaque fois que je pousse. Sauf si j'ai une configuration SSH, ce qui est un niveau de sécurité supplémentaire. Je ne vais pas y aller maintenant, ça pourrait être un sujet pour un autre cours. Vous êtes venu sur Google comment configurer SSH, ce n'est pas si difficile. Donc, si vous tapez votre nom d'utilisateur et votre mot de passe maintes et maintes fois, google pour voir si vous pouvez le faire fonctionner. D' habitude, c'est ce que j'utilise. Alors passons au compte GitHub maintenant. Vous verrez que j'ai une demande de traction ici. Donc, dès que j'ai poussé ce contenu, GitHub a reconnu qu'il s'agissait d'une nouvelle branche entrante, et il dit, « Voulez-vous faire une requête pull pour cela ? » Bien sûr. Créons la requête de traction. Donc maintenant ça va me dire, vous pouvez fusionner ça automatiquement. C' est génial, faisons-le. Fusion, raffermisse-le. Super. Donc, ce que c' est fait est la même chose que nous ferions localement quand nous fusionnions à nouveau. Tu montes dans cette petite branche et quand tu as fini de t'engager, tu as fusionné en maître. Nous venons de le faire ici dans le Cloud dans notre dépôt GitHub. Vous pouvez donc supprimer la branche que vous poussez car elle a été tirée dans votre maître. Maintenant, allons par ici. Si on dit git, je veux te montrer ça. Notre recette de pain grillé est tout en une seule pièce. On est toujours sur la branche des toasts. Donc, si je dis git checkout, maître, regardez ce qui se passe. Wow, tout est parti. Donc cette branche a tous ces changements, maître ne l'a pas. Si nous travaillions localement, nous fusionnerions la branche de recette en master. Eh bien, nous allons le faire à partir du dépôt GitHub à la place. Donc je dis git pull, et ce que fait pull, c' est qu'il monte, regarde autour de quelque chose de nouveau, le fait descendre et le fusionne avec n'importe quelle branche ici. Donc git pull origine, maître. Nous y allons, et maintenant nous devrions avoir tous ces changements. Il y a donc une boucle à travers le trou, créant un repo, le clonant vers le bas, créant du contenu, le poussant vers le haut, fusionnant et le ramenant vers le bas, et complétez la boucle que vous avez vue sur les diapositives. Donc pour la prochaine vidéo, je vais faire la même chose avec la fourchette. C' est juste un peu plus ajouté de complexité honnêtement. Ce que je veux que tu fasses, c'est essayer ça, et que tout ce circuit fonctionne pour toi. C' est votre GitHub et Git Workflow de base que vous utiliseriez sur n'importe quel type de projet web, ou projet open source, ou quoi que ce soit du genre. Donc, si vous pouvez le faire, vous l'avez, et la prochaine leçon sera juste un peu plus. Donc, avoir à elle et bonne chance. On se voit dans une minute. 9. Forking a GitHub repo - Live Démo: Maintenant, nous allons regarder forking dans GitHub. C' est typique du processus que vous feriez si vous vouliez contribuer à un projet que vous ne possédiez pas. C' est mon repo personnel sur GitHub. J' ai un autre navigateur ouvert avec notre livre de recettes repo. Alors que je suis connecté ici en tant qu'administrateur dans ce navigateur, je ne le suis pas, mais je peux y accéder. Allons à github.com/gitforvisual. Je peux suivre cette personne ici, et je peux aussi regarder les repos qu'elle a. Puisque c'est public, je peux le fourcher. Voici l'icône de la fourchette par ici. Quand je fais ça, j'adore cette animation ici. Je reçois une fourchette de GitHub. On y va. CuissonavecMARC/Livre de cuisine. Ça va être une copie de ce qu'il y a ici. Voyez comment ils correspondent. Maintenant, je dois suivre la même procédure que celle que j'ai faite quand je clonais. Je copie cette URL, retourne ici, assurez-vous que je suis dans l'espace de travail et dis obtenir le clone, mettre cela dans. On y va. Maintenant, je devrais avoir un livre de cuisine dans l'espace de travail. Il est là. Maintenant, je peux prendre ce fichier README et l'éditer. Cela va en fait faire partie de notre projet. Encore une fois, j'ai fait ce que vous n'êtes pas censé faire, qui est de commencer à créer avant de créer une branche. Laisse-moi faire ça maintenant. Un état git rapide va nous montrer. Je dois voir dans le livre de cuisine. On y va. Statut Git. Git checkout B, on appellera cette branche tortilla. Git ajoute le fichier Readme.markDown, git le commet avec un message. On y va. Maintenant, je peux faire une tortilla d'origine git push. Cela va pousser ma branche localement vers mon repo GitHub. C' est là que nous allons voir la magie GitHub entrer avec la fourche. Je fais ça. Maintenant, allons regarder. Assez sûr. Il y a ma branche que j'ai poussée là-haut. Quand je dis une requête de comparaison et de traction, cela me donne la possibilité de créer une requête de traction. Je ne vois rien ici qui dise comment le fusionner. Parce que maintenant je suis dans Git pour visuel/livre de cuisine. Suivez ce lien magique de mon repo GitHub à celui que j'ai bifurqué. Maintenant, si je vais ici au Git réel pour le repo visuel de livre de cuisine que je suis connecté en tant qu'administrateur et regarde dans la requête de traction, c'est là que la requête de traction apparaît. Maintenant, je peux l'examiner et je peux le fusionner. Il fait partie de ce dépôt. Retournons ici. Voilà, tu y vas. Comme avant, si je vais git checkout master, tout cela devrait disparaître. Boum. Nous devons extraire la version la plus mise à jour de master dans notre référentiel. Git, tire. Attendez une minute. Attendez une seconde. Regardons nos télécommandes. Nous n'avons qu'une seule origine. Nous devons ajouter une télécommande pour ce livre de cuisine original. Retournons là-bas. Copiez l'URL de clone et dites, « Git remote add upstream » et collez-le dans. Ce que je dis est, « Hey git, je veux ajouter une télécommande, je veux l'appeler en amont. » Encore une fois, je pourrais appeler ça tout ce que je veux. Mais l'amont et l'origine sont deux conventions de nommage auxquelles je m'en tiens et auxquelles beaucoup de gens s'en tiennent parce que cela vous aide à séparer dans votre esprit où vous poussez ce truc. Origine est à moi et en amont est le principal repo canonique GitHub. Je vais dire « Entrer ». Maintenant, si je dis git remote-b, cela me montre mon origine et mes télécommandes en amont. Si je dis git pull upstream master, il va aller en amont, il va chercher quelque chose de nouveau, il va le tirer vers le bas et il va le fusionner avec ma branche master. Quand je reviendrai ici, je devrais l'avoir maintenant. Boom, on y va. Maintenant, je peux recommencer tout le cycle. Si vous appuyez sur la commande K, l'écran est effacé. J' aime le faire assez souvent. Je vais git checkout b. Disons que je veux faire quelques ajustements à la façon dont j'ai écrit ma recette. Quand je commence cette branche de réglages, j'ai le dernier et le plus grand maître. Si je collaborais et que cela se produira au fur et à mesure que nous collaborons, je tirerai tous les changements qui ont été ajoutés par les autres membres de l'équipe, ainsi que le mien. Quand je démarre une nouvelle branche, j'amène tous ceux avec elle. J' ai toujours la version la plus récente. J' ai une nouvelle branche. Allons ici. Je vais juste faire une petite mise à jour. Je vais aussi mettre une ligne ici pour séparer ma recette de celle de tout le monde. Ce sont mes réglages. Git ajouter est un truc. Git ajoute tous vos documents sur scène. Si vous avez beaucoup de choses ouvertes, ça peut devenir un peu délicat. Mais si vous travaillez généralement sur trois ou quatre fichiers, ce que vous le serez si vous faites du développement web, c'est soigné et c'est un raccourci qui vous permet d' ajouter plusieurs à la fois sans taper le nom de fichier entier. Git commit-m pour le message, a changé du texte. C' est un mauvais message de validation, mais on va y aller. Maintenant, je peux faire une origine git push. On va appeler celui-là des ajustements. J' ai poussé ça, allons jeter un oeil. Où est mon repo ? Si je demande des ajustements, cela me rebondit ici, je crée la requête pull, elle ne peut être fusionnée que par les collaborateurs du projet. Allons ici où je suis un collaborateur et regardons les demandes de traction. Il est là. Je le fusionne en tant qu'administrateur ici. Maintenant, je peux dire git checkout master. Je peux tirer. Vérifions ça très vite. Je suis maître, donc mes changements ne devraient pas être là et ils ne le sont pas. Puisque je fais git pull upstream master, il va obtenir les derniers changements et cela devrait maintenant refléter les petits changements que j'ai faits. Il y a quelques boucles à travers la fourche. Fondamentalement, c'est tout. Tu es à la fin de ce cours. Vous avez couvert un peu de matériel et vous devriez maintenant être en mesure de configurer votre propre repo Git localement. Set est monté sur GitHub et clone et fork. Ce sont les compétences de base dont vous avez besoin pour collaborer à un projet d'équipe en utilisant Git. Félicitations, certainement courir à travers cela quelques fois. Ensuite, nous allons faire la dernière vidéo sur ce qu'il faut soumettre pour votre projet de recette, que vous venez à peu près de voir. Si vous pouvez mettre une recette là-haut, alors vous l'avez fait. C'est tout l'objectif. Pas beaucoup de travail acharné en ce qui concerne la création d'artefact, plupart du travail acharné que vous avez fait dans cette classe est juste apprendre. Apprendre comment les choses fonctionnent et apprendre la syntaxe et le protocole de contribution. Félicitations et je te vois dans la dernière vidéo. 10. Merge les conflits et le projet final: D' accord, tout le monde. Bienvenue sur la dernière vidéo pour Git et GitHub pour les apprenants visuels. Je vais couvrir quelque chose de très rapide que vous ne rencontrerez probablement pas au cours de ce projet. Mais si vous commencez à utiliser Git d'une manière quelconque en équipe, il y a de fortes chances que vous rencontriez ce qu'on appelle un conflit de fusion. Vous pouvez voir que je suis entré et a foiré le fichier pour que je puisse créer ce conflit de fusion. Fondamentalement ce qui se passe, c'est lorsque vous avez des gens qui contribuent, puis que vous reculez et recontribuez et que vous redescendez dans ce cycle, tôt ou tard quelqu'un va modifier un code sur une ligne que quelqu'un d'autre a fait, et cela pourrait confondre Git. Git peut ne pas savoir quelle version des deux changements différents prendre. Donc, cela vous donne un conflit de fusion. Mais cela fera quelque chose d'utile pour vous, il indiquera où est la confusion. Donc ici, vous voyez une sélection, où dans un cas quelqu'un a présenté le nom Marc Nischan Esquire, et l'autre Marc Nischan PhD. Donc Git a enveloppé cela dans un petit commentaire. Vous verrez ces motifs distinctifs de grands thans et moins thans divisés par une ligne pleine. Donc Git dit que ce grand nombre est l'ID réel du commit. Donc Git dit, entre ces deux-là, lequel voulez-vous garder, essentiellement ? Donc tout ce que vous avez à faire est de réparer ça. Je vais garder Esquire. Bien que je ne suis ni Esquire ni Doctorat. Mais c'est une histoire tout à fait différente. Donc j'ai jumelé ça pour être juste les textes que je veux garder, et il y en avait un autre ici, on dirait que ces espaces ont été modifiés. Ça n'a pas beaucoup de sens, on va juste se débarrasser de ça aussi. Alors maintenant, je peux sauver ça. Faisons un statut Git et voyons ce que j'obtiens. Super. Git ajouter. Git commit -M, message, résolution d'un conflit de fusion. On y va. C'est donc un rapide coup d'oeil aux conflits de fusion. Une autre option que vous avez est de télécharger un outil de fusion. J' utilise P4Merge, c'est gratuit. C'est plutôt bon. Vous pouvez voir sur cette image ici, elle indique essentiellement ce qui se trouve sur la télécommande, ce qui est sur votre ordinateur, et ce qui se trouve dans la branche que vous avez retirée. Il vous demande de choisir entre les différentes versions, et il sauve celle que vous choisissez. C' est donc une façon visuelle vraiment soignée de passer par ces choses. Il vous permet de faire défiler l'ensemble du document et vous montre tous ces endroits où se trouvent les erreurs. Je ne veux pas aller dans l'installation. Il y a quelques tutoriels sur la façon d'installer cette chose. Il y a beaucoup d'outils de fusion gratuits. Alors regardez autour de vous, choisissez-en un que vous aimez, et vous pouvez le faire courir, je suis sûr assez vite. Donc maintenant, ce que je veux faire est de passer tout un cycle. Fondamentalement, c'est votre projet final. Tout le cycle d'ajout d'une recette, engagement local et de la pousser vers le haut pour l'inclusion dans le livre de recettes principal. Alors on y va. Voici donc mon projet, projet de livre de recettes. Je vais ajouter une autre recette. C' est à peu près ce que tu ferais. Vous commenciez par forking, clonage, puis par commencer sur une nouvelle branche. Donc je suis sur le maître en ce moment. Je peux vérifier cela en accédant au statut Git. Faisons une caisse Git -B et on appellera cette nouvelle branche, l'ail. Parce que je vais ajouter une recette pour l'ail rôti. Alors passons à la fin de ma dernière. Ici, j'ai beaucoup de formatés dans Markdown. Donc, nous n'aurons pas à perdre de temps. On y va. Alors sauvez-le, et j'ai besoin de l'ajouter, de le valider. Maintenant, je vais pousser ça jusqu'à ma version fourchue de ça. J' utilise la convention de dénomination d'origine et en amont. En amont étant l'original, et l'origine étant celle que j'ai fourchu. Donc nous allons pousser ces changements vers Git. Poussez la tête d'origine. Alors poussez à l'origine où je suis en ce moment. On y va. Maintenant que je vais à mon repo, ici, livre de cuisine, j'ai la possibilité de faire une demande de comparaison et de tirage, ce que je vais faire. Super. C'est à jour avec la branche de base, donc je ne devrais pas avoir de mal à fusionner cela. Donc maintenant, je retourne à cet autre navigateur où je suis connecté en tant qu'administrateur, et je vais regarder les demandes de traction, et c'est là. Donc c'est ce que je ferai quand je recevrai votre demande de tirage. Je vais le regarder, vérifier les dossiers, assurer qu'il n'y a rien de fou là-dedans. Maintenant, vous remarquerez ces icônes ici. Ils vous ont permis de voir le dossier complet. Il cache des choses qui n'ont aucun conflit, des choses que vous avez déjà vues. Il est plus facile de numériser les modifications et de ne pas avoir à vous soucier de tout le texte entre les deux. Eh bien, tout ça a l'air bien. Revenons en arrière et fusionnons ça. C'est ça. Donc, vous n'aurez même pas à faire cette étape, tout ce que vous avez vraiment à faire est de le pousser vers le haut, et de laisser la demande de traction passer à ce repo, à quel point je vais réellement l'ajouter au livre de cuisine. Mais ce que vous pouvez faire lorsque vous allez sur Skillshare pour votre projet final, c'est juste de prendre une capture d'écran de votre version, votre profil de ceci. Il suffit de prendre une capture d'écran et de poster cela comme le projet final. Ça devrait le faire. Merci beaucoup d'avoir pris ce cours, j'apprécie vraiment. Si vous l'avez trouvé utile, une évaluation positive rend vraiment cette classe plus facile pour d'autres personnes à trouver, laisse flotter vers le haut un peu. Donc, si vous avez trouvé cela utile, veuillez lui donner un avis positif et aider d'autres personnes à le trouver. Bien sûr, si vous avez des commentaires, positifs ou négatifs, j'aimerais l'entendre. Alors peut-être que je peux rendre ce cours encore un peu meilleur. Merci encore et bonne chance. Une dernière chose que je veux vous dire est que, j'ai mis en place gitforvisual.com. Comme vous pouvez le voir, il n'y a pas beaucoup là-bas en ce moment. Mais ce qu'il a, c'est ce PDF que vous pouvez télécharger. C' est essentiellement une feuille de triche qui traverse tout ce processus que nous avons traversé ensemble ici dans la classe. C' est quelque chose que vous pouvez garder à portée de main si vous voulez juste une référence rapide pour le flux de travail que nous avons décrit. Donc là, vous l'avez. Encore une fois, merci beaucoup. J' apprécie vos commentaires, et j'apprécie Skillshare, et Git. Merci beaucoup. Au revoir.