Masterclass sur Git et GitHub - Accélérez votre parcours vers Git !

1. Vidéo d'introduction: Bienvenue dans ce cours sur Git et GitHub. Voici quelques raisons pour lesquelles vous devriez apprendre Git et GitHub. Plus de 83 millions de dollars dans le monde utilisent Get up. 90 % des entreprises financées par Fortune utilisent GitHub. Plus de 200 millions de référentiels sont des projets résidant actuellement sur GitHub. Github est un élément clé de votre parcours DevOps. En fait, si vous souhaitez poursuivre DevOps Catia, GitHub est un point de départ. Vous n'arriverez nulle part si vous n'apprenez pas GitHub. Github est également la plateforme d'hébergement de code la plus populaire par rapport à ses concurrents, comme Bitbucket ou GitLab, get est le système de contrôle de version le plus populaire qui ait jamais existé. C'est presque une compétence indispensable pour tout professionnel de l'informatique. Et je suppose que tu le sais déjà. Voici les objectifs de ce cours. Je vais vous apprendre tout ce que vous devez savoir sur Git et GitHub. Je l'utilise depuis 2014 et j'ai même expérience dans la gestion d'équipes et dans le respect des délais de projet. J'ai peaufiné le programme en conséquence. Et vous n'avez pas besoin de vous référer à d' autres livres ou à d'autres cours. Vous apprendrez tout ce dont vous avez besoin dans ce cours seul et vous n'avez pas besoin d'y aller. N'importe quoi au-delà de ça. Vous permet de gérer en toute confiance toutes les tâches de projet liées à Git et GitHub. Apprenez à contribuer à des projets open source et à vous mettre en confiance grâce à des entretiens. Mais pourquoi devriez-vous tirer des leçons de ce cours ? Aldi, des sujets importants et essentiels sont abordés dans les premiers chapitres. Et tous les sujets qui ne sont pas essentiels ou dont il est question plus tard dans le cours. Nous regardons juste pendant six à dix chapitres. Vous commencerez à vous sentir en confiance pour commencer à prendre la tâche plus tard pour vous lever. Cela étant dit, je vous recommande vivement de suivre le cours en entier. Pour apprendre le sujet dans son intégralité. Je combine plusieurs sujets connexes dans le même cours afin de vous faire gagner un temps précieux. S'il est logique pour moi de combiner plusieurs sujets connexes et les enseigner ensemble, je le fais toujours. Non seulement pour gagner du temps, mais aussi pour enseigner plus efficacement. Je vais vous apprendre cet objet avec des scénarios, des cas d' utilisation et des flux de travail réels . J'ai moi-même relevé certains des défis les plus difficiles du projet. Et je peux certainement utiliser cette expérience pour parler de certains scénarios du monde réel dans lesquels vous pouvez appliquer tous ces concepts. J'ai la capacité unique d'enseigner concepts très complexes d'une manière facile à comprendre. Vous le comprendrez vous-même une fois que vous aurez progressé dans ce cours. J'ai également des attentes quant aux personnes qui suivent ce cours. Oubliez ce que vous savez déjà et recommencez à zéro. Si vous connaissez déjà quelque chose sur Git et GitHub ou tout autre sujet connexe, je veux que vous supprimiez tout de votre esprit et que vous commenciez par un esprit propre. Sinon, vous pourriez entendre des terminologies contradictoires, ce qui pourrait alors vous embrouiller. dévouement et l' engagement à apprendre l'intersujet vivaient dans un monde de distractions. À moins que vous ne fassiez des efforts pour rester engagé et dévoué à l' apprentissage de la matière dans son intégralité, vous n'apprendrez vraiment rien. Pratiquez ce que j'enseigne. Pratiquer pour une fois équivaut à dix lectures effectuées par quelqu'un quelque part. Mais c'est parfaitement logique. Tu devrais essayer de mettre en pratique ce que j'enseigne. Sinon, vous risquez de perdre la trace du sujet et de vous embrouiller. Restez concentré sur un cours, que vous suiviez ce cours ou un autre cours, suivez-le complètement, puis passez à une autre source d' information si vous le souhaitez. Mais ne mélangez pas les choses, ce qui créera encore une fois beaucoup de confusion. Ne consacrez qu'une heure par jour sans aucune distraction. Il vaut mieux apprendre pendant une heure avec une concentration complète que d'apprendre pendant huit heures avec une concentration moins bonne. Gardez cela à l'esprit. Ensuite, nous allons commencer à comprendre ce qu'est get Github, qu'est-ce que le système de contrôle de version, etc., avec des exemples concrets ? C'est une excellente façon de commencer notre cours. Je te verrai ensuite. 2. 0101 Besoin d'un système de contrôle de version et de Git partie 1: Pourquoi avons-nous besoin d'un système de contrôle de version ? Voici M. Bob, qui est conseiller en placement. Et grâce à tout le travail incroyable qu'il fait, sa clientèle a considérablement augmenté au fil du temps. Et il voit donc un besoin d'avoir son propre site Web personnel. Bob avait donc imaginé un site Web qui lui était propre. Et Bob étant un gars non technique, il a pensé à prendre l'aide d' un pigiste pour faire le travail. Il a donc rencontré un expéditeur qui est un freelance ou lui a expliqué tout ce qui s'attend son site web et a donné la date limite au 24 février, qui se trouve être son anniversaire à c'est sous un grade et a commencé à travailler sur le projet. Des informations sur ces ordinateurs. Il y avait créé ce dossier appelé application d'investissement, à l'intérieur duquel il a créé tous ces fichiers qui feront de ce site Web. Après quelques jours d'arrêt, cylinder avait fini travailler à la création du site Web. Il l'a testé. Il l'a également hébergée sur un fournisseur d'hébergement ou sur un fournisseur de services Cloud. Mon Dieu, l'application est opérationnelle et je l'ai montrée à Bob. Bob a été très impressionné par le travail de Sunder. Et maintenant, il a décidé d'ajouter quelques fonctionnalités supplémentaires à son site Web. Et la date limite est le 20 février. Deux marchandises plus tôt, une fois de plus, avaient accepté l'offre et ont commencé à marcher sur ces fonctionnalités supplémentaires. Et encore une fois, Cinder avait ajouté toutes ces fonctionnalités, hébergée sur un fournisseur d'hébergement, mis en place le site Web et l'avait montré à Bob. Mais cette fois, Bob n'était pas complètement satisfait du travail. Même si les dernières fonctionnalités ont été introduites après le 24 février, nous fonctionnons bien. Les fonctionnalités qui fonctionnaient auparavant semblent avoir cassées ou ne fonctionnent pas comme prévu. Bob avait donc expliqué les deux mêmes cinder et lui avait demandé d'annuler tous les nouveaux changements et de ramener l'application à ce qu'elle était le 24 février. Ils sont bientôt acceptés avec hésitation. Mais malheureusement pour Cinder, ce ne sera pas une tâche facile d' annuler toutes ces modifications car il y a beaucoup de nouveau code introduit après le 24 février, et le code s'est dispersé sur plusieurs fichiers. Il est très difficile pour l'expéditeur se souvenir de chaque ligne de code introduite et d'annuler toutes ces modifications. Cependant, depuis celui qui a accepté l'accord, pour garder le client heureux, après de nombreuses nuits blanches et après beaucoup de frustration et beaucoup de centre de test a finalement fait le travail. Cependant, cette fois, au milieu de la date limite de Bob, Bob se demandait pourquoi il avait fallu moins de deux semaines pour annuler les modifications. Eh bien, il ne lui a fallu que quelques jours pour créer l'ensemble du site Web. Cela a fait en sorte que Bob n' était pas satisfait et a rapidement commencé à voir des problèmes similaires avec certains de ses autres clients également. Ils se plaignaient que certaines fonctionnalités ne fonctionnaient pas comme prévu, ce qui avait fonctionné auparavant. Ils ont donc voulu les corriger ou revenir aux versions précédentes de leurs applications Web qui fonctionnent correctement. Alors Sunder y a réfléchi et a finalement trouvé une idée géniale, qui résolvent quelque peu ce problème. Nous en reparlerons dans un moment. 3. 0102 Besoin d'un système de contrôle de version et de Git partie 2: Donc, ce qu'il y a là-dedans avait commencé à remarquer, c'est qu' il n'avait pas de sites Web clients Office de sauvegarde. Si vous aviez une sauvegarde de leurs sites Web, il aura la possibilité revenir à la version de travail précédente de leur site Web ou au moins n réside le problème en comparant une version à l'autre. Cylinder a eu une idée géniale pour résoudre ce problème. Ce que vous avez commencé à faire maintenant est, par exemple, de considérer l'application d'investissement dont nous parlions. Cinder crée un dossier appelé application d'investissement V1 et 14 mars, date à laquelle ce projet a été livré au client. Et puis supposons que Bob lui ait demandé d'introduire quelques nouvelles fonctionnalités. Ce cylindre temporel ne va pas apporter modifications à cette partie du projet. Au lieu de cela, il va faire une copie de ce projet, le nommer V2 et introduire toutes les nouvelles fonctionnalités. Et de même, si Bob devait demander à certains d'ajouter encore plus de fonctionnalités, il va faire une copie de la dernière version de son projet, nommer V3 par exemple. Ensuite, apportez toutes les modifications nécessaires, et ainsi de suite. Ainsi, chaque fois qu'il a introduit une nouvelle fonctionnalité ou introduit un énorme morceau de code, il va simplement copier le dossier ou le projet et apporter les modifications nécessaires. Cette fois-ci. Encore une fois, supposons le même cas où Bob se plaignait que Washington auparavant ne fonctionne pas comme prévu, et qu'il souhaitait retourner à Washington V3, qui fonctionnait bien si tôt qui ne doivent décoller leur pied pour annuler tous les changements. Il pourrait simplement supprimer le dossier V4 du serveur et le remplacer par version de travail V3 du site be-bops. Ou si Bob l'avait insisté pour corriger le bogue, il peut réellement comparer les fichiers entre v3 et v4 en utilisant un logiciel de comparaison comme Beyond Compare, par exemple, identifier exactement les changements qui ont été nouvellement introduit, analysez le problème et résolvez-le. Bien que cela ait quelque peu résolu le problème, j'ai soudainement commencé à réaliser que cela prenait plus de mémoire que nécessaire. Parce que l'expéditeur ne fait pas seulement une copie de tous les fichiers qu' il a modifiés, mais également des fichiers qu'il n'a jamais touchés. Cela va donc prendre beaucoup de place et cela devient vraiment difficile à gérer pour les similaires. J'ai donc soudainement eu une bien meilleure idée, qui est en fait de créer des versions des fichiers à l'intérieur du projet. Qu'est-ce que je veux dire par là ? Supposons donc que vous ayez à nouveau un projet comme celui-ci avec tous ces fichiers. Bien sûr, dans ce cas, je les ai nommés HTML, mais cela peut être n'importe quel fichier, peut s'agir d'un fichier image, d'un fichier CSS, d'un fichier JavaScript, d'un fichier java, peu importe. Pour les besoins de cet exemple, supposons que nous avons tous ces fichiers. Maintenant, supposons que le centre introduit une nouvelle fonctionnalité qui a quelque chose à voir avec les fichiers B et C. Donc, au lieu de créer une copie de l'ensemble du dossier, il va faire une copie de la dernière version de ces deux fichiers. Cela va faire une copie du fichier B et du fichier voir, introduire tout le code requis pour la fonctionnalité 1. Et si vous voulez introduire une autre fonctionnalité, et cette fois en supposant que les modifications doivent aller et déposer le fichier, voir certaines de ces fonctionnalités vont simplement faire une copie des dernières versions du fichier a et fichier. Voyez, par exemple, dans ce cas, il va faire une copie du fichier ici ainsi qu'une copie du fichier C, version 1, qui contient la dernière version du fichier C. Ensuite, il va introduire la nouvelle fonctionnalité dans ce fichier. Une fois, je peux supposer que Bob avait demandé à Sunder de supprimer complètement la fonctionnalité et que nous souhaitons revenir à la version antérieure de son site Web de marche. Devinez Watson, ils peuvent simplement l'extraire des fichiers V2 et ne garder que les fichiers V1 aussi simples que cela. Et si vous voulez corriger le bogue à la place, il peut simplement comparer le fichier de la version 1 avec Washington to File et identifier exactement ce qui ne va pas en utilisant un logiciel de comparaison comme Beyond Compare. Cependant, Watson ils ont commencé à remarquer que même cela n'est pas faisable parce qu'il devient incroyablement complexe de gérer plusieurs projets clients. Par exemple, l'expéditeur doit renommer tous ces fichiers avec leur nom d'origine avant les déployer sur le serveur distant. Et il a également commencé à remarquer que ses fichiers ne cessent d'augmenter, ce qui crée un problème non seulement en termes d' organisation des fichiers, mais aussi en termes de prise de place. En ce moment, depuis que je commence à réaliser qu' il est temps de laisser le logiciel faire le travail à sa place. Un logiciel qui gérera les versions comme un logiciel qui suivra les modifications historiques, créera des sauvegardes et permettra l' inversion des modifications, etc. C'est la raison principale pour laquelle quelqu'un a dû venir quelque part avec le logiciel qui fera ce travail. Et c'est la naissance de get. Maintenant, get fait bien plus que cela. Mais je ne parle pas d'eux pour le moment parce qu'à ce stade, vous ne savez pas ce qu'est la branche de collaboration d' équipe GitHub dans la fusion et ce genre de choses. Je vais les conserver pour les prochaines conférences. Et je suis presque sûr que vous devez également avoir des questions comme, qu'est-ce que GitHub ou GitLab , qu'est-ce que la création de branches, etc. Je ne peux pas tout placer sous une seule vidéo, comment les patients et regarder le reste du cours. Et vous trouverez les réponses à toutes les questions que vous pourriez vous poser. Mais à vrai dire. J'aime la rapidité avec laquelle la maintenance est une expression de smiley tout au long. Peu importe comment sa vie tourne autour de lui. Il y a quelque chose à apprendre, n'est-ce pas ? Qu'est-ce que tu viens de dire ? Non. Non. Je dis juste que tu as un grand sens de la mode. OK. 4. 0103 VCS Comment cela fonctionne: Voyons comment le système de contrôle de version, ou simplement le logiciel visio, fonctionne à un très haut niveau. Encore une fois, supposons que nous avons sunder, qui est un développeur indépendant, et cylindre a un nouveau client, Linda, qui est propriétaire d'un restaurant, et elle voulait avoir un site Web pour son restaurant. Donc pour accepter les commandes en ligne de nos clients. après leur sourire, on peut dire qu'il est prêt à se lancer dans le projet. Mais sur la base de ses mauvaises expériences passées avec certains de ses autres clients qui ont maintenant décidé d'utiliser un logiciel VCS pour gérer le versionnement. Cylinder dans son ordinateur local, crée un dossier avec le nom app restaurant, passe quelques jours et introduit tous les fichiers nécessaires à la création d'un site Web fonctionnel minimum. Le logiciel vidéo disposera son propre magasin de données pour stocker toutes les données historiques et les sauvegardes. Quand je dis que Datastore ne doit pas nécessairement être une base de données relationnelle ou une forme quelconque de logiciel de base de données. Cela peut être aussi simple qu'un système de fichiers. Nous vendons des logiciels qui ont généralement tendance à utiliser votre propre système de fichiers pour stocker les sauvegardes et les données historiques. fur et à mesure que nous progresserons dans le cours, vous comprendrez mieux ce concept. Mais pour l'instant, supposons qu'il s'agit d' une sorte de sauvegarde pour stocker l'état du projet. Supposons maintenant que cylindre soit très satisfait des progrès qu'il a réalisés dans son projet. Il a un site Web fonctionnel minimum et a tout testé. Tout fonctionne très bien. Elle a donc décidé de sauvegarder l'état de ce projet en cours. Donc pour le récupérer en cas de besoin. Il va donc demander au logiciel visio stocker l' état actuel du projet, généralement en exécutant une commande. Une fois qu'il exécute la commande que nous voyons logiciel fait essentiellement une copie de tous les fichiers et les stocke dans le magasin de données. Supposons maintenant que l'expéditeur ait une nouvelle exigence pour introduire la fonctionnalité 1. Et supposons que tous ces changements de code devraient aller dans un fichier, bn fichier, voir certains qui ont apporté toutes ces modifications. Encore une fois, va exécuter la commande pour enregistrer l' état de son travail en cours. Mais cette fois, le vizir soft, nous stockerons les informations légèrement différemment par rapport à la façon dont elles étaient stockées précédemment. C'est ainsi qu'il va être stocké. Comme aucun changement n' a été introduit dans le fichier a, le logiciel VCU ne stockerait que la référence de defile a. Cela signifie qu'il contiendra uniquement des informations sur l'emplacement où ils déposent une copie résidant. Et la raison en est évidente. Nous ne voulons pas faire une copie inutile de tous les fichiers intacts ou non modifiés et occuper cet espace. En ce qui concerne les fichiers B et C, cependant, nous avons introduit de nouvelles modifications. Mais le logiciel le plus simple ne va pas faire de copie de ces fichiers. ADR. Ce qui va être stocké est en fait la différence entre le fichier modifié et la dernière version du même fichier. Et il va stocker la même chose dans le datastore. Nous appelons chacun de ces éléments un mauvais ensemble. Essentiellement, un mauvais ensemble est la différence entre le fichier d'origine et la dernière version du même fichier. Et la raison en est une fois de plus évidente. Nous voulons économiser cet espace autant que possible. De même, supposons que nous ayons une nouvelle fonctionnalité appelée fonctionnalité à laquelle est introduite. fichiers A et B ont été modifiés. Et c'est ainsi que le logiciel VCS stockerait les données. Nous avons donc des ensembles PAD pour le fichier a et le fichier B. Ensuite, pour le fichier C, nous allons uniquement stocker la référence de sa version précédente. Et supposons de même que nous avons une autre fonctionnalité. Nous allons apporter des modifications au fichier B. Et c'est ainsi que le logiciel VCO, qui stocke les informations, suppose maintenant que cylindre n'est pas satisfait de la version du fichier brut B et qu'il Je voulais revenir à la troisième version du fichier B. Il va donc insérer la même chose dans le logiciel Vizier. Le logiciel de visa récupérerait alors la copie originale du fichier B, puis appliquerait tous les correctifs qui ont suivi jusqu'à la version trois pour constituer le fichier B de la version trois et va redonner à dimanche. Il peut en faire ce qu'il veut. auditeur similaire peut également écrire la commande demandant au logiciel d'obtenir la torsion trois du projet entier, par exemple, et c'est exactement ce que le logiciel va faire. Maintenant, il existe évidemment de nombreux logiciels de vizir disponibles sur le marché. Nous avons de bons Mercurial, SVN, etc. Et ils diffèrent tous légèrement en termes de gestion des données historiques. Mais en général, c'est ainsi que l'on gère les données historiques. Maintenant, plongeons-nous en profondeur et comprenons ce qui se passe exactement , ce qui s'est passé, pourquoi ? Je me fiche de savoir comment ça fonctionne en interne. Cela ne m' aide pas dans mon travail de toute façon. Je veux juste savoir comment utiliser le logiciel. C'est logique. C'est logique. Juste une dernière vidéo , puis nous commencerons à installer le portail et à nous salir les mains avec beaucoup d'entraînement. Que penses-tu de ça ? Merci. Tu es le bienvenu. 5. 0104 DistributedVCS: Parlons du système de contrôle de version distribué. Linda est très heureuse du travail accompli d'ici dimanche et elle a commencé à remarquer une augmentation des revenus de notre entreprise depuis qu'elle a lancé un site Web. Et en raison de l' augmentation des demandes des clients, elle a maintenant décidé d'avoir encore plus de fonctionnalités sur son site Web. Elle veut que la deuxième approche soit de faire le travail à sa place. Mais cette fois, en raison demandes croissantes de nos clients, elle a un délai très court à surveiller. Sender a accepté l'accord, mais quelqu'un est tout à fait conscient du fait qu'il ne peut pas le faire tout seul et qu'il avait besoin d' embaucher quelques personnes dans son équipe, l' aider à livrer le projet à temps. Sunder a embauché quelques personnes pour rencontrer Asia et Luke, qui sont les nouveaux membres de l'équipe. Sender leur a également fourni un tout nouveau MacBook Pro, leur a partagé les fichiers du projet ou le code. Ou peut-être qu'il a hébergé un serveur FTP, partagé le lien et leur a demandé de télécharger. Et il leur a également demandé d'installer le logiciel sur l'ordinateur local, compte tenu de tous ses avantages. Bien sûr, under a sa propre inscription locale et son propre ensemble de problèmes au fur et à mesure qu'ils progressent dans le projet. Depuis que j'ai commencé à remarquer quelques problèmes avec l'utilisation d'un système de contrôle de version local. Certains des problèmes auxquels ils sont confrontés sont absence de changements historiques d'autres membres. Par exemple, s'il souhaite examiner modifications historiques apportées au fichier a, elle ne peut examiner modifications historiques qu'elle a apportées, mais elle n'a pas accès à les données historiques de quelqu'un d'autre, par exemple, cylinder, parce qu'il n' a accès qu'à son propre magasin de données, mais pas dans ce magasin de données. Maintenant, c'est clairement un problème. À moins d'avoir accès à l'historique complet des modifications, elle ne peut pas travailler efficacement sur une tâche. Un autre problème est qu'il est difficile de maintenir la dernière base de code. Chaque fois que quelqu'un apporte une modification, il doit informer les autres développeurs qu'il a effectué ce changement et qu'il doit également copier ce code sur sa machine locale. Donc, pour avoir la dernière version du code sur tous les ordinateurs, c'est bien sûr pratiquement impossible, surtout lorsque plusieurs membres de l'équipe travaillent sur une seule base de code. Et les choses deviendraient encore plus compliquées si deux personnes travaillaient exactement sur le même dossier. Un autre problème est l'absence de gestion centralisée des rôles ou de contrôle d'accès. Par exemple, supposons que quelqu' un souhaite restreindre l' accès ensemble particulier de dossiers dans le projet, mais pas aux autres dossiers. Eh bien, avec le système de contrôle local de Washington, il n'a pas le contrôle là-dessus. Sender a réfléchi à tous ces problèmes auxquels il est confronté et a fait une recherche sur Google. Et finalement est venu avec ce que l'on appelle un système de contrôle de version centralisé. Cela signifie simplement que cette fois, au lieu d'avoir le magasin de données, ainsi que le code dans les inscriptions locales sont sur les machines locales. Il se trouvera sur un serveur centralisé. Et tout le monde choisissait le code sur le serveur centralisé, travaillait dessus, puis le renvoyait au serveur pour que d'autres puissent utiliser son code. Et avec cela, nous pouvons nous débarrasser de tous les problèmes que nous avons rencontrés avec système de contrôle de version local. Encore une fois, si esa veut jeter un œil à toutes les données historiques d'un fichier particulier, elle y aura facilement accès. Parce que cette fois-ci, tous les ensembles de chemins sont conservés dans un serveur centralisé et tous les développeurs y ont accès. Et avec une simple commande, tout le monde pourrait obtenir le tout dernier code et commencer à travailler dessus. Donc pour éviter les conflits. Cinder peut également mieux contrôler qui peut accéder à quoi. Comme tout est hébergé sur un serveur centralisé, il peut désormais commencer à utiliser le contrôle d'accès basé sur les rôles. Et il aura le contrôle sur qui peut accéder à quels dossiers du projet, et cetera. Cependant, les systèmes de contrôle de version centralisés présentent leurs propres problèmes. Par exemple, que se passe-t-il si plusieurs sont lancés ? Ou que se passe-t-il si quelqu'un pirate le serveur ? Et s'il montre qu'il a des problèmes de connexion ? Peut-être que son Wi-Fi ne fonctionne pas. Dans tous ces cas, développeurs ne peuvent pas travailler sur le projet. Ils risquent également de perdre l'intégralité du code s'ils ne sont pas en mesure d'enregistrer le serveur. Compte tenu de tous ces inconvénients offre un système de contrôle de version centralisé, a dû trouver une alternative. Et c'est ainsi qu'il est tombé sur un système de contrôle de version distribué. Il s'agit essentiellement du meilleur des mondes du VCS local et du VCS centralisé, éliminant ainsi tous leurs inconvénients. Cette fois avec un système de contrôle de version centralisé. Au lieu d'avoir un seul dépôt comme serveur centralisé. Ici, chaque durable aura son propre serveur et chacun des développeurs aura une copie de l'historique complet ou des versions du code sur sa propre machine locale. Cela signifie que même si le serveur doit aller pour une tâche, chacun a sa propre copie locale de l'ensemble du code ainsi que les données historiques. Et si quelqu'un comme Asia, quoi perdre la connectivité, peut-être à cause d'une connexion Wi-Fi, elle peut encore progresser parce qu'elle a tout dans son ordinateur local. Elle peut apporter des changements. Et chaque fois que la connexion revient à la normale, elle peut livrer le code au serveur centralisé afin que d'autres développeurs puissent les obtenir et en faire quelque chose. Ou en cas de perte de données, chaque dollar plus une sauvegarde de l' ensemble de la base de code. Ils peuvent donc se souvenir de certains exemples de systèmes de contrôle de version centralisés ou CVS Subversion ou simplement de SVN Perforce, ou de certains exemples de systèmes de contrôle de version centralisés. distribués sont des exemples de systèmes de contrôle de version Mercurial, Bazaar et Git sont des exemples de systèmes de contrôle de version distribués. Git est un système de contrôle de version distribué. Tous les développeurs devraient installer Git sur la machine locale. En plus de cela, nous avons également GitHub, qui agit comme un serveur centralisé. Je pense que nous avons acquis suffisamment de connaissances pour commencer à travailler avec Git. 6. 0105 InstallingGit: Voyons comment nous pouvons télécharger, installer et configurer, et obtenir notre inscription locale. Supposons maintenant que je suis pigiste et que j'ai un tout petit projet sur lequel je pense pouvoir marcher seul. Oubliez la collaboration d'équipe, oubliez les multiples personnes impliquées dans le projet. Oubliez GitHub pour le moment. Restons simplement concentrés sur obtenir. Allez donc sur Google et recherchez le téléchargement, obtenez le premier lien, mais assurez-vous qu'il appartient au site Web. Obtenez le code d'union SCM. C'est le site officiel de get. Une fois que vous y êtes, en fonction du système d'exploitation que vous utilisez, cliquez sur le lien correspondant. Au moment où vous consulterez cette page, il se peut que vous voyiez une mise en page différente. Mais tu as compris. Il vous suffit de cliquer sur le lien spécifique à votre système d'exploitation. J'utilise Windows. Dans mon cas, si vous utilisez macOS, il existe un ensemble d'instructions distinct pour le même. Il suffit de les suivre. Et pendant l'installation, vous pouvez tout laisser aux valeurs par défaut et poursuivre l'installation. Et il n'est pas nécessaire que vous compreniez chaque étape de l'installation. C'est parfaitement normal. Si vous rencontrez des problèmes lors de l'installation dans les sets macOS, contactez-nous et nous serons en mesure de vous aider. Mais comme j'utilise Windows, je vais cliquer ici. En gros, j'ai deux options. La première est la version d'installation de Git, et l'autre est la version portable de Git. Si je télécharge la version portable, je peux commencer à utiliser Git sans avoir à l'installer. Et cela peut s'avérer pratique, surtout si je veux travailler sur plusieurs ordinateurs et que je ne veux pas installer Git sur chaque ordinateur. Je peux simplement vider tous ces fichiers sur une clé USB ou une clé USB, puis commencer à utiliser correctement sur tous ces ordinateurs. Mais je vais opter pour l'installateur. J'utilise un système d'exploitation 64 bits, je vais donc cliquer dessus. Eh bien, pour les utilisateurs de Linux et de Mac, vous avez peut-être déjà installé Git. Vous pouvez simplement le vérifier en exécutant une commande. Je vais vous montrer cette commande dans un moment. Ou vous avez peut-être déjà ces bibliothèques, il vous suffit donc de les installer. Vous pouvez vous reporter aux instructions d'installation pour cela. J'ai donc téléchargé cela. Commençons maintenant le processus d'installation. Si vous avez des patients qui passent par cette licence complète, je n'ai pas beaucoup de patients, j'ai juste cliqué sur Suivant. Maintenant, lors de l'installation de Git vous pouvez rencontrer certaines étapes, certaines invites, certaines terminologies qui ne vous semblent pas familières. C'est parfaitement bien. En règle générale, n'oubliez pas de conserver les valeurs par défaut et de procéder à l'installation. Il n'est pas nécessaire que vous compreniez chacune des étapes de ce processus d'installation. Depuis que j' y travaille depuis longtemps. Je comprends ce qui est demandé ici. Mais pour toi, tu n'as pas besoin de tout comprendre. Je vous expliquerais uniquement les étapes que je pense que vous serez capable de comprendre en fonction du niveau de connaissances que vous avez acquis jusqu'à présent dans ce cours. Je pourrais donc tout laisser aux valeurs par défaut. Mais ce que cette invite nous demande essentiellement, c' est qu'elle nous demande de choisir les composants que nous voulons installer. Nous allons parler de Git Bash et c'est parti. Dans la prochaine conférence. Vous pouvez simplement ignorer et conserver le reste de ces éléments aux valeurs par défaut. Nous ne voulons pas entrer dans les détails. Ce n'est pas ce qu'il s' agit ici de vous demander de choisir un logiciel pour éditer les fichiers point get. J'ai installé Notepad Plus Plus sur mon ordinateur, et je peux le choisir. Et je vous recommande également d'utiliser le même logiciel. Il est open source. Vous n'avez rien à payer pour cela. Téléchargez Notepad Plus, Plus, c'est un outil incroyable. Choisissez cette option et cliquez sur Next. Laissez cette option par défaut car vous ne savez pas ce qu'est une branche à ce stade. Cela n'a donc aucun sens pour moi de vous expliquer cette étape. Nous allons donc laisser cela par défaut. Ok, dans cet onglet , nous demande essentiellement si nous allons utiliser Git Bash uniquement ou allons-nous également utiliser la ligne de commande de Windows ? Cette étape est spécifique à Windows. installation similaires ne s'affichent peut-être pas. Si vous essayez d'installer Git sur un autre système d'exploitation comme Linux ou macOS, vous pouvez voir un ensemble d'instructions complètement différent . Mais comme je l'ai dit, laissez tout à leurs valeurs par défaut et terminez l'installation. Mais ici, si je choisis cette option, get va ajouter une variable de chemin dans variables d'inscription système afin que nous puissions commencer utiliser les commandes Git sur le processeur de commandes Windows. Si vous choisissez cette option. Cependant, cela ne va pas se faire avec une hypothèse qui utiliserait uniquement Git Bash. Encore une fois, nous allons parler de Git Bash, soyez gris dans la prochaine conférence. Ensuite, je vais laisser ce paramètre par défaut. En gros. Il leur demande s'ils veulent utiliser OpenSSH existant ou si vous l'avez déjà installé. Vous pouvez simplement le pointer du doigt. Mais nous allons utiliser OpenSSH qui est fourni avec good. Au fait, une ouverture qui vous permettrait essentiellement de vous connecter à la machine distante de manière sécurisée. Plus d'informations à ce sujet dans les prochaines conférences. Laissez également cette option par défaut. Évidemment, vous ne comprenez pas ce qu' est le combat ou ce checkout, donc je ne peux rien vous expliquer à ce sujet pour le moment. Laissez-le à la valeur par défaut. Conservez la valeur par défaut. Ok, on parle de git pull. Encore une fois, c'est trop avancé pour que vous puissiez le comprendre. Il suffit de tout laisser aux valeurs par défaut. Je suis britannique ou vous ne comprenez peut-être pas toutes les étapes ici. N'essayez même pas de comprendre que ce n'est pas nécessaire. Nous allons tout explorer lors des prochaines conférences. C'est parfaitement normal. Si tu ne comprends pas, c'est très bien. Fais-moi confiance. Cliquez sur Suivant. Activez la mise en cache du système de fichiers. Oui, nous voulons, cela améliorerait les performances. Nous pouvons également le désélectionner et cliquer sur Installer. Attends un peu. Très bien, je ne veux pas lire les notes de publication. Finition de la tête. Bon, nous avons maintenant installé sur notre machine locale. Allons vérifier. S'il a effectivement été installé. Je suis fenêtre ouverte, processeur de commande Windows. Ensuite, tapez get. Si vous pouvez voir une sortie comme celle-ci. Cela signifie que get a été installé avec succès. Et la raison pour laquelle nous sommes capables d'exécuter la commande git à partir du processeur de commandes Windows est que quelque part au milieu du processus d'installation, nous avions demandé d'inclure la variable path de obtenir dans les variables d'inscription Windows. Laissez-moi vous montrer ce que je veux dire. Recherchez des variables d'inscription. Cliquez sur Modifier les variables d'inscription système. Si vous allez sur le chemin. Ici, vous verrez le chemin pour obtenir la bibliothèque. Ainsi, chaque fois que vous exécutez une commande, quelque chose comme ça s' exécutera simplement. exploitation Windows va en fait jeter un coup d' œil à toutes ces parties répertoriées ici. Et puis il rencontre cette partie où il a le code pour faire quelque chose avec la commande GET. Nous sommes donc en mesure de voir cette sortie. Si vous le supprimez, nous ne serons pas en mesure d' exécuter de commandes Git à partir du processeur de commandes Windows à moins que nous n'accédions explicitement à ce répertoire et que nous ne le fassions. Quoi qu'il en soit, si tout cela semble déroutant, ignorez simplement , croyez-moi, vous allez tout comprendre dans les prochaines conférences. 7. 0106 Git CLI vs Git Bash vs Git GUI: Il existe essentiellement trois manières d'interagir avec Git. Nous pouvons soit utiliser gets CMD ou Git Bash, soit obtenir une interface graphique ou une interface utilisateur graphique. Gets CMV n'est rien que le processeur de commande Windows que nous utilisons pour exécuter des commandes git. En fait, nous avions déjà examiné un exemple similaire lors de notre précédente conférence, où nous étions en train de tester l' installation de getting. L'autre option que nous avons est d'utiliser Git Bash, un outil que nous avions installé avec Git. Git Bash est similaire au processeur de commandes Windows, sauf que nous pouvons utiliser commandes Linux standard pour interagir avec good. Cela sera pratique, surtout si vous venez de arrière-plan Linux où vous êtes habitué à exécuter des commandes Linux. Et maintenant, supposons que vous travaillez à partir du système d'exploitation Windows. Vous n'avez pas besoin de suivre cette courbe d'apprentissage supplémentaire pour comprendre la commande Windows afin d'interagir avec Git. Par exemple, pour répertorier tous les fichiers d'un dossier particulier dans la ligne de commande Windows, utilisez la commande ici. Alors que sous Linux, vous utilisez la commande ls pour lister tous les fichiers. Si vous utilisez un Mac ou Linux, ils sont tous deux fournis avec un shell Unix. Vous n'êtes pas obligé d' installer Git Bash. Git Bash est uniquement destiné au système d'exploitation Windows. Si vous n'êtes habitué à aucun de ces outils, il est évidemment préférable de choisir Git Bash plutôt qu'un bon cmd. Et la raison en si vous êtes habitué à Git Bash, vous pouvez également travailler sur le système d'exploitation Linux ultérieurement, si vous le deviez. La troisième option que nous avons est d'obtenir une interface graphique ou une interface utilisateur graphique. Et comme son nom l'indique, cet outil fournira une interface utilisateur graphique pour interagir avec Git. Maintenant, je dois mentionner que get gooey ne prend pas en charge toutes les fonctionnalités que get a à offrir. Nous pouvons faire plus avec Git Bash ou obtenir combats CMD pour gagner de la gloire. Cela étant dit, une bonne interface graphique a également son propre rôle. Par exemple, si vous souhaitez avoir une vue d'ensemble, ou si vous souhaitez avoir une vue d'ensemble de l'ensemble des changements historiques, etc. Ensuite, vous pourriez trouver utile d'utiliser la requête get pour obtenir cet argent. Cependant, dans la suite du cours, nous utiliserons Git Bash car c'est la meilleure option. Nous pourrions aussi bien explorer le chemin du départ à un moment donné du cours. Mais nous allons nous concentrer principalement sur Git Bash, qui est également le choix populaire. 8. 0107 Commandes de base de Bash: Jetons un coup d'œil à certaines des commandes de base que nous pouvons exécuter sur Git Bash pour interagir avec le système de fichiers Windows. Maintenant, si vous venez d' un environnement Unix ou Linux, vous connaissez probablement toutes ces commandes. N'hésitez pas à ignorer la vidéo. Vous n'êtes pas obligé de regarder le reste de la conférence. Et pour d'autres, vous vous demandez peut-être pourquoi nous avons ces commandes ? Eh bien, sous Windows, nous créons des dossiers. Jetez un œil à ce qu' il contient ou supprimez des dossiers. Nous le faisons graphiquement que Windows nous fournit. Toutefois, si vous voulez faire la même chose depuis Git Bash, nous devons utiliser ces commandes car Git Bash n'est pas fourni avec une interface utilisateur graphique. Vous avez peut-être une autre question. Pourquoi devons-nous interagir avec le système de fichiers à l'aide ces commandes alors que nous pouvons faire de même sous Windows ? Eh bien, la réponse est que tu peux le faire d'une façon ou d'une autre. Mais si vous apprenez ces commandes, cela pourrait vous être utile à l'avenir. Par exemple, si vous deviez travailler sur un système d'exploitation Linux, vous n'avez pas de système d'exploitation Windows. Vous devez interagir avec le système de fichiers l'aide de ces commandes. Et ces commandes ne sont pas non plus difficiles à apprendre. Ils sont en fait assez explicites. Par exemple, MKDIR signifie make directory. Et comme son nom l'indique, il vous aidera à créer un répertoire ou un dossier. Et puis nous avons CD pour change directory. Cela vous aidera à passer d' un répertoire à l' autre. C'est la commande que nous utilisons pour naviguer dans le système de fichiers. Et puis nous avons PWD signifie present working directory, qui affichera simplement le régime alimentaire sur lequel nous sommes en train de travailler sur Git Bash. Si vous vous demandez dans quel répertoire vous travaillez, c'est la commande à exécuter. Ensuite, nous avons Ls signifie list. Et cela listerait simplement tous les fichiers d'un répertoire particulier. Cette commande combinée avec l'option tiret a, liste tous les fichiers, y compris les fichiers cachés. Et enfin, nous avons notre M signifie remove. Et comme vous pouvez le deviner, cela nous aidera à supprimer un dossier ou un fichier. Maintenant, certaines de ces commandes vont avec certaines options. Nous les explorerons dans un moment. J'ai créé un dossier de test pour cette conférence. Et c'est là que nous allons expérimenter toutes ces commandes. Tout d'abord, lançons Git Bash. Vous pouvez lancer Git Bash soit à partir du menu Démarrer soit simplement cliquer avec le bouton droit de la souris et cliquer sur Git Bash ici, cela lancerait Git Bash dans le répertoire courant. Vous allez voir un écran qui ressemble à ceci. Commençons par créer un nouveau dossier. Il obtient donc la commande que j'ai besoin d'utiliser. C'est MKDIR signifie make directory. Et je vais fournir le nom du dossier ou du répertoire que je voulais créer. Appelons-ça mon application ou quoi que ce soit d'autre. Cela a donc créé un nouveau répertoire afin de s'assurer qu'il a bien créé un répertoire. Exécutons la commande ls pour répertorier tous les fichiers du répertoire courant. Et bien sûr, nous voyons le répertoire que nous venons de créer. Nous pouvons également ajouter un tiret d'option a pour répertorier tous les fichiers, y compris les fichiers cachés. Mais pour le moment, sur ce territoire, nous n'avons aucun fichier caché à afficher. Mais cette commande sera utile à l'avenir, en particulier lorsque nous voulons explorer le répertoire des cadeaux, qui a été masqué. Passons maintenant à l'intérieur du répertoire de l'application. Comment est-ce que je fais ça ? Parce que la commande cd pour changer de répertoire. Et je voulais mentionner ce répertoire, appuyez sur Entrée et nous sommes actuellement dans le répertoire MyApp. Pour être sûr que nous sommes dans ce répertoire. Laissons la commande PWD pour vérifier le répertoire de travail actuel, et cela imprimerait le répertoire de mon application. Passons maintenant au répertoire parent de mon application. Alors, comment est-ce que je fais ça ? Nous faisons de l'espace cd, une barre oblique point point. Si vous voulez aller dans le répertoire grand-parent, vous n'avez plus qu'une barre oblique. Et ça fera l'affaire. Cependant, je voudrais simplement aller dans le répertoire parent. Maintenant, faisons la commande ls pour lister tous les fichiers. Maintenant, disons que je veux supprimer ce dossier , obtenir la commande, RM et le nom du dossier. Mais cela ne va pas supprimer le dossier. Eh bien, il ne supprime pas le dossier parce que cet utilisateur n'a pas l'autorisation de le faire. Ou ce dossier contient peut-être des fichiers. Il nous demande d'abord de supprimer ces fichiers. Ce n'est qu'alors que cela nous permettra de supprimer ce dossier ? Cependant, nous savons que ce dossier ne contient aucun fichier. Ça doit être l'autre raison. Pour contourner ce problème, nous devons inclure une option avec la commande RM, c'est-à-dire le trait d'union r, f. R signifie récursif et F signifie force. Récursif signifierait que nous disons, non seulement voulons-nous supprimer ce dossier, mais également tous les fichiers qu'il contient ? Et l'effort est synonyme de force. En d'autres termes, nous voulons forcer la suppression du dossier quelles que soient les autorisations. Je vais spécifier le nom du dossier. Et cette fois, il supprime le dossier. Si nous le faisons maintenant, il n'affichera plus ce dossier. Prenez donc cinq à dix minutes pour essayer d' expérimenter et de jouer avec ces commandes. Essaie simplement de créer des dossiers, supprimer des dossiers, de regarder ce qu'il y a à l'intérieur des dossiers, etc. 9. 0108 Qu'est-ce que Git Commit: Vous avez probablement entendu parler de git commit, mais qu'est-ce que c'est exactement ? Allons y jeter un œil. Imaginez que vous jouez à un jeu vidéo. Et supposons que vous avez suffisamment progressé dans le jeu pour ne pas risquer de perdre. Vous sauvegardez la partie à ce moment-là en donnant un message significatif, vous continuez à jouer et vous progressez. Et encore une fois, tu as envie de sauver la partie. Et vous n'avez qu'à commencer par donner un message significatif. Et si quelque chose devait mal tourner dans votre jeu, il vous suffit de jeter un œil à la liste des sauvegardes que vous avez effectuées et de charger le jeu à un moment donné. Maintenant, vous devez noter que la sauvegarde ici n'est pas réellement une sauvegarde. C'est un peu comme un instantané. Par exemple, vous ne pouvez pas simplement copier le fichier de sauvegarde et le transférer sur un autre système où le même jeu est installé et pouvoir le charger à partir de ce point enregistré. Ce n'est pas possible. Cependant, s'il s'agit d'une sauvegarde, vous effectuez une sauvegarde complète du jeu. Par exemple, si le jeu se trouve dans un dossier, il vous suffit de copier le dossier entier, de le transférer sur un autre système et de démarrer le jeu à l'endroit où vous voulez commencer. Enregistré ici ressemble essentiellement à un instantané, mais pas exactement à une sauvegarde. Une analogie similaire peut être expliquée avec les points de restauration Windows. Vous créez peut-être plusieurs points de restauration en envoyant un message significatif. Et si quelque chose ne va pas avec votre système, peut-être un virus ou autre, j'aimerais vraiment que cela n'arrive pas. Mais si quelque chose comme ça se produit, il suffit de jeter un œil à toute la liste restaurée une fois que vous l'avez créée, d'en choisir une et de restaurer le système à son état antérieur. Tout comme vous avez restauré des points pour Microsoft ou une option de sauvegarde pour un jeu, vous avez git commit. Pour votre projet. Vous allez faire quelques progrès dans votre projet. Supposons, par exemple, que vous avez écrit un blog sur la première fonctionnalité. Ensuite, vous avez l'impression d'en avoir fait assez pour enregistrer le projet ou le valider. C'est ce que vous pouvez faire en utilisant la commande git commit. Ensuite, vous poursuivez le projet. Vous travaillez sur une autre fonctionnalité , puis vous validez le projet avec un message significatif. Et si quelque chose ne va pas avec votre projet, get vous permettra de revenir à l'état antérieur du projet ou de rétablir un fichier particulier à ses versions antérieures, etc. Tout comme saved n'est pas un sauvegarde dans un jeu. Git commit n' effectue pas réellement une sauvegarde de l'ensemble de votre projet, mais plutôt un instantané de votre projet à ce moment précis. Comme si vous aviez créé un projet avec tous ces fichiers. Et maintenant, vous avez l'impression d'en avoir fait assez pour enregistrer le projet ou valider toutes les modifications dans le dépôt. Maintenant, vous ne pouvez pas simplement lancer la commande git commit et mentionner tous les fichiers que vous souhaitez consulter. Cela ne fonctionne pas de cette façon. Malheureusement, il y a une étape supplémentaire à franchir avant votre arrivée. Et il y a une raison à cela. Par exemple, vous pouvez avoir d'autres fichiers dans le projet qui ne sont pas destinés à être validés. Vous ne voulez pas que les autres membres de l' équipe puissent accéder à ces fichiers. Par exemple, il peut s'agir de fichiers générés automatiquement ou de certains fichiers destinés uniquement à être utilisés localement, mais qui ne devraient pas être disponibles pour le monde extérieur. Et c'est là que nous avons une étape supplémentaire où vous devez laisser sans moteur tous les fichiers que vous vouliez suivre. Actuellement, tous ces fichiers votre répertoire de travail ne sont pas réellement suivis par Git. Vous devez lui indiquer explicitement quels sont tous les fichiers que vous souhaitez suivre. Vous pouvez le faire avec la commande git add. Vous souhaitez utiliser cette commande git add. Et vous avez mentionné tous les fichiers dans ce cas, nous allons mentionner par fichier de couches, fichiers C et D et exécuter la commande qui copierait essentiellement tous ces fichiers dans la zone de transit. Et c'est à ce moment que get commencera à suivre ces fichiers. Une fois cela fait, vous allez utiliser la commande git commit pour valider toutes les modifications dans un dépôt local, ou parfois appelé base de données d'objets. Et ce n'est pas le seul cas où vous pourriez avoir besoin de git add git commit. Examinons un autre cas d'utilisation. Imaginez que vous ayez quelques caractéristiques sur lesquelles marcher. Et vous avez travaillé simultanément sur les deux fonctionnalités en supposant que les modifications apportées à la fonctionnalité 1 sont entrées dans le fichier A et le fichier B. Et que les modifications de la fonctionnalité 2 ont été apportées aux fichiers C et D. Maintenant , nous voulons que ces deux fonctionnalités soient passer à différents commits, pas dans un seul commentaire. Comment faisons-nous cela ? S'il n'y a pas de concept de mise en scène ? Et si nous utilisions la commande git commit, qui validerait tous ces changements, nous ne voulons pas cela. Donc, avec la commande git add, nous allons d'abord ajouter tous les fichiers liés à la fonctionnalité 1. Ensuite, nous allons valider les modifications avec un message significatif, tout comme nous recevons un message significatif lorsque nous sauvegardons une partie. Nous allons également faire la même chose en sortant de la comète. Maintenant, une fois que vous aurez terminé, nous allons ajouter les fichiers C et D et valider en tant que fonctionnalité dans. Pendant un certain temps. Nous allons conserver tous ces commentaires dans notre dépôt local. De cette façon, nous serons en mesure de jeter un œil à toutes les données historiques, récompenser notre projet à son état antérieur. Ou nous pouvons faire ce que le fichier particulier à une version particulière de son historique passé. Nous pouvons également examiner la différence entre la version actuelle du fichier et ses versions antérieures, et ainsi de suite. Nous allons certainement explorer tout cela dans les prochaines conférences. Finalement, nous allons transférer toutes ces modifications vers un dépôt centralisé tel que GitHub. Tous les autres membres de l'équipe pourront ainsi accéder à vos modifications ainsi qu'à tous vos commentaires et données historiques. Mais c'est le sujet d'un autre chapitre. Je dois également mentionner que lorsque j'ai commencé à utiliser Git, j'ai rejoint une communauté GitHub locale. Maintenant, je leur ai posé cette question. Pourquoi avons-nous besoin de quelques étapes pour valider les modifications ? Pourquoi ne pouvons-nous pas simplement avoir une commande qui ressemble à ceci ? Nous allons mentionner git commit tiret m. Et ensuite vous allez envoyer un message. Ensuite, vous allez lister tous les fichiers que vous voulez valider et tous les fichiers que vous voulez qui peuvent correspondre à la fonctionnalité 2, par exemple. Eh bien, je n'ai reçu aucune réponse satisfaisante de leur part. En fait, si vous parlez d'autres systèmes de contrôle de version comme Mercurial ou subversive, ils n'ont pas cette étape supplémentaire qui consiste à ajouter les fichiers avant de les valider. 10. 0109 Initialiser le projet et le dossier "Exploring dot git": Voyons ce que cela signifie d' initialiser un projet. Afin de mieux comprendre cela, supposons que j'ai un contrat de freelance, alors qu'on me demande de créer une application Web pour mon client. Dans mon système, j'ai créé ce dossier avec le nom my app, dans lequel je vais introduire tous les fichiers nécessaires à la création d'une application fonctionnelle minimale opérationnelle. Maintenant, je pourrais créer tous ces fichiers en utilisant la nouvelle option ici. Mais je vais le faire en utilisant Git Bash juste pour vous familiariser avec toutes ces commandes Linux. Et les commandes que j'ai besoin d'utiliser s'appellent touch. Ensuite, je vais spécifier le nom du fichier. Pour plus de simplicité, je vais simplement l' appeler TXT à un point. Maintenant, cela n'a évidemment aucun sens d'avoir un fichier TXT pour écrire le code source. Mais nous ne sommes pas vraiment intéressés par la création d' applications ici, nous voulons apprendre, approfondir, émettre certaines hypothèses. De même, je vais créer deux tiges dxdy. Je me suis trompé de nom. Et trois points dx, dy. Renommons cela en TXT à deux points. J'ai donc créé tous ces fichiers. Mais actuellement, aucun de ces fichiers n'est réellement géré par Git. Par exemple, si je devais exécuter la commande git commit maintenant, cela va lancer un message disant qu'aucun dépôt Git ou aucun des répertoires parents ne l'est. Nous devons donc lui faire savoir qu'il doit gérer votre projet. Et la façon dont vous le dites est d'utiliser une commande git qui signifie initialisation. Une fois que nous avons initialisé le projet, nous demandons essentiellement à get de configurer un écrit, il doit être configuré dans notre projet pour commencer à gérer un projet. Je vais créer des versions sur demande. Et si vous remarquez, il a créé un dossier caché avec le nom dot get. C'est ici que se cette zone de transit dont nous avons parlé plus tôt. Et c'est là que se trouve la base de données d'objets dont nous avons parlé plus tôt. Si vous ne pouvez pas voir ce dossier, vous devez activer l'option permettant afficher les fichiers et dossiers cachés. Dans Windows, vous devez accéder à l'onglet Affichage, cliquer sur Options, cliquer sur Modifier le dossier et les options de recherche. Et encore une fois dans l'onglet Affichage, vous devriez pouvoir localiser cette option pour activer ou afficher les fichiers cachés. Et c'est ici. Cliquez sur cette option qui indique Afficher les fichiers, dossiers et lecteurs cachés. Cliquez sur Appliquer et OK, et vous devriez maintenant pouvoir trouver ce dossier. Jetons un coup d'œil à ce qu'il contient. Maintenant, évidemment, ça ne vaut pas vraiment la peine d'aller plus loin et d'essayer de comprendre tout ce qu'il y a à l'intérieur. Nous explorerons certains d'entre eux dans le reste du cours au fur et à mesure que nous le jugerons approprié. Mais pour l'instant, je vais juste vous donner un aperçu du contenu de ce dossier. Nous avons ce dossier hooks dans lequel nous avons un tas de scripts. Ces scripts définiraient ce qui doit être fait avant et après un événement particulier. Par exemple, nous connaissons déjà l'événement commit. Ensuite, nous avons le script avec le nom de pré-validation. Comme son nom l'indique, il fait quelque chose avant d' exécuter la logique de validation proprement dite. Donc, lancez ce script avant d'exécuter la logique de validation. se peut donc que nous ayons des choses comme la validation de la syntaxe, etc. Si vous êtes vraiment curieux de savoir ce que contiennent les scripts, vous pouvez cliquer avec le bouton droit de la souris et l' ouvrir avec Notepad Plus, Plus. Et passez simplement en revue tous ces commentaires et essayez de vous faire une idée de ce qu'il fait. Mais je ne te recommande pas de le faire. Ne vous embrouillez pas. Ensuite, nous avons le dossier d'entrée dans lequel nous avons ce fichier d'exclusion. Ouvrons-le avec Notepad Plus, Plus. S'il y a des fichiers dans votre projet que vous ne souhaitez pas prendre en compte, c'est ici que vous devez les lister. Vous pouvez également utiliser des motifs. Par exemple, vous pouvez dire « star dot log ». Et maintenant, get ignore tous les fichiers avec n'importe quel nom, mais possède l'extension dot log. C'est juste un exemple. Et au fait, le fichier d'exclusion est quelque chose qui est local à un ordinateur. Et tout ce que vous ajoutez ici ne s' applique qu'au sein de votre propre déposant, à l'intérieur de votre système local. Si vous voulez avoir des exclusions tous les membres de l'équipe, il existe un élément distinct pour cela appelé gitignore. Nous en reparlerons dans les prochains chapitres. Ensuite, nous avons le dossier des objets. C'est là que Good Foods stocke toutes les données historiques ou l'historique des versions. C'est ce que nous appelons la base de données d'objets. Eh bien, actuellement, ce dossier ne contient pas beaucoup de données. Mais une fois que nous aurons fait quelques commentaires, vous verrez ce dossier être rempli. Vous allez voir un tas de dossiers en cours de création. Dossier d'objets intérieurs. Nous avons le dossier ribs, mais cela n'en parle pas car pour comprendre cela, vous devez savoir ce qu' est un objet commit , un hachage, etc. Nous allons donc l' ignorer pour l'instant. Le fichier de conflit est quelque chose que nous aborderons dans la prochaine conférence. Le fichier de description a quelque chose à voir avec Git web. Et puisque tu ne connais pas le web, ça n'a pas de sens pour moi d'en parler. En ce moment. La tête a quelque chose à voir avec la ramification. Nous allons donc en parler. Quand nous avons parlé de succursales. Passons à autre chose. Une chose que je dois également mentionner est que l'accès est une opération sûre. Cela signifie que nous supposons que j'ai travaillé sur mon projet pendant un certain temps et que j'ai fait quelques commentaires, puis supposons accidentellement que j'ai relancé la commande, dans notre projet. Cela ne causera aucun dommage. Tout resterait tel quel, comme si nous n'avions pas du tout exécuté cette commande. Cependant, si vous supprimez ce dossier, cela posera problème. Vous allez perdre toutes les données historiques, l' historique des versions, etc. Ensuite, vous devrez soit réinitialiser le projet, mais exécuter la commande git init et recommencer à zéro. Vous pouvez également consulter le projet à partir du référentiel centralisé, que nous explorerons dans les prochains chapitres. Mais en règle générale, vous devez toujours vous rappeler de ne pas vous embêter avec ce dossier à moins de savoir ce que vous faites. Le fait qu'il soit masqué par défaut devrait vous indiquer qu'il n'est pas destiné à être utilisé par des développeurs comme vous et moi, mais à être utilisé seul. Cependant, dans certains cas, vous pouvez avoir besoin d' apporter des modifications ou de faire quelque chose dans ce dossier. Par exemple, nous avons déjà parlé du fichier info exclude, dans lequel vous pouvez ajouter des exclusions. Mais sinon, dans la plupart des cas, vous ne voulez pas vous embêter avec ce dossier. Il suffit de le laisser. 11. 0110 Configurer les identifiants de Git et explorer les configurations locales pour le système mondial: Bon, voyons comment nous pouvons configurer informations d'identification Git et essayer de comprendre son objectif réel. Nous avons maintenant un projet initialisé par get avec un ensemble de fichiers. Essayons maintenant d' exécuter la commande git commit et voyons ce qui se passe. Tu en auras 12. Merci de vous demander, s'il vous plaît, dites-moi qui vous êtes. Maintenant. L'eau demande des changements d'engagement locaux pour vous, mais qui diable êtes-vous ? Et il a également fourni des instructions sur la façon dont nous pouvons nous présenter à get is en exécutant cette commande. Mais il ne s'agit pas seulement de vous présenter pour obtenir objectif réel de configurer ces informations d'identification. Par exemple, supposons que l' un des membres de votre équipe reçu un défaut ou un bogue attribué à son nom, indiquant que ce n'est pas le cas, que la fonctionnalité ne fonctionne pas comme prévu. Dans le processus d' analyse du problème, ils veulent examiner tous les changements historiques de ce fichier. Et puis ils rencontrent un changement introduit plus tôt, qui semble avoir causé le problème ou semble avoir cassé une fonctionnalité. Devine quoi ? Ils vont connaître le nom de la personne et l'adresse e-mail de la personne qui a effectué ces modifications. Ils vont les contacter et leur demander de corriger le bogue. Mais comment ne pas. Tout cela, c'est lorsque vous configurez ces informations d'identification à l'intérieur, vous obtenez, lorsque vous effectuez un commit et que vous poussez toutes ces modifications vers le référentiel centralisé, qui sera GitHub. Il stockera également ces informations indiquant qui a effectué les modifications, y compris votre nom ainsi que votre adresse e-mail. Donc, si vous introduisez un bon code, quelqu'un reviendra et vous fera l'éloge. Sont. Si vous introduisez un mauvais code, quelqu'un reviendra vous blâmer. Dans la plupart des cas, c'est toujours la faute, mais sans commentaires à ce sujet. Voyons donc comment nous pouvons configurer les informations d'identification et get nous a déjà fourni comment le faire. Utilisons donc cette commande, git, config hyphen, hyphen global. Lorsque nous définissons cette option globale, cela signifie que ces informations d'identification sont disponibles pour tous les projets, tous les bons projets que vous créez dans votre système concernant cet utilisateur en particulier. Si vous avez dit ces deux systèmes, par exemple, alors ces informations d'identification seraient utiles à l'échelle du système. Cela signifie que tous les utilisateurs du système auront toutes ces informations d'identification applicables. Nous avons également une autre option qui dit local. Cela signifie que ces condamnés ne sont disponibles que pour le dépôt actuel sur lequel vous travaillez. Essayons d'abord avec le local. Je vais peut-être d' abord définir le nom. Vous pouvez définir le nom de votre choix, mais il doit s'agir de votre nom. Et je vais appuyer sur Entrée. Et je vais également définir le courrier électronique. Bon, maintenant regardons où ils sont réellement peuplés. C'est donc à l'intérieur du dossier. Rappelez-vous pas la conférence précédente, j'ai mentionné que nous allons parler de ce fichier de configuration. Eh bien, c'est là que toutes ces informations d'identification seraient définies. Essayons maintenant de définir ces informations d'identification au niveau global. Cette fois, il ne sera pas renseigné dans le répertoire Users de votre lecteur C. Laisse-moi remonter ça. Ainsi, dans le répertoire de l'utilisateur, vous devriez être en mesure de localiser la configuration Git. Et cela se refléterait là-bas. De même, si vous devez définir les identification à l'échelle du système, vous pouvez le faire. Je ne m'attends pas à ce que votre ordinateur soit utilisé par plusieurs personnes et elles contribuent toutes à votre travail. Mais de toute façon, configurons cela pour le système, même si vous avez besoin d'une autorisation. Cela ne lance donc pas get depuis le menu Démarrer en tant qu'administrateur. Ensuite, nous serons en mesure de définir les informations d'identification, obtenir la configuration. Je suis désolé, le nom d'utilisateur doit être modifié à l' échelle du système. Je vais dire que cela a marché et que cela se refléterait dans les fichiers du programme. Laisse-moi t'y emmener. Dans Program Files, récupérez le répertoire ETC. Vous allez voir le fichier de configuration Git. Et c'est là que les informations d'identification seraient renseignées. Au fait, je dois également mentionner que informations d'identification locales remplaceront les informations d'identification globales. informations d'identification globales remplaceront les informations d'identification au niveau du système Donc, nous allons essayer d'obtenir les informations d'identification locales rapidement. S'ils ne sont pas disponibles. Il essaiera de rechercher les informations d'identification globales. Sinon, la dernière option serait ces informations d'identification système. Si aucun de ces éléments n'est défini, vous verrez évidemment une erreur. Vous pouvez également consulter les informations d'identification en exécutant une commande git config list. Quelque part ici, vous allez voir le nom et l' adresse e-mail comme un téléphone portable. Vous pouvez également donner la possibilité de voir un niveau particulier d'informations d'identification, par exemple locales. Et vous pouvez également être plus précis sur les informations contenues dans Config. Vous voulez jeter un œil, allant jeter un œil au nom d'utilisateur par exemple. Et il va en imprimer la valeur. 12. 0111 Établir et désorganiser et vérifier le statut: Voyons comment nous pouvons mettre en scène fichiers instables dans le dépôt Git. Et comme je l'ai déjà mentionné, nous devons préparer les fichiers avant de les valider. Nous avons donc actuellement trois fichiers dans notre répertoire de travail. Prévoyons de les engager. Permettez-moi d'agrandir la fenêtre afin d'avoir une meilleure vue. Permettez-moi également de taper la commande clear pour effacer l'écran afin que nous obtenions une nouvelle vue. Je vais faire un ls pour lister tous les fichiers. Et nous avons actuellement trois dossiers. Si j'ai essayé de faire git commit, maintenant, ça va nous plaindre en disant que nous avons des fichiers non suivis à l'intérieur de notre projet. Nous avons besoin d'au moins un dossier. Tract va avoir au moins un fichier dans la zone de transit pour pouvoir valider. Et c'est ce qu'il se plaint. Maintenant, comment enregistrer ces fichiers ? Obtient la commande, Eh bien, bien nous a déjà donné un indice. Il est doué pour. Faisons donc git add. Et je pourrais simplement lister tous les fichiers que je voulais valider. Par exemple, un espace TXT point vers un point TXT, et ainsi de suite. Cela peut être utile si vous souhaitez sélectionner deux fichiers dans lesquels vous souhaitez qu'il entre dans le cadre d'une fonctionnalité particulière. Cependant, dans ce cas, j'aimerais tout engager. Je pourrais donc simplement utiliser un style de caractère générique. Je peux également utiliser un motif. Par exemple, je peux dire étoile point TXT, et cela mettrait en scène tous les fichiers avec un nom ayant l'extension point TXT. Nous allons donc exécuter cette commande. C'est ce dont nous avons besoin. Cela a donc maintenant mis en scène tous nos fichiers dans la zone de transit. Comment s'assurer qu'il a mis en scène tous nos fichiers ? Eh bien, il y a une commande pour vérifier le statut de git status. La commande Git status nous montrera une liste des fichiers non suivis, liste des fichiers qui sont suivis, des fichiers qui sont modifiés, etc. Cette commande sera utile pour vérifier l'état de notre projet au fur et à mesure que nous progressons dans ce cours Vous en saurez plus sur cette commande. Ainsi, après avoir exécuté cette commande, nos fichiers sont répertoriés sous modifications à valider. Et il a également changé la couleur de ces fichiers en vert, ce qui indique que ces fichiers sont maintenant suivis ou que ces fichiers se trouvent dans la zone de transit en ce moment. Ce qu'il dit dans le cas précédent où tous ces fichiers sont répertoriés sous fichiers non suivis et sont marqués en rouge. Maintenant, supposons que je veuille supprimer l'un de ces fichiers de la zone de transit, peut-être parce que je l'ai accidentellement ajouté ici. Comment faisons-nous cela ? Eh bien, Dieu nous a déjà donné un indice la commande que nous devons exécuter pour lancer sur scène un fichier qui obtient RM avec l' option tiret, trait d' union en cache. Chaque fois que je dis que les mises en cache sont indexées ou mises en scène, nous voulons tous dire la même chose. Gardez cela à l'esprit. Donc, mettez le trait d'union RM, le trait d'union mis en cache. Et je vais faire la liste des dossiers que je voulais voir sur scène. Si je veux mettre en scène tous les fichiers, je pourrais utiliser un caractère générique comme celui-ci. Et cela mettrait en scène tous les dossiers. Laisse-moi le faire. Cela a donc déchiffré tous nos fichiers pour s'assurer qu'il a tous nos fichiers sur scène. Utilisons la commande git status. Et comme vous pouvez le voir, retour à la section des fichiers non suivis et là encore marqué en rouge. Ajoutons-les à nouveau. Permettez-moi cette fois de créer sur scène un seul fichier, peut-être deux points TXT. Vous devez vous assurer que vous utilisez cette option mise en cache. Si vous n'utilisez pas cette option, cette commande aura une signification différente, dont nous parlerons dans les prochaines conférences. Cela a un TXT à deux points mis en scène. Faites-le nous savoir, vérifiez l'état d'avancement de notre projet. Et comme vous pouvez le voir, TXT à deux points est maintenant répertorié sous fichiers non suivis. Mais comme les deux autres fichiers sont répertoriés sous les modifications pour y arriver. Prenez donc un moment et essayez d'expérimenter ces commandes pour préparer fichiers instables et vérifier ces données simultanément. Ne validez pas encore les modifications. Nous en reparlerons lors de la prochaine conférence. Mais n'hésitez pas ou n'ayez pas peur d'expérimenter toutes ces commandes, vous pourriez avoir l'impression ces commentaires sont assez simples et directs à ce stade. Mais au fur et à mesure que nous progresserons dans ce cours et que j'introduirai de plus en plus de commandes git, vous commencerez à avoir l'impression qu' elles sont très déroutantes. La seule arme dont vous disposez pour éviter cet état d'esprit confus. Sa pratique, je ne peux pas souligner à quel point il est important de pratiquer toutes ces commandes, sinon vous allez bientôt vous embrouiller. Rendez-vous dans le prochain. 13. 0112 Comprendre Commis avec plusieurs usecases: Voyons comment nous pouvons valider nos modifications dans le dépôt Git. Au fait, quand je dis dépôt Git, je pourrais parler de notre dossier de projet avec le dossier git point. Ou je pourrais également parler du magasin de données d'objet dont nous avons parlé plus tôt. Cela dépend du contexte. Pour éviter la confusion, je vais appeler notre répertoire de travail sont notre dossier de projet en tant que dépôt Git. Je vais faire référence à la base de données d'objets sous le nom de base de données d'objets juste pour éviter toute confusion. Nous avons donc tous ces fichiers en place. Faisons en sorte que tous ces fichiers soient mis en scène. Je vais faire git status. Nous avons un dossier qui n'est pas mis en scène. Faisons git, ajoutons deux points TXT pour le mettre en scène. Faisons encore une fois git status. Et nous avons préparé tous nos dossiers. Je vais dire git commit hyphen m. Et ensuite nous allons fournir un message significatif. Pourquoi devons-nous transmettre ce message ? Eh bien, décrit essentiellement les changements que vous vous engagez à y apporter ultérieurement, si vous ou quelqu'un d'autre dans votre équipe, devez examiner tous les changements historiques ou les engagements historiques. Ils découvrent également quel comité en examinant son message. Par exemple, vous pouvez valider des modifications pour corriger un bogue ou ajouter une fonctionnalité. C'est une bonne pratique. Dans les applications en temps réel, nous suivons un format spécifique pour ce message. Le premier sera combinaison de caractères alphanumériques, qui est essentiellement un défaut ou un identifiant de fonction que vous choisissez dans votre outil de suivi des défauts. Si vous travaillez pour une organisation, vous disposez peut-être d'un outil de suivi des défauts ou des fonctionnalités. Vous choisissez cet identifiant et saisissez-le ici. Par exemple, il peut s' agir de quelque chose comme WI, de certains codes numériques. W signifie élément de travail. C'est peut-être autre chose pour toi. Ensuite, vous allez produire un message descriptif. Et même ce message, que nous choisirons le titre du défaut dans l'outil de suivi des défauts ? Je vais dire mon application de travail ou quoi que ce soit d'autre. Appuyons sur Entrée. Et tous les changements qui ont été mis en scène seraient désormais validés. Et afin de nous assurer que tous les fichiers sont validés, faisons git status. Et cela ne montre rien, ce qui signifie que nous n'avons aucun fichier pour devenir accro. Passons maintenant à une modification dans l'un des fichiers existants de notre répertoire de travail. Pour cela, je vais utiliser la commande echo juste pour remplir un fichier avec un texte. Mon texte dans le fichier un par exemple. Et je vais vider ce message dans un fichier txt point. Cette commande équivaut à ouvrir le fichier TXT à un point et à saisir le texte, mon texte dans le fichier un. Laissez-moi appuyer sur Entrée. Maintenant, je vais utiliser la commande cat pour voir ce qu'il y a à l'intérieur du geste TXT à un point. Je vous ai montré que nous avons ce message là-bas et qu'il imprime le texte dans OneNote dxdy. Tout va bien. C'est un changement que nous avons introduit, ce qui signifie que nous devons le mettre en scène afin de le valider. Faisons donc encore une fois git status. Cette fois-ci, nous allons dire que nous avons un fichier qui a été modifié. Nous devons donc faire git add pour ajouter ce fichier et l' amener dans la zone de transit. État de Git. Il devient vert, ce qui signifie qu'il est prêt à être validé. Je vais à nouveau utiliser la commande commit. Commettez les modifications. Supprimons l' identifiant du défaut pour le moment. Permettez-moi simplement de transmettre un message significatif. Fichier modifié, un, par exemple, appuyez sur Entrée, obtenez l'état. Et bien sûr, nous avons engagé nos changements. Considérons maintenant le cas de la suppression d'un fichier. Pour cela, je vais utiliser la commande RPM signifie remove. Ensuite, je vais spécifier le nom du fichier. Mettons-le au point txt, position différente. Maintenant, cette commande n'est pas spécifique à get, il s'agit d'une commande Unix typique. Appuyez sur Entrée. Je vais le faire pour voir s'il a été supprimé et effectivement supprimé. Il s'agit maintenant d'un nouveau changement qui est introduit dans le projet. Devine quoi ? Nous devons le mettre en scène, puis leur faire savoir que nous avons supprimé le fichier. Il est donc également reflété dans la base de données d'objets. Ainsi, git status va indiquer que le fichier a été supprimé, mais cette modification n'est pas mise en scène. Alors git add dot dxdy. Bon statut. Et nous avons des modifications qui sont prêtes à être éditées. Encore une fois, git commit avec un message significatif. Cette fois, laissez-moi ne pas entrer de message et appuyez sur Entrée pour voir ce qui se passe. Eh bien, cela ouvrirait l'éditeur de texte que nous avions choisi lors de l'installation de Git. Dans mon cas, il a Notepad Plus Plus pour vous, c'est peut-être autre chose. Ici, nous devons entrer le message que nous saisirions autrement avec option tiret m quand dire qu'il a supprimé le fichier. Pour enregistrer le fichier et simplement le fermer. Et elle a engagé nos changements. Nous utilisons la commande RM avec l'humeur, le fichier. Et puis nous avions fait git add command pour mettre en scène ces changements. Cependant, nous pouvons faire ces deux étapes dans un seul but en utilisant la commande get out from this time au lieu de simplement RM, je dis get RM. Cela supprimera non seulement le fichier, mais nous mettrons également en scène ces modifications dans la zone de transit. Supprimons trois points dx, dy par exemple. Je vais le faire. Et comme vous pouvez le voir, le fichier a été supprimé. Mais si je fais git status, contrairement à la commande RM, cette fois les modifications sont déjà scène et vous pouvez directement valider les modifications. Git commit, tirez-le. Suppression de trois fichiers. Jetons maintenant un coup d' œil à la liste des commits que nous avons effectués en exécutant la commande git log master. Master est le nom de la branche et est également la branche par défaut. Nous parlerons des succursales ultérieurement. Mais pour l'instant, lancez simplement cette commande à l'aveugle pour voir la liste de toutes les validations que vous avez effectuées. Le plus récent sera affiché en haut de la page. Comme tu peux le voir. Nous avons notre premier commit, mais mon message d'application de travail. Ensuite, nous avons modifié le fichier un, nous avons supprimé les fichiers à supprimer. Trois dossiers. Je peux également voir l'auteur qui l'a fait. C'est méchant dans ce cas pour toi. Il s'agit de tout ce que vous avez saisi lors de la configuration des informations d'identification. Lorsque nous avons un référentiel centralisé et une équipe travaille sur un projet, qu'une équipe travaille sur un projet, vous pouvez voir la liste complète des validations effectuées par plusieurs membres de l'équipe. Et si vous deviez repérer un commit qui cause des problèmes ou qui pourrait casser une fonctionnalité. Vous pouvez contacter l'auteur en lui écrivant un e-mail. 14. 0201 Sha1 algorithme de hachage: Oublions cela une seconde et essayons de comprendre ce qu'est l'algorithme de hachage Chavan. L'algorithme de hachage siobhan, ou parfois appelé fonction de hachage, prend n'importe quelle quantité arbitraire de données en entrée. Et cela va nous donner un hashCode de 40 caractères avec une sortie. La taille de l'entrée n'a pas d'importance. Elle peut être aussi petite qu'un octet, ou elle peut atteindre un Go ou même un To. Mais le résultat sera toujours un code de hachage de 40 caractères. Même si l'entrée n'est qu' un seul alphabet, vous verrez toujours un HashCode de 40 caractères en sortie. Voici quelques-unes des caractéristiques de la fonction de hachage. même entrée aboutirait au même HashCode, peu importe le nombre de fois que vous exécutez, elle peut fournir la même entrée qui aboutira exactement au même HashCode. Vous ne pouvez pas générer de données à partir d'un code de hachage donné Bien qu'il soit possible de convertir des données en code de hachage, ce n'est pas possible dans l'autre sens. Je veux dire, si je vous donne un HashCode, il ne peut pas générer de données à partir de celui-ci. Il est vraiment difficile de trouver une autre entrée qui aboutit au même hashCode, mais ce n'est pas impossible. Vous pourriez avoir une autre entrée qui pourrait aboutir exactement au même HashCode. Mais la probabilité de le trouver afin que vous n' ayez même pas à vous en soucier. Voici un autre cas d'utilisation où HashCode peut être utilisé chaque fois que nous utilisons les registres de votre site Web en saisissant le nom d'utilisateur, passe et d'autres détails. Au lieu de stocker le mot de passe et dessiner le format texte dans la base de données, nous allons stocker le code de hachage de ce mot de passe afin que l'utilisateur du terme suivant essaie de se connecter. Nous allons à nouveau exécuter l'algorithme de hachage sur le mot de passe qu'ils saisissent. Ensuite, nous allons voir si la sortie résultante correspond à celle de la base de données. S'ils correspondent tous les deux, l'utilisateur sera authentifié et l' accès lui sera accordé. L'avantage de stocker code de hachage au lieu de stocker le mot de passe brut au format textuel est que si un pirate pirate votre système, il a accès aux codes de hachage, mais pas aux mots de passe réels. Ils ne peuvent rien faire en utilisant le HashCode. Par exemple, ils ne peuvent pas se connecter en utilisant le HashCode pour le compte d'un utilisateur. Tous les algorithmes de hachage sont utilisés par mesure de sécurité. Vous pouvez utiliser un ensemble dans un but différent. Et c'est pour identifier de manière unique divers objets et obtenir. Et nous en reparlerons lors de la prochaine conférence. Essayons maintenant de générer du code de hachage à partir de Git Bash à l'aide des commandes git. La commande à exécuter est un bon objet de hachage, mais avant cela, utilisons la commande echo avec du texte. Je vais utiliser le caractère pipe, puis dire obtenir entrée standard de l'objet de hachage. En utilisant le caractère pipe, nous indiquons que la sortie de cette commande sera l' entrée de cette commande. Essentiellement, nous essayons d'obtenir le HashCode de ce texte particulier. Appuyons sur Entrée. Nous avons obtenu un HashCode pour ce texte. Et peu importe combien de fois j'exécute la même commande, nous verrons exactement le même HashCode. Mais si je fais ne serait-ce qu'une petite modification, le code de hachage résultant serait complètement différent de ce que nous venons de voir. Supposons, par exemple, que je viens d'ajouter un caractère et que j'appuie sur Entrée. Vous verrez que ces deux codes de hachage sont très différents. Vous allez en savoir plus sur HashCode, les conférences à venir. 15. 0202 Git Internals (tout sur la base de données d'objets) Partie 1: Afin de mieux expliquer comment gérer et stocker les données dans la base de données d'objets. J'ai supprimé tout ce qui se trouve dans notre projet. Donc, tout l'historique de nos commits, tous les changements que nous avions introduits ont disparu pour de bon. Ce que nous avons ici est essentiellement un tout nouveau répertoire. Et je vais maintenant lancer Git Bash ici et créer un tas de fichiers et de répertoires. Je souhaite créer quelques fichiers dans ce dossier. Je vais donc utiliser la commande touch one dot dx dy et dx dy. Cela a créé quelques fichiers. En plus de cela, je vais également introduire un sous-répertoire dans notre projet. Il donne la commande de créer un tout nouveau répertoire. C'est MKDIR signifie make directory. Je vais l'appeler « actifs ». Nous avons donc des actifs qui sont recréés. Allons à l'intérieur et créons également un tas de fichiers dedans. Je vais créer, je veux utiliser la commande touch one subdata dxdy, substance ou sous-répertoire, juste pour notre compréhension. Et deux fichiers TXT sous-points. Mettons également du contenu dans ce fichier. Revenons au répertoire parent, qui est le répertoire racine de notre projet. Je vais utiliser la commande echo. Fichier de nouvelle génération. Nous allons le remplir dans un fichier TXT à un point. De même, nous allons remplir du texte dans l' autre fichier, stool, dxdy. Un sous-répertoire va entrer dans un sous-point dx dy, qui se trouve dans le sous-répertoire assets. Voici donc la structure de notre répertoire. Nous avons le répertoire assets et quelques fichiers dans le répertoire racine du projet. Et des atouts internes qui sont vrais. Nous avons ces deux dossiers. Actuellement, ce dossier n' est pas initialisé. Alors faisons-le. Entrez dedans pour initialiser ce projet. Et git ajoute tous les fichiers. Git status pour voir le statut. Et comme vous pouvez le constater, tout est mis en scène. Nous allons maintenant valider les modifications. Commit Git. Premier commentaire. Cela devrait fonctionner. Dans la prochaine conférence, nous allons comprendre les différents types d' objets que nous avons dans Git et comment tous ces fichiers sont stockés dans la base de données d'objets get. Je te verrai dans le prochain. 16. 0202 Git Internals (tout sur la base de données d'objets) Partie 2: Parlons de la qualité du stockage des données dans la base de données d'objets. Lors de notre précédente conférence, nous avions créé un projet avec de nombreux fichiers et nous avons validé ces modifications. Voici la structure du projet que nous avions. Nous avons le dossier my app, qui est le répertoire racine du projet. À l'intérieur duquel nous avons un point vous amène au point TXT et également un sous-répertoire appelé assets. Dans le répertoire assets, nous avons un sous-point dx dy et dx dy. Voyons maintenant comment ces fichiers sont réellement stockés dans la base de données pour laquelle nous avons besoin de comprendre les différents types d'objets qui ont. Nous avons d'abord l'objet Blob pour chaque fichier unique que vous consultez. Un objet blob est créé dans la base de données. Chaque objet blob stockerait le contenu de son fichier correspondant. Par exemple, un objet Blob peut être créé pour un point dxdy avec tout son contenu. Chaque objet blob possède également un hachage unique. Et comme vous l'avez peut-être deviné, ce hachage serait généré l'aide de l'algorithme de hachage Siobhan. L'entrée de cet algorithme serait le contenu du fichier. Il n'utilise pas vraiment l' algorithme de Siobhan pour sécuriser l'application ou quelque chose comme ça. Il l'utilise pour créer un identifiant unique pour ses objets. Et le contenu stocké dans le blob ne sera pas dans un format lisible par l'homme. Il sera stocké dans un format compressé. Je pourrais donc le stocker, le gérer et le récupérer efficacement . Cependant, get propose également certaines commandes permettant de lire le contenu du blob. Nous allons explorer cela lors des prochaines conférences. Maintenant, comme il y a quatre fichiers que nous avions déjà validés, il y en aura pour les blobs créés dans la base de données avec le contenu correspondant de ces fichiers. Ensuite, nous avons trois objets. L'objet Tree correspond à chaque directeur du projet, y compris le répertoire racine du projet. Et tout comme pour l'objet Blob, l'objet arbre aura également un cache unique pour identifier de manière unique un objet arbre particulier. En plus de cela, il aura références qui maintiendront essentiellement les codes de hachage d' autres objets blob ou trois objets ou une combinaison des deux. Par exemple, nous avons quelques dossiers dans notre projet. Il s'agira donc de deux ou trois objets créés pour chacun de ces répertoires. Nous allons donc créer un objet arborescence pour le répertoire assets. Et à l'intérieur de cet objet il contiendra les références sont HashCode de ses fichiers. Dans ce cas, cet objet arborescente contiendra le hashCode OPT sub one dot TXT et subdued ou TXT. Ce sont essentiellement les hachages des gouttes qui correspondent à un point inférieur à un point T s'étend jusqu'au point TXT. Ensuite, nous allons créer un autre objet arborescence pour le répertoire parent du projet. Et il va avoir HashCode sur ses propres fichiers. En plus de cela, il contiendra également le HashCode de la sous-arborescence, qui correspond au répertoire assets. Et bien entendu, chacun de ces trois objets aurait son code de hachage unique pour les identifier de manière unique afin qu'ils puissent être référencés à partir d'autres objets. Ensuite, nous avons l'objet commit. Encore une fois, il aura son propre hachage unique. Et ce hachage sera généré fonction des informations de validation, comme le nom de l'auteur, adresse e-mail, le message qui a été saisi, l'heure à laquelle la validation a eu lieu, etc. en fonction des informations de validation, comme le nom de l'auteur, l'adresse e-mail, le message qui a été saisi, l'heure à laquelle la validation a eu lieu, etc. contient la référence ou le HashCode de l'arbre parent. En plus de cela, il contiendra également des informations sur le nom de l'auteur, adresse e-mail, le message qui a été saisi lors de la validation, etc. Et à l'exception du tout premier combat, le L'objet commit contiendra également une référence ou un hashCode du commentaire précédent. Vous en saurez la signification lors des prochaines conférences. Pour les changements que nous venions de nous engager. C'est ainsi qu'il stockerait les informations dans la base de données. Nous avons donc trois objets qui correspondent à chacun des réalisateurs du projet. Ensuite, nous avons également des objets Blob qui correspondent à chaque fichier du projet. Maintenant, ce n'est pas nécessairement que si vous avez dix fichiers créés dans votre projet, nous aurions dix blobs créés dans la base de données d'objets. Il n'est pas nécessaire qu'il en soit ainsi. Par exemple, si vous avez deux fichiers ayant exactement le même contenu, et qu'ils génèrent tous deux exactement le même HashCode, par exemple. Dans ce cas, get ne créera pas deux objets blob différents pour cela, il créera simplement un objet blob et s'y référera à la place. Bref, nous en parlerons dans les prochaines conférences. 17. 0204 Internals de Git Consulter et lire des objets de Git: Nous avons théoriquement compris à quel point il gère et stocke les données dans la base de données d'objets. Maintenant, jetons un coup d'œil pratique afin de mieux expliquer les choses. Je vais également vous montrer une représentation graphique de ce que nous faisons actuellement sur le côté droit de l'écran afin que vous ayez une meilleure idée de ce que nous faisons. Actuellement, nous n' avons qu'un seul commit. Jetons-y un œil. Je fais donc git log pour jeter un œil à toute la liste des commits. Actuellement, nous n'en avons qu'un. Et comme vous pouvez le voir, nous avons des informations sur l'auteur, date et même le message de validation. En plus de cela, nous avons également un code de hachage de 140 caractères. Peux-tu deviner en quoi consiste ce code de hachage ? Eh bien, voici le HashCode de l'objet commit correspondant à ce commit. Maintenant, comment examinons-nous le contenu de cet objet comète ? Eh bien, ce HashCode lui-même donnera un indice sur la façon dont nous pouvons accéder à cet objet commit. Laissez-moi vous montrer ce que je veux dire. Je suis dans le répertoire du projet. Laissez-moi vous l'agrandir. Je vais aller dans le dossier dot git. Et devinez dans quel dossier nous devons entrer. C'est le dossier des objets. Maintenant, nous avons un tas de dossiers qui n' existaient pas avant de valider les modifications. Maintenant, si vous regardez le HashCode et que vous retirez les deux premiers caractères, il indique 95. Nous devons aller dans ce dossier. Ensuite, vous voyez un fichier avec le nom, qui est essentiellement constitué des caractères restants du HashCode. Nous avons donc 95 ECE, ainsi de suite. 95 est le nom du répertoire et le reste des caractères est le nom du fichier. Et c'est ce que nous appelons l'objet commit. Si vous essayez de regarder le contenu à l'aide d'un Bloc-notes Plus, Plus, vous ne pourrez pas le lire car il sera stocké dans un format différent que nous ne pouvons pas lire. La seule façon de lire le contenu est d'exécuter la commande get kept file. Ensuite, vous allez fournir l'option tiret P signifie joli imprimé. Et vous allez fournir le HashCode de l'objet que vous voulez imprimer. Je pourrais copier l' intégralité du code de hachage, ou simplement copier les premiers caractères et les coller ici. Cela imprimerait Watson à l'intérieur de l'objet comète. Si vous souhaitez examiner le type de l'objet, l' option pour cela est le trait d' union d pour imprimer le texte. Et c'est arrivé à l'objet. Imprimons à nouveau cet objet. Donc, comme je l'ai mentionné précédemment, vous avez des informations sur l'ordinateur auteur et même le message de validation. En plus de cela, nous avons également un HashCode, qui est en fait le HashCode de l'objet arbre parent. Jetons donc un coup d'œil à ce qu'il y a à l'intérieur de l'objet arbre. Et je vais utiliser la même commande pour imprimer ce qui se trouve à l' intérieur de l'objet arbre. Je peux simplement copier les premiers caractères. Colle-le ici. Et si vous appuyez sur Entrée, vous verrez ce qu'il contient. Puisque nous devons revenir au répertoire racine, nous avons un sous-répertoire et deux fichiers. Et si vous regardez ce qu'il y a à l'intérieur de cet objet arbre, vous avez deux gouttes. Chaque blob correspond à un fichier individuel. Dans ce cas, il s'agit d'un point dx dy et dx dy. Et puis il pointe également vers un autre arbre, ou il a désactivé HashCode et un autre arbre ou le sous-arbre. Nous pouvons donc également aller dans le sous-arbre. Faisons ça. Obtient la sortie. Il s'agira des gouttes des deux fichiers du sous-dossier. Un sous-point prend en sous-point TXT. Au fait, vous pouvez localiser ces objets dans le dossier des objets. Tout comme vous avez localisé l'objet commit. Il n'en est pas autrement. Puisque je suis le dossier des objets. Vous y trouverez un dossier. C'est donc l' objet de sous-arbre dont nous parlions. De même, vous pouvez également trouver les objets blob. Par exemple, parlons de ce blob. Cela commence par 99, nous allons donc aller dans ce répertoire. Et il s'agit d'un objet Blob. Essayons d' imprimer joliment cet objet blob et nous devrions être en mesure de voir le contenu qu'il contient. Et encore une fois, si vous deviez l' ouvrir avec Notepad Plus, Plus ou quelque chose comme ça, vous ne pourriez pas le lire. Et vous voyez le texte qui se trouve dans ce fichier. C'est ainsi que nous obtenons essentiellement les données stockées dans la base de données d'objets. Et la compréhension de cela est très importante pour que vous puissiez comprendre comment les sujets que nous allons aborder et les chapitres à venir. 18. 0205 Comment Blob Objects se comportez-vous: Parlons des objets Blob et de la façon dont ils sont gérés dans le référentiel Git. Imaginez que j'ai créé un tout nouveau projet avec le fichier suivant, TXT à un point, et contenant le texte suivant. Bonjour de recevoir. Maintenant, au moment où j'ajouterai ce fichier à cette zone de transit, get essaiera de générer un code de hachage à partir du contenu d'un fichier TXT à un point. Et get vérifiera ensuite si nous avons déjà des objets dans la base de données d'objets qui correspondent à ce code de hachage. S'il n'y en a pas, alors il créera un objet Blob avec tout le contenu d'un fichier txt point, bien sûr, dans un format compressé. Supposons maintenant que j'ai créé un fichier de plus, disons deux points TXT, avec exactement le même texte que le TXT grossier à un point bonjour en obtenant, encore une fois, supposons que j'ai ajouté ce fichier au zone de transit. Obtenir la largeur. Encore une fois, essayez de générer un HashCode à partir du contenu d'un fichier TXT à deux points. Et cette fois-ci, nous remarquerons que nous avons déjà un objet qui correspond à ce HashCode. Par conséquent, get ne créera pas un autre objet blob. La raison en est évidente. Pourquoi voudrions-nous créer exactement le même objet blob alors que nous en avons déjà un ? Pourquoi n'utilisons-nous pas simplement celui qui existe déjà ? C'est logique, non ? Voyons maintenant tout cela en pratique. Pour le bien de cet exemple et éviter toute sorte de conclusion. J'ai créé un nouveau dossier avec le nom onglet Tests. Et c'est là que nous allons expérimenter et voir ce que les blobs peuvent faire pour nous. Alors laissez-moi lancer et me faire défoncer dans ce dossier. Tout d'abord, initialisons le projet. Et laissez-moi créer un fichier contenant du contenu. J'utilise la commande echo. Je vais vider ce message dans un fichier txt point. Cette commande ne créera pas seulement un module de fichier TXT point, mais le remplira également avec ce contenu Bonjour d'obtenir. Passons maintenant au répertoire des objets et voyons comment il se comporte. Permettez-moi d'énoncer ce fichier, un point txt, git ajouter un point dx dy. Et au moment où je fais cela, nous voyons un nouveau dossier se créer directement dans les objets. Devinez quel est ce dossier ? Eh bien, il s'agit de l'objet Blob pour le fichier TXT à un point que nous venons de créer. Donc oui, les blobs sont créés lorsque le nouveau stage du fichier ne l'est pas nécessairement lorsque vous validez les modifications. Lorsque vous validez les modifications, cela créera l'objet comète ainsi que les trois objets correspondant à un groupe de gouttes. En fait, c'est le but de l'opération de validation. Il s'agit de créer un instantané, enregistré le projet à ce moment précis. Nous allons parler de l' instantané lors de la prochaine conférence. Revenons en arrière. Voyons maintenant ce qui se passerait si je devais créer un autre fichier avec exactement le même contenu. En ce qui concerne ce TXT souvent point, je vais utiliser la même commande. Mais cette fois, je vais remplir le même message dans un fichier TXT point. Laissez-nous préparer ce dossier. Je vais faire git status. Et nous avons préparé ces deux fichiers. Mais si vous remarquez, aucun nouvel objet n' a été créé pour TXT à deux points. Je vous en ai déjà expliqué la raison. Puisque nous avons déjà un objet Blob avec exactement le même contenu, get n'entre pas dans la création d'un autre objet. En d'autres termes, au moment où nous avons ajouté l'extra sous la zone de mise en scène, essayez de générer le HashCode de ce contenu. Et il doit vérifier si nous avons des objets existants dans la base de données qui correspondent à ce HashCode. Pour TXT à deux points, nous avons un blob existant et n'a donc pas créé un autre bloc. Le même principe s' applique même si vous devez modifier un fichier. Par exemple, disons que je voulais modifier le texte à l'intérieur pour basculer dxdy du fichier vers, par exemple, nous allons remplacer le texte à l'intérieur du fichier point TXT. Laissez-nous préparer ce dossier. Maintenant, pouvez-vous deviner si nous allons voir un nouveau dossier être créé dans le dossier des objets, la réponse est oui, bien sûr. Nous avons créé un nouvel objet blob parce que ce contenu est unique et qu'il n'existe aucun objet blob pour cela. Créons également un autre fichier, un fichier TXT à trois points avec le même contenu que celui souvent point TXT. Et passons à l'escalier ce fichier git status. Et nous avons ces trois fichiers à valider. Un point dx dy et dx dy, ou ayant exactement le même contenu alors que la route dxdy a une texture différente. Maintenant, validons les modifications. Eh bien, ce ne sont pas des offres, mais peu importe. Appuyons sur Entrée. Et comme vous pouvez le voir, nous avons créé à la fois le commit et l'objet arbre, juste après les modifications. Regardons maintenant ce qui se trouve à l'intérieur de l'objet arbre. Je vais obtenir le journal pour obtenir le HashCode de l'objet commit. Élément B du fichier Git cat. Voyons ce qu'il y a à l'intérieur de cet objet arbre. Ainsi, un point dx, dy et trois points TXT doivent pointer vers le même objet blob. Si vous remarquez que les deux entrées TXT ou dxdy pointent vers le même objet blob. Alors que pour TXT à deux points, il s'agit d'un objet Blob différent. 19. 0206 Garbage Collection et Pack des fichiers: Maintenant, vous avez peut-être une question. Chaque fois que nous ajoutons un fichier ou que nous modifierons un fichier et que nous l' amenons dans la zone de transit, nous allons voir l'objet blob être créé dans la base de données d'objets. Et get ne les supprimera même pas. Même si vous deviez déstabiliser les fichiers de la zone de transit. Est-ce efficace ou est-ce que cela prend trop de place ? La réponse est que ce n'est pas totalement efficace, bien entendu. Mais bon a ce concept de garbage collection, qui se produit périodiquement ou lorsque vous exécutez certaines commandes, comme get pulled par exemple, nous allons parler de git pull, git push commandes, chapitres entrants, bien sûr. Mais il existe certaines commandes qui déclencheront également le nettoyage de la mémoire. Le concept de garbage collection est un peu similaire à celui de garbage collection dans d'autres langages de programmation. Par exemple, nous avons un nettoyage de mémoire dans le langage de programmation Java dans lequel tous les objets non référencés seraient détruits. Et comme dans le cas de Git. Ce n'est pas un outil efficace à 100%, mais il dispose également d'un mécanisme pour gérer efficacement les objets. En fait, nous pouvons exécuter le nettoyage de la mémoire manuellement. Allons chercher GC. Et si vous remarquez que les objets qui existaient auparavant n'existent plus. Cela veut-il dire que tout s'est bien passé ? La réponse est non. Nous avons toujours tout cela. Par exemple, si vous exécutez cette commande, nous allons toujours voir comment ces informations d' objet et vous pouvez même lire le contenu de ces objets blob. Comment est-ce possible ? Nous n'avons pas ces dossiers d'objets, mais nous avons quand même pu lire ces objets. Eh bien, c'est à l'intérieur de ce répertoire. Essentiellement, cette opération de récupération de mémoire a encore compressé tous ces objets en un seul fichier. Nous avons également idx, notre fichier d'index. Et cela indiquera quel objet se trouve dans quel fichier arrière. Actuellement, comme tous les projets sont très petits, nous n'avons qu'un seul fichier pack. Mais comme nous avons plus en plus de fichiers introduits dans un projet, vous allez voir de nouveaux fichiers de pack être introduits. Un indice apparaîtrait à ce moment-là. Mais de toute façon, ce n' est pas quelque chose dont nous devons vraiment nous inquiéter. Vous pouvez également vérifier Watson dans le fichier PAC. Permettez-moi de lancer Git Bash dans ce dossier. Et la commande à utiliser est get, verify back, tiret v. Et puis je vais spécifier le nom du fichier compressé, et cela imprimerait tous les objets qu'il contient. Je dois également mentionner que la technologie crée une dépendance. Si nous voulons tout apprendre. ciel est la limite à la profondeur à laquelle nous pouvons aller et comprendre chaque concept. Mais est-ce que ça vaut le coup ? Telle est la question. Tu n'as pas vraiment envie de tout apprendre. Ça n'en vaut tout simplement pas la peine. Parce que nous avons déjà beaucoup de choses à couvrir et n' est que le point de départ et votre parcours DevOps. Pour moi, en tant qu'instructeur, j'ai besoin de tout savoir et de faire des recherches sur tout. Quel bien a à offrir pour que je puisse filtrer ce qui est nécessaire et ce qui ne l'est pas pour vous. En fait, j'hésite même à parler de ces concepts, mais j'ai trouvé que la compréhension de cela est très importante pour comprendre tous les futurs concepts dont nous parlerons dans les chapitres à venir. Mais sinon, j' hésite à parler tous ces concepts qui ne jouent aucun rôle dans votre Gettier. Je peux le faire si je le veux. Je peux juste t'apprendre des choses juste pour prouver que j' ai des connaissances là-dessus. Mais ça n'a aucun sens pour toi ou pour moi. Mon travail est de vous faciliter la tâche, pas de la compliquer. Et je préférerais faire de mon mieux pour vous enseigner uniquement ce qui est absolument nécessaire à votre travail. Vous devez garder cela à l'esprit et ne pas essayer de tout apprendre. C'est l'une des plus grandes leçons que j'ai apprises au cours de ma carrière. J'ai juste essayé de tout apprendre. En fait, la technologie crée une forte dépendance. Plus vous explorez, plus vous voulez en savoir plus et cela n'en vaut pas la peine. C'est un peu comme un divertissement en soi, d'une façon étrange peut-être, mais c'est pour moi. Je dois m'occuper de cette douleur, pas toi. 20. 0207 Git Snapshot Ce que cela signifie de prendre un instantané: Essayons de comprendre ce qu'est un bon instantané. Auparavant, nous avions créé un projet dans lequel nous avions quelques fichiers dans le répertoire racine du projet. Et puis nous avons également un sous-répertoire dans lequel nous avons quelques fichiers supplémentaires. Si vous vous souvenez de nos précédentes conférences. C'était la structure de l'objet que nous avions lorsque nous avons effectué notre premier commit. Permettez-moi de simplifier ce diagramme pour qu'il soit plus compact. Supposons maintenant que j'ai introduit un autre fichier, c3 point dxdy avec le texte suivant hello from getting. Et je l'ai gardé dans le répertoire racine du projet, reste ce fichier. Ensuite, j'ai validé les modifications. Pouvez-vous maintenant visualiser la structure de l' objet ? Pour le deuxième engagement que nous faisons ? Vous imaginez quelque chose comme ça ? Nous avons donc créé un nouveau blob pour le fichier nouvellement introduit. En plus de cela, pensez-vous pouvoir créer des blobs pour chaque fichier du projet ? La réponse est, bien entendu, non. Au lieu de cela, git créera un blog pour le nouveau fichier. Et l'objet arborescence racine du nouveau commit contiendra le hachage de ce nouveau blob. Et pour tous les autres fichiers, puisqu'ils sont restés tels quels et qu'ils ne sont pas modifiés, git fera simplement référence à leurs blobs existants et à leurs trois objets. Essentiellement, le contenu de l'objet arbre et de la deuxième colonne serait exactement le même que le condenseur de l' objet arbre dans notre premier commit, sauf qu'il y aura une entrée supplémentaire pour le fichier nouvellement introduit. En plus de cela, l'objet commit contiendra également la différence ou le hashCode du commit précédent ou de son parent. Vous en saurez la signification dans les chapitres suivants. Quel est donc cet instantané ici ? Eh bien, chaque fois que vous effectuez un commit, vous prenez un instantané de l'état de l'index ou la zone de staging au moment où vous effectuez le commit. Il capture essentiellement à quoi ressemblait chaque fichier au moment où vous effectuez le commit. Si vous devez revenir dans temps à l'un des commits précédents, git aura la possibilité de restaurer tous les fichiers votre répertoire de travail tels qu'ils étaient lorsque vous avez fait le commentaire. Comment est-ce possible ? C'est à cause de l'instantané. Voyons maintenant tout cela en pratique. Je suis dans notre bon vieux dossier my app. Permettez-moi de créer un nouveau fichier. Nous avons donc trois points dx, dy avec du texte dedans. Git ajoute git commit. Deuxième commit. Enfin, nous faisons un deuxième commentaire. Passons maintenant à l'exploration du commit et de trois objets. Je vais faire git log pour jeter un œil à toute la liste des commits. Et au fait, en parlant du combat parent, lorsque nous exécutons cette commande git log, elle affiche les détails de notre récent commit. Et puis cet objet de commentaire a les détails de son commit parent, qui est celui-ci. Et donc git va continuer et afficher ses détails également. Pour ce commit cependant, étant donné que c'est le tout premier commit que nous avons fait, il n'y a pas de commit parent. Ainsi, cette commande cessera de s'exécuter. Quoi qu'il en soit, vous en saurez plus sur les commits parents et les prochains chapitres. Alors allons-y et explorons ce qu'il y a à l'envers. Commit récent. Get kept file, tiret P. Et comme vous pouvez le voir, nous avons le HashCode de l'objet racine de l'arbre. En plus de cela, nous avons également le HashCode du commit parent, qui est celui-ci. Et puis les informations sur l'auteur, etc. Voyons ce qu'il y a dans ce dossier. Voici donc le contenu de l'objet arbre. Comparons-le avec l'objet arbre de notre première connexion. Si vous remarquez, le HashCode de l'objet de sous-arborescence est exactement le même. code de hachage d'un point dx dy et dx dy sont exactement mêmes sauf pour le fichier three dot dx dy nouvellement introduit. C'est ce qui explique. 21. 0208 Voyage dans le temps avec Git: Voyons comment nous pouvons voyager dans le temps. Je veux dire, je vais te le prouver dans un moment. Supposons que vous descendiez la première fonctionnalité et que vous validez tous ces changements dans le cadre de votre tout premier commit. Et supposons que toutes ces modifications sont entrées dans un TXT à un point. Et puis votre client dit qu'il avait besoin d'une autre fonctionnalité dans son application. Donc vous voulez prendre et travailler dessus, faire un autre commit, et supposer que toutes ces modifications sont entrées dans le fichier TXT point. Une fois de plus, votre client propose une idée créative. Il avait besoin d'une fonctionnalité supplémentaire dans son application. Et encore une fois, vous travaillez sur cette fonctionnalité, faites un autre commit. Et puis supposons que vous avez introduit TXT à trois points où vous avez tous ces trois changements. Maintenant, disons que pour une raison quelconque, le client a décidé de ne pas avoir la fonctionnalité trois pour une raison quelconque. Et qu'il voulait revenir à la version précédente de cette application. Alors, comment annuler toutes les modifications apportées aux trois fonctionnalités ? Eh bien, dans cet exemple, c'est assez simple. Vous supprimez simplement le fichier TXT à trois points , puis vous effectuez un autre commit. Cependant, comme nous l'avons vu dans l'un de nos chapitres précédents, détournement des modifications n'est pas une tâche facile car dans les applications réelles, vous pouvez avoir des modifications éparpillées dans plusieurs fichiers. Et il est vraiment difficile d'annuler tous ces changements sans tout gâcher. Vous risquez de casser des fonctionnalités qui fonctionnent plus tôt. Heureusement, get serait en mesure de revenir à la copie de travail précédente de notre projet. Maintenant, je dois également mentionner que quelle que soit l'approche dont je vais parler pour passer à la version précédente du projet, ce n'est pas vraiment l'approche recommandée. L'approche recommandée est d'utiliser des branches, dont nous parlerons dans le chapitre suivant. Et dans le chapitre suivant, vous comprendrez également pourquoi ce n'est pas l'approche recommandée pour détourner vos modifications. Mais pour l'instant, regardons cela en action. 22. 0209 Voyage dans le temps en pratique: Voyons comment voyager dans le temps et prenons un exemple rapide. Et encore une fois, pour éviter toute confusion, je viens de tout nettoyer dans le dossier du bureau et nous allons tout faire à partir de zéro. Laissez-moi lancer et Git Bash. Mon plan est de faire trois validations. Et nous supposons que chaque commentaire correspondrait à des caractéristiques individuelles. Initialisez le projet. Touchez un point TXT, git add. Nous allons rester dans ce fichier, git commit. Et appelons-le comme il se doit. Nous allons également répéter le processus pour ajouter une fonctionnalité. Appelons-le TXT à deux points. Git ajoute deux points TXT et git commit. Fonctionnalité deux. Faisons un dernier commit représentant la troisième fonctionnalité. Et git commit en a présenté trois. Maintenant, faisons git log pour jeter un œil à toute la liste des objets. Permettez-moi d'agrandir ce dossier afin que nous puissions regarder simultanément ce qui se passe ici pendant que nous exécutons les commandes. Nous avons donc actuellement ces trois fichiers. Supposons maintenant que je voulais récompenser et revenir à l'une des versions précédentes du projet. Supposons que je voulais revenir en arrière quoi ressemblait mon projet. J'ai fait un long métrage pour venir. La commande que je dois utiliser est en fait switch. Maintenant, notez que cette commande peut ne pas fonctionner pour vous si des versions plus anciennes de Git sont installées. Donc, téléchargez et installez la dernière version de Git uniquement, puis cette commande fonctionnera. Si vous insistez toujours pour utiliser des versions antérieures de gaped, il existe une autre commande appelée git checkout. Tu dois taper ça. Et si vous avez installé la dernière version, comme dans mon cas, alors ces deux commandes fonctionneront sans problème. Cependant, je préfère utiliser switch. Ensuite, nous allons fournir le HashCode du combat auquel nous voulons nous consacrer. Permettez-moi de coller le code. Vous n'êtes pas obligé de coller le code en entier. Les premiers caractères suffiraient en fait. Maintenant, si j'appuie sur Entrée, nous allons obtenir un indice de get disant, si vous voulez détacher, dirigez-vous vers le commit, réessayez avec l'option detach. Eh bien, peu importe ce que nous faisons en ce moment, c' est l'État de la tête détachée. Vous allez le comprendre dans le chapitre suivant et qu' une branche est attendue. Mais ça s'est engagé. Comme je l'ai déjà dit, quoi que nous fassions actuellement, ce n'est pas vraiment l'approche recommandée. L'approche recommandée consiste en fait à utiliser des branches. Encore une fois, nous en reparlerons dans le chapitre suivant. C'est même ce que recommande Git. Il s'attend à ce que nous utilisions une branche et non une comète. Nous allons continuer en incluant l'option de détachement du trait d'union. Et si vous remarquez au moment où nous exécutons cette commande, vous ne voyez plus de fichier TXT à trois points. Et même si vous deviez jeter un œil à toute la liste des commits, en faisant git log. Il ne va imprimer que deux validations. Essentiellement. Nous venons de remonter le temps pour ramener au projet ce qu'il était quand ils ont créé feature to commit. C'est équivalent à, je n'ai fait aucun changement après avoir créé une fonctionnalité. Qu'est-ce que c'est cool ? Vous pouvez également aller dans le futur. Et je n'ai pas tort de le dire. Permettez-moi de trouver le HashCode de la troisième fonctionnalité. Cette fois-ci. Laissez-moi lancer git checkout et Strauss, puis je vais spécifier le hachage du troisième commit, notre commit d'arbre de fonctionnalités. Et regardez ce qui se passerait dans notre répertoire de travail. Eh bien, vous voyez trois fois , et nous sommes de retour vers le futur. Qu'est-ce que c'est cool ? J'aimerais qu'il y ait quelque chose comme ça dans nos vies. Je veux dire, je pourrais juste remonter le temps, arranger les choses, peut-être investir dans Bitcoin, et revenir vers le futur. Ce serait cool à quel point ? C'est seulement possible et obtenir, pour le moment. C'est fou, mais en même temps, peu effrayant pour être honnête, mais c'est le pouvoir du bien. Mais quoi qu'il en soit, essayez d' expérimenter cette fonctionnalité. Il suffit de jouer avec. Et ne vous préoccupez pas des terminologies comme head, branch, etc. Nous allons parler de tout cela dans le prochain chapitre. Une autre chose que je dois mentionner est que chaque fois que nous changeons ou vérifions un autre commit, Get a pu ramener le répertoire de travail à ce qu'il était lorsque nous avons fait ce commentaire. Et cela s'est produit très rapidement. La raison pour laquelle cela se produit si rapidement est dû au concept d'instantané dont nous avons parlé lors d'une de nos précédentes conférences. Dans d'autres systèmes de contrôle de version. L'histoire est en fait la différence entre les fichiers et leurs commits précédents. Et lorsque nous ajoutons l' outil pour ramener le projet à un certain état, il va en fait résumer toutes les différences pour recréer les fichiers tels qu' ils étaient lorsque nous avons fait le commit. Cependant, dans le cas de get, il s'agit de Snapshot. En gros, chaque objet commit pointe vers un snapshot ou l'objet racine de l'arborescence, qui contient toutes les informations de tous les fichiers résidant dans notre répertoire de travail et toutes ses objets blob correspondants. C'est donc relativement plus rapide. Oubliez de récupérer le contenu des objets Blob et presque instantanément ou rapidement chargez presque instantanément ou rapidement tous les fichiers dans le répertoire de travail. C'est le pouvoir de stocker un instantané par rapport au stockage des différences entre les jeux de pads comme nous l'avons vu dans l'une de nos précédentes conférences. C'est comme si vous jouiez à un jeu, vous faisiez des allers-retours entre plusieurs points de vente. est un peu similaire à ça. J'espère que c'est logique. 23. 0301 Vie sans succursales: Voyons comment existait sa vie avant les branches git. Et vous pouvez voir par cette image que cela doit être une expérience très frustrante. Imaginez que nous ayons Bob qui est un conseiller en placement et un expéditeur, qui est un pigiste. Bob se sépare pour créer une application pour lui. Et l'expéditeur a créé une application et Bob est très content du fonctionnement de l' application. Et maintenant, Bob a décidé d'ajouter quelques fonctionnalités supplémentaires à son application. Et l'expéditeur a accepté de travailler sur ces fonctionnalités. Supposons maintenant que l'expéditeur ait commencé à marcher sur la première fonctionnalité et qu'il ait validé toutes ces modifications et les ait montrées à Bob. Bob est très content fonctionnement de la fonctionnalité 1 . Et il a donné le signal vert pour continuer à travailler sur d'autres fonctionnalités. L"expéditeur a donc continué à travailler sur la fonctionnalité pour également. Et envoyé un e-mail à Bob pour lui demander de vérifier la fonctionnalité. Mais cette fois, Bob est très occupé avec ces clients. Il n'avait donc pas eu le temps de vérifier cette fonctionnalité. Cependant, certains d'entre eux ont décidé de continuer à travailler sur d'autres fonctionnalités car s'il continue d'attendre la réponse de Bob, il pourrait ne pas être en mesure de respecter la date limite du projet. Il a donc livré la fonctionnalité trois et la fonctionnalité pour également, et a envoyé un e-mail à Bob lui demandant de vérifier toutes ces fonctionnalités. Bob a vérifié toutes les fonctionnalités. Et pour une raison quelconque, Bob n'est pas satisfait de la fonctionnalité pour terminer qu'il a décidé d'éliminer complètement cette fonctionnalité de son application. Alors Cinder y a réfléchi un peu et il s'est rendu compte qu'il est vraiment difficile d'annuler tous ces changements. Parce que s'il essaie d' annuler tous ces changements, il pourrait finir par casser certaines fonctionnalités qui marchaient. Une autre chose que l'on pense faire est de revenir à l'une des versions précédentes du projet en exécutant la commande gets qui sont git checkout. Mais le problème avec cela est que Cinder ne se débarrassera pas seulement de la fonctionnalité des modifications, mais il se débarrassera également de la fonctionnalité trois et fonctionnalité pour les modifications qui fonctionnent correctement. Et Bob est très content de ces fonctionnalités. Ce n'est que la partie émergée de l' iceberg quant au type de problèmes auxquels nous pouvons être confrontés lorsque nous n'utilisons pas de branches. Par exemple, dans les applications réelles, il se peut que vous ne soyez pas la seule personne travailler sur l'application. Vous pouvez avoir la base de code et la liste des historiques de validation, décider d'un référentiel centralisé et plusieurs membres de l'équipe et peut-être de plusieurs équipes, qui contribueraient à ce projet. Chacun ferait ses propres commits, introduisant ses propres fonctionnalités. Désormais, nous ne pouvons pas risquer de revenir à l'une des versions précédentes et perdre tous les efforts de l'équipe. Un autre problème auquel vous pouvez être confronté sans branches est celui où vous souhaitez travailler simultanément sur plusieurs entités. Laissez-moi vous expliquer ce que je veux dire. Supposons que toutes ces fonctionnalités vous sont attribuées et que vous devez les terminer avant une date limite. Appelons-les feature F1, F2, F3 et F4. Bien qu'il ne soit pas recommandé d'effectuer plusieurs tâches en même temps, certaines situations d'utilisation peuvent vous obliger à travailler sur plusieurs choses simultanément. Supposons, par exemple, que vous avez commencé à travailler sur la fonction F et apporté quelques modifications relatives à F1 dans votre répertoire de travail. Ensuite, tu dois écrire un e-mail à quelqu'un. Et en fonction de la réponse, vous voudriez continuer avec la première fonctionnalité. Pendant que vous attendez la réponse. On ne s'attend pas à ce que vous regardiez YouTube ou autre chose. Votre patron s'attend à ce que vous vous occupiez d'une autre tâche. Peut-être commencer à travailler sur une fonctionnalité pour, par exemple, choisir la fonctionnalité deux et commencer à travailler dessus. Introduisez le code lié à la fonctionnalité deux. Et ensuite, supposons que vous dépendez de quelqu'un d'autre pour la fonctionnalité. Et tu dois attendre la réponse. Donc, vous vous occupez également de la troisième fonctionnalité. Pendant que vous gérez toutes ces fonctionnalités, attendez des réponses et que vous mettez à jour le code en conséquence. Votre patron vous demandera de vous envoyer une mise à jour sur la fonctionnalité. Nous vous dirons qu'il est en cours même si vous n'avez pas commencé à utiliser la fonctionnalité juste pour les garder heureux, vous pourriez lui dire que c'est en cours de réalisation. Vous êtes donc en quelque sorte obligé de commencer à travailler sur une fonctionnalité pour le moment. Et puis tout à coup, vous pouvez répondre pour le premier long métrage. Ou quelqu'un de votre équipe vous demande de proposer troisième fonctionnalité parce qu'il en dépend. J'espère que vous arrivez là où cela mène. Lorsque vous avez tous ces changements partiels de toutes les fonctionnalités de votre projet. Cela créerait beaucoup de désordre et beaucoup de frustration. Parlons d'un autre problème réaliste auquel vous pourriez être confronté si vous n'utilisez pas de branches. Imaginez que vous ayez un référentiel centralisé dans lequel tous les membres de l'équipe contribueraient à la base de code. Et voici cette nouvelle dame qui vient de rejoindre l'équipe. Elle n'avait aucune expérience en programmation. Elle vient de terminer ses études collégiales et de rejoindre l'organisation. Et on lui a assigné une fonctionnalité sur laquelle travailler. Pendant qu'elle travaille sur le long métrage, elle a eu l'impression qu'il y a trop de changements pour revenir. Elle a donc pensé à faire un commit partiel sur la base de code. Elle commet donc ces changements. Et évidemment, comme vous pouvez vous y attendre, ce n'est pas la chose idéale à faire. Mais elle est nouvelle dans l'équipe. Elle ne sait pas grand-chose. Elle est encore en train d'apprendre et elle s'est engagée partiellement. Et les autres membres de l'équipe commenceraient à prendre ces nouvelles modifications car ils ont besoin code le plus récent pour commencer à travailler sur leurs propres fonctionnalités en plus du code existant. Ils contribuent également au projet introduisant leur propre ensemble de modifications et en introduisant de nouvelles fonctionnalités ou des corrections de bogues. Maintenant, à cause de ce commit partiel fait par cette jeune femme, tous les futurs commits pourraient également être interrompus. Ou pire encore, cela pourrait en fait casser maturité des choses, fonctionner correctement plus tôt. Maintenant, il est compréhensible qu'elle soit nouvelle l'équipe et qu'elle est obligée de faire des erreurs, dans l'équipe et qu'elle est obligée de faire des erreurs, mais qu'elle a abrité tous les membres seniors l'équipe qui ont fait un travail équitable. Mais ils doivent être blâmés parce que leur code ne fonctionne pas comme prévu en raison des changements introduits par cette jeune femme. Ce n'est que la conséquence d'une erreur commise par un membre de l'équipe. Que diriez-vous de plusieurs membres de l'équipe qui introduisent toutes ces idées à moitié cuites dans la base de code principale ? Cela va bientôt devenir un cauchemar. Cela deviendra bientôt difficile à gérer, ne pas être en mesure de respecter les délais du projet, trop de problèmes à résoudre, etc. Je suppose donc que je dois maintenant en savoir plus sur les branches git. Absolument. Alors qu'est-ce que tu attends ? Chacun rencontre ces trucs endommagés. OK. Cylindre facile. C'est ça le plan. C'est pour ça que je suis là. Je suis là pour t'apprendre. Merci. Merci. Tu es le bienvenu. 24. 0302 Qu'est-ce que Git Branches: Ok, essayons de nous faire une idée de ce que notre git branche. Maintenant, je dois mentionner qu'avec cette vidéo seule, vous ne pourrez peut-être pas comprendre ou obtenir une image complète de ce que sont les branches git. Vous devez regarder toutes les autres conférences de ce chapitre afin d'avoir une image complète de ce que nos branches git, quel en est le but, pourquoi elles existaient et comment elles résolvent tous les problèmes nous en avions parlé plus tôt. Passons donc à autre chose et essayons d' obtenir en tant que personnel, ce que j'aurai des succursales. Les branches Git sont une fonctionnalité si importante dans Git que même le logo lui-même possède un symbole représentant les branches get. Vous pouvez donc comprendre l'importance de cette fonctionnalité dans git. Je voudrais maintenant te poser une question. Quelle est la première chose qui vous vient à l'esprit lorsque vous entendez le mot branche ? Tu imagines quelque chose comme ça ? Eh bien, tu n'as pas tort. Ici. Si vous observez que nous avons une branche principale, puis nous avons également des sous-branches qui proviennent de la branche principale. Et chacune de ces branches possède son propre ensemble de feuilles. Eh bien, c'est synonyme de ce que les branches peuvent également obtenir. Donc, vous pouvez avoir une branche master créée par get lorsque vous initialisez le projet et que vous effectuez votre premier commit. Nous n'avons pas besoin de créer manuellement cette porte, fait pour nous. Et tous les commentaires que nous avons faits jusqu' ici sont allés dans cette branche par défaut, branche master, même si nous n'en sommes pas conscients. Ensuite, nous pourrions également avoir des branches de fonctionnalité qui proviennent de la branche master. Tout comme nous avons une branche principale et des sous-branches dans une branche réelle, nous avons également des branches master et feature en bon état. Et tout comme chacune des branches aurait son propre ensemble de feuilles, même dans Git, nous avons des convects résidant dans chacune de ces branches. Et toutes ces branches évolueraient indépendamment. Par exemple, si vous effectuez un commit et que vous utilisez une branche, ces modifications ne seront disponibles dans aucune des autres branches. Comme pour les autres branches. Si vous créez un commentaire et une branche master, ces modifications ne seront pas disponibles dans les autres branches. Si vous voulez effectuer un commit dans une certaine branche, vous devez basculer vers cette branche et effectuer un commit dans cette branche. Et ces modifications validées ne seront pas disponibles dans les autres branches. Et lorsque vous passez à une branche, git fait en sorte que le répertoire de travail ressemble à ce qu'il était lorsque vous avez effectué le dernier commit dans cette branche particulière. terme, l'objectif de toutes ces branches de fonctionnalité serait dans la plupart des cas d'être fusionnées dans la branche master. Cela signifie que nous allons maintenant avoir toutes les modifications introduites dans ces branches de fonctionnalité à l'intérieur de la branche master. De toute évidence, cela n'a peut-être pas tout à fait de sens pour vous en ce moment. Décomposons-le et voyons comment ce projet a pu évoluer depuis le début. Ainsi, lorsque vous êtes initialement en tant que projet et que vous effectuez votre premier commit, vous avez une branche master créée par good. Supposons que vous ayez fait quelques commentaires. Ces commentaires iraient à l'intérieur de la branche master. Nous avons donc le premier commit qui n'a aucun parent. Ensuite, vous avez le second commit, qui a le premier commit comme commit parent. Supposons maintenant que vous êtes chargé de travailler sur la première fonctionnalité. Au lieu de valider toutes ces fonctionnalités on change à l'intérieur de la branche master. Ce que vous allez faire, c'est exécuter une commande pour créer une branche de fonctionnalité. Et cela créerait simplement la branche feature. Et une fois que vous avez fait cela, vous devez basculer vers cette branche pour pouvoir effectuer des validations dans cette branche de fonctionnalité. Vous devez donc exécuter une commande pour basculer vers cette branche. Et une fois que vous aurez fait cela, vous allez commencer à introduire toutes les fonctionnalités que vous avez modifiées. Quand tu feras le premier commentaire. Nous avons un objet de commentaire dont les parents seraient le dernier commit de la branche à partir de laquelle vous avez créé cette branche. Dans ce cas, il s'agit de la branche master. Ainsi, le premier commentaire que vous avez fait dans la branche feature one pointe maintenant vers le dernier commit de la branche master. Supposons ensuite que vous ayez fait quelques commentaires à l'intérieur de la branche feature. Aucune des modifications que nous avons introduites dans la branche feature 1 ne serait disponible dans la branche master. Parce que comme je l' ai déjà dit, toutes ces branches évolueraient indépendamment les unes des autres. Supposons maintenant que vous avez décidé travailler sur autre chose et que vous souhaitiez apporter tous ces changements dans la branche master. Vous devez donc à nouveau passer à la branche master et faire un commentaire. Notez que ces deux commits ou le fait d' avoir exactement le même parent et quels que soient les changements que vous avez introduits avec ce nouveau commit dans la branche master ne seront pas disponible dans la branche Feature. branche Feature One ne comporterait que toutes les modifications introduites dans branche master jusqu'au moment où vous créiez la fonctionnalité sur la branche et que vous effectuiez le premier commit. Plus tous les changements que vous avez introduits dans la fonctionnalité 1. Supposons que vous ayez encore fait un commentaire à l'intérieur de la branche master. Et c'est à ce moment-là que l'on vous demande de travailler sur une fonctionnalité pour deviner ce que vous allez créer encore une autre branche, appelons-la fonctionnalité à branche. Ensuite, vous devez basculer vers cette branche pour pouvoir effectuer des validations dans la fonctionnalité vers la branche, vous allez faire un commit. Et cette fois, il serait piégé à l'intérieur d'une entité à l'autre. Et cet objet commit pointe vers le dernier commit de la branche master, car c'est la branche master à partir de laquelle nous avons créé cette fonctionnalité vers la branche. Et toutes les validations suivantes que vous allez effectuer seront suivies d' une entité à l'autre. Maintenant, encore une fois, vous voudrez peut-être revenir à la branche master et faire un tas de commentaires et non la fonctionnalité de dimension à la branche aura des modifications que vous avez introduites dans branche master jusqu'à l'heure à laquelle vous avez créé la fonctionnalité vers la branche et effectué le premier commit. Et tous les commentaires que vous avez introduits dans feature to branch, mais ne comportent aucun des changements que vous avez introduits dans les autres branches. Comme par exemple, une seule branche. Enfin, vous souhaiterez fusionner toutes les modifications que vous avez introduites dans ces branches de fonctionnalité dans la branche master afin de disposer toutes les modifications dans la branche master. De toute évidence, vous vous posez peut-être de nombreuses questions sur la façon dont cela résoudrait tous les problèmes dont nous avons parlé plus tôt. Et qu'est-ce qu'une branche exactement ? Comment fonctionne-t-il en interne ? Et comment est géré ce que cela signifie lorsque vous passez à une autre branche, vous, et de trouver des réponses à toutes ces questions dans les prochaines conférences. Et au fait, j'ai mentionné que nous effectuons des commits dans la branche master. En général, nous n'avons pas tendance à effectuer des validations directement dans la branche master. Nous créons toujours une nouvelle branche, fonctionnalité bêta ou une correction de bogue. Et une fois que nous serons sûrs de toutes les modifications, une fois que nous les aurons testées, les ferons réviser, ce n'est qu'alors que nous fusionnerons toutes ces modifications dans la branche master. Donc, essentiellement, la branche master aurait ce qu'on appelle un commit de fusion. Nous parlerons des commits de fusion dans les prochaines conférences. Je ne veux pas en parler maintenant et vous embrouiller davantage. Je te verrai dans le prochain. 25. 0303 Comment les succursales ont résolu nos problèmes: Ok, jusqu'à présent, nous avons une idée des branches. Voyons maintenant comment les branches résolvent les problèmes dont nous avons parlé plus tôt. Parlons-en un par un. Imaginez qu'on vous demande de travailler simultanément sur plusieurs fonctionnalités. Cette fois, vous allez avoir plusieurs branches, chacune correspondant à une entité individuelle. Il est très facile pour vous d'effectuer plusieurs tâches à car supposons que vous vouliez travailler sur la première fonctionnalité. Il vous suffit de basculer vers cette branche et de continuer à travailler sur la fonctionnalité 1. Quelque part au milieu de votre travail, vous avez peut-être décidé de travailler sur une autre fonctionnalité, exemple parce que vous attendez une réponse par e-mail ou quoi que ce soit d'autre. Alors devine quoi ? Il est allé passer à une fonctionnalité vers une branche et a continué à travailler sur la fonctionnalité deux. Et puisque les changements de pelage introduits dans une branche n'auront aucun impact sur les autres branches. Il n'y a aucune chance que vous vous confondiez avec les changements de code introduits pour plusieurs fonctionnalités. Nous avons un contexte distinct pour chaque fonctionnalité. Et ils évoluent indépendamment les uns des autres. Les branches ont donc en quelque sorte résolu le problème de ne pas pouvoir effectuer plusieurs tâches simultanément entre plusieurs entités. Supposons maintenant qu' un programmeur inexpérimenté ait rejoint l'équipe. Devine quoi ? Ils peuvent simplement créer une branche, expérimenter. Tout ce qu'ils voulaient expérimenter, faire des erreurs, apprendre de ces erreurs et apporter des mises à jour. Enfin, quand ils seront prêts avec les changements. Et une fois que tous ces changements ont été testés, membres seniors de l'équipe peuvent réellement examiner tous les changements de code. Et ce n'est qu'alors qu'ils accepteront que tous ces changements soient fusionnés avec le courant dominant du développement. Il n'est donc pas possible qu'un membre de l'équipe joue avec le code et coûte également le travail des autres. Supposons maintenant que vous vouliez vous débarrasser de l'une des fonctionnalités, alors vous n'avez pas à prendre leur avantage pour annuler tous les changements et risquer de créer des problèmes. Ou vous n'avez pas à revenir à l'un des commits précédents et risquez de perdre tous les efforts de l'équipe qui ont suivi. Au lieu de cela, vous pouvez simplement supprimer la branche et la créer. La fonctionnalité dont vous ne voulez pas. Cela n'aura aucun impact ou influence sur le travail des autres. Un autre avantage des branches est que vous pouvez effectuer des validations partielles. Sans les branches dans lesquelles nous avons effectué des validations partielles, vous risquez d' introduire de nouveaux bogues dans votre application qui cassent votre application qui cassent certaines fonctionnalités fonctionnelles. Cependant, avec les branches, vous pouvez effectuer plusieurs validations partielles, surtout si votre fonctionnalité est très importante. Et une fois que vous avez terminé, vous allez simplement fusionner toutes ces modifications sur la branche master. J'espère que c'est logique. 26. 0304 Comment fonctionnent Git Branches et ce qu'est exacte, une succursale: Essayons de comprendre comment les branches fonctionneraient. Mais avant cela, voyons ce qu'est exactement une branche. Si je devais définir une branche, une branche serait simplement une référence à un commit, ou en d'autres termes, est juste un pointeur vers un commit spécifique. Vous vous demandez peut-être comment une chose aussi simple peut faire autant pour nous ? C'est le cas. Laissez-moi vous expliquer ce que je veux dire. Mettons-en place ça. Il suffit d'initialiser le projet à l'aide de la commande git init. Et puisque branch est une référence à un commit particulier, nous avons besoin d'au moins un commit pour avoir une branche. C'est pourquoi tu ne vois rien en ce moment. Une branche serait créée la première fois que nous effectuons un commit. Et cette branche est la branche master, qui serait créée par Git lui-même. Nous n'avons pas à le faire manuellement. Vous pouvez le voir simplement comme un fichier avec le nom Master, dont le contenu sera le HashCode d'un commit spécifique. Et une branche pointe toujours vers le dernier commit de cette branche. Actuellement, nous n'avons qu' un seul commit. Cette branche master pointe vers ce commit. Supposons que j'ai fait un nouveau commit, puis que la branche pointe vers ce nouveau commit, et ainsi de suite. Et faites un nouveau commit et la branche pointera vers ce nouveau commit. Disons maintenant que je dois marcher sur le premier long métrage. Nous allons exécuter une commande pour créer une autre branche. Appelons-le «  feature one branch ». Au moment où vous exécuterez cette commande, git créera une nouvelle branche, essentiellement un nouveau fichier avec le nom feature one, dont le contenu serait le hashCode d'un commit spécifique. Qu'est-ce que ce serait ? Peux-tu deviner ? Eh bien, ce serait le dernier commit de la branche à partir de laquelle nous avons créé la branche feature one. Cela indiquerait donc ce commit. Supposons maintenant que j'ai effectué quelques validations supplémentaires. Où pensez-vous que ces commentaires iraient Mel ? Il irait dans master car il s'agit de la branche active actuelle. Ces deux commentaires iraient donc à l'intérieur de la branche master. Et comme vous pouvez le deviner, master pointe maintenant vers ce commit très récent dans cette branche particulière. Supposons maintenant que vous souhaitiez faire quelques commentaires à l'intérieur de la branche feature. Eh bien, vous devez exécuter une commande pour passer à cette branche. Et une fois que vous aurez fait cela, tous les commits que vous allez effectuer seront suivis dans la branche feature one. Si je fais un commit maintenant, quoi ressemblerait le diagramme selon vous ? Eh bien, une branche indiquerait toujours le dernier commentaire sur cette branche. Fonctionnalité. Une branche pointe désormais vers ce nouveau commit. Et ce nouveau commit aura le commit de la branche master comme parent. C'est donc à ce moment que nous aurons deux commits ayant exactement le même parent. Disons maintenant que j'ai fait quelques commentaires supplémentaires. Où pensez-vous que ces commentaires seraient suivis ? Eh bien, puisque la branche feature one est l'acteur actuel Branch, ces commentaires iraient à l' intérieur de la branche feature one. Et bien sûr, la branche feature one pointe désormais vers le dernier commit sur cette branche. Maintenant, ma question, imaginez que j'ai ajouté un fichier dans chacun de ces commentaires. Maintenant, si je regardais le répertoire de travail, quels sont tous les fichiers que vous allez voir ? Tu peux deviner ? Eh bien, chaque fois que vous passez à une branche, git réécrit le répertoire de travail pour qu'il ressemble à ce qu'il était lorsque vous avez effectué le dernier commit sur cette branche que vous venez de basculer. Ainsi, dans ce cas, les branches d'acteurs actuelles comportent un lot. Vous allez donc voir tous ces fichiers A, B, C et F, G, H. Vous n'allez pas voir les fichiers D et E. Et maintenant, si vous deviez passer à la branche master, vous allez voir les fichiers a, B, C, D, E , mais pas F, G, H Files. J'espère que c'est logique. Je te vois dans le prochain. 27. 0305 succursales en action (Créer des succursales et explorer le git repo): Bon, voyons les branches en action avec un exemple rapide. Encore une fois, je vais créer un nouveau dossier, mon application, et c'est là que nous allons expérimenter tout ce qui concerne les branches. Je vais lancer Git Bash ici. Permettez-moi de créer un fichier validé sur la branche master. Et nous allons commencer par là. Je vais initialiser le projet. Puis touchez un point TXT pour créer ce fichier. Git ajoute un point TXT pour rester dans ce fichier. Et avant de valider les modifications, laissez-moi vous emmener dans le répertoire refs, heads. C'est là qu'il créerait une liste de branches souvent. Permettez-moi de revenir à Git Bash et de commenter ce changement. Git commit tiret m. Premier commit dans la branche master. Au moment où je vais valider ces modifications, vous allez voir un nouveau fichier créé par gaped. Regardons ce qu'il y a dans ce dossier. Pour prendre note du nom du fichier, c'est le nom de la branche, la branche par défaut que Dieu a créée pour nous. C'est Master. Et le HashCode est le HashCode du commit que nous venons de faire. Si je reviens à Git Bash et que je fais git log, le HashCode que vous voyez ici est exactement le HashCode que vous voyez dans le fichier maître. Donc, pour l'essentiel, le maître de branche pointe cette comète en particulier en ce moment. Faisons encore un commentaire et voyons ce qui va se passer. Appuyez sur le fichier TXT à deux points, git, ajoutez deux points TXT. Et puis, encore une fois , engageons le changement. Appelons-le second commit et branche master. Et regardons le contenu du fichier maître. Donc, cat dot obtient les têtes de référence, puis le fichier master. Et comme vous pouvez le voir, Master pointe maintenant vers le dernier commit de cette branche actuelle. Donc, si je fais git log, vous verrez que la branche master pointe en fait vers le tout récent commit que nous avons fait. Essayons maintenant de créer une nouvelle branche. Et la commande pour cela est git branch. Ensuite, vous allez spécifier le nom de la branche que vous souhaitez créer. Appelons ça la fonctionnalité un. Cela a donc créé une branche feature one, mais nous sommes toujours sur la branche master. Et vous pouvez le voir en regardant ici, il est écrit Master, donc nous sommes actuellement dans la branche master. Si je fais un commit maintenant, il ne sera pas disponible. Dispose d'une branche. Mais si vous remarquez, il a également créé un autre fichier dans le répertoire heads avec le nom feature one et y récupère le contenu. Eh bien, ce sera le hashCode de la dernière branche commit off à partir de laquelle nous avons créé la branche feature one. Donc, en gros, si vous regardez le contenu du fichier feature 1, il va pointer vers le dernier commit de la branche master. Comme prévu. Maintenant, si je fais un nouveau commit dans lequel vous pensez que les modifications iraient, ce serait à l'intérieur de la branche master parce que c'est la branche act to branch actuelle. Alors laisse-moi m'engager. Dutch trois points dxdy, git ajoute trois points dxdy. Et nous allons faire un troisième commit dans la branche master. Si je le fais, tu vas voir ces trois fichiers. Mais si je passe à une branche, j'obtiens switch et le nom de la branche vers laquelle je veux passer. Fonctionnalité 1. Vous pouvez également utiliser la commande git checkout et le nom de la branche immédiatement. Comme vous pouvez le constater, nous avons opté pour une seule branche. Vous pouvez également le dire en regardant ici. Maintenant, pouvez-vous deviner ce que tous les fichiers verront si je le fais ? Eh bien, nous ne devrions pouvoir voir un seul point dx dy et dx dy. Et pas libéré dxdy parce que le texte à trois points est créé et la branche master, après avoir créé cette branche de fonctionnalité. Comme vous pouvez le voir, nous ne voyons qu'un seul point d x dans fichiers Rho TXT, ce qui est normal. Maintenant que nous sommes dans la branche feature one, tous les commentaires que je vais faire maintenant seraient piégés dans la branche feature one. Faisons un commentaire. Je veux créer un fichier, touchez. Appelons-le, qui sont noms de fichiers TXT à 13 points comme ceci, juste pour que nous sachions qu' il appartient à une branche. Pour le moment. Git ajoute. Nous allons rester dans ce fichier, git commit m, ajoutant un fichier feature 13 dans lequel une branche, peu importe. Donc nous avons fait le commentaire si je le fais maintenant, vous voulez voir tous ces fichiers. Laisse-moi y retourner. Le répertoire de travail. Vous allez voir tous ces fichiers. Eh bien, voyons ce qui se passerait si je devais passer à la branche master. J'utilise donc la commande gets which. Ou je pourrais aussi utiliser git checkout puis le nom de la branche. Au moment où je le fais, vous pouvez voir qu'il a mis à jour le répertoire de travail qui convient à la branche master. Prenez donc connaissance de l'instantané de la dernière branche master de commit diamond. Et cela va faire en sorte que le répertoire de travail ressemble à ce qu'il était lorsque nous avons fait le dernier commit dans la branche master. Et si je devais revenir à la branche des fonctionnalités, encore une fois, vous verrez le répertoire de travail être mis à jour en conséquence. On ne voit pas trois points, Dxdy. Et la branche feature pointe désormais vers le dernier commit effectué dans cette branche. Donc, si vous regardez le contenu de la branche feature one, le HashCode est maintenant mis à jour, pointant vers le dernier commit dans une future branche. Si vous utilisez git log, vous verrez que c'est le dernier commit effectué dans cette branche. Maintenant, il est vraiment essentiel que vous compreniez comment cela fonctionne exactement. Je veux que tu expérimentes ça. Créez des fichiers sur plusieurs branches, basculez entre plusieurs branches et essayez comprendre le bon comportement avec les branches. Si vous ne pratiquez pas, il est presque certain que vous vous embrouillerez bientôt. N'hésitez donc pas à vous entraîner. Vous avez l'impression de tout savoir, mais lorsque vous vous entraînez, vous pourriez avoir des surprises. N'hésitez donc pas à l'expérimenter. Prenez le temps de mettre en pratique ce que je viens enseigner et assurez-vous aise avec les branches. 28. 0306 Comprendre le chef de l'État détaché 'HEAD' en action: Comprenons ce qui nous attend et obtenons. Ma branche est une référence à un commit, lié à la tête au point d'une branche ou à un commit spécifique. Lorsque l'en-tête pointe vers un commit spécifique, on parle d'état de tête détaché. Laissez-moi vous expliquer ce que je veux dire. Lorsque vous avez un projet sans autre branche que la branche master, par défaut, head pointe vers la branche master. Supposons maintenant que vous avez deux branches, master et feature une branche. Supposons que vous ayez opté pour une seule branche. La tête indiquerait maintenant une branche. Et en fonction de la tête, get saura dans quelle branche il doit valider les modifications. Si la tête pointe vers la branche master, git fera les commentaires à l'intérieur de la branche master, ou la tête pointe vers autre branche comme feature one branch. Git effectuera des validations à l'intérieur de la branche feature one. Vous pouvez également avoir la tête pointant vers un commit spécifique. Et nous avions déjà examiné un exemple similaire dans l' une de nos conférences précédentes. Par exemple, vous pouvez dire git checkout ou good switch. Ensuite, vous allez spécifier le HashCode d'un commit particulier pour les objets. La tête pointe alors vers ce commit particulier et get met à jour le répertoire de travail du projet pour qu'il ressemble à ce que vous avez fait lorsque vous avez effectué ce commit particulier. Et quels sont les commentaires que vous faites pendant l'état de la tête détachée ? Tous ces commentaires seraient perdus une fois que vous reveniez à l'une des branches. Vous vous demandez peut-être pourquoi nous autorisons à passer à la caisse ou à passer à un commit particulier. Eh bien, dans certains cas d'utilisation, vous souhaiterez peut-être revenir à l'état précédent du projet. Par exemple, supposons que vous aimeriez voir à quoi ressemble notre projet lorsque vous avez effectué un commit particulier sur Supposons que vous souhaitiez récupérer certaines des modifications que vous aimeriez voir à quoi ressemble notre projet lorsque vous avez effectué un commit particulier sur. Supposons que vous souhaitiez récupérer certaines des modifications ont été supprimés plus tôt dans l' un des commentaires précédents. Eh bien, vous pouvez vérifier le commit en particulier. Vous jetez un œil à toutes les modifications, vous pouvez copier le code qui a été supprimé et utiliser ce code dans votre projet actuel. Une fois que vous êtes revenu à la branche ou un autre cas d'utilisation de l'état de tête détaché, supposons que vous vouliez remonter temps et faire quelques validations expérimentales. Mais vous ne voulez pas que tous ces commits soient disponibles dans votre base de code. Et une fois que vous avez terminé, vous devez simplement revenir à l'une des branches et tous ces commits expérimentaux seraient perdus. Voyons maintenant tout cela en action. D'accord, nous sommes actuellement dans la branche Feature One. Essayons tout d'abord de localiser l'endroit où réside réellement la tête. À l'intérieur du dossier git. Vous allez trouver ce fichier avec le nom « head ». Puisque nous sommes maintenant dans la branche feature one, head pointe vers l' entité une branche. Voyons ce qui va se passer. Si nous passons à la branche master. Jetons un coup d' œil au contenu du fichier d'en-tête point get. Et comme vous pouvez le voir, head pointe maintenant vers la branche master. Jetons maintenant un coup d' œil à la liste des commits de cette branche master, git log. Et comme vous pouvez le voir, nous avons actuellement trois commits. Et vous pouvez également voir ici que la tête pointe vers la branche master. Si vous deviez passer à une branche, disons. Et faites git log par exemple. Vous allez voir que la tête pointe vers une branche. Si vous souhaitez jeter un œil à toute la liste des branches disponibles, il s'agit de git branch. Ensuite, vous allez voir la liste de toutes les succursales. Et puisque la branche actuelle ou la branche ACT vers branche ou dite branche principale est une branche caractéristique, elle est surlignée en vert. Nous voyons également une étoile qui nous indique qu'il s'agit de la branche actuelle ou de la branche actuelle. Donc, si je fais git log, vous pouvez voir que nous avons actuellement trois commits. Nous avons déjà examiné comment consulter ou passer à l'un des commentaires précédents dans l'une de nos conférences précédentes. Donc je ne vais pas faire ça. J'utiliserais plutôt une commande différente appelée Git checkout. Ou vous pouvez également utiliser un bon interrupteur. Utilisons-le parce que c'est le dernier en date. Et puis tu vas dire « tête en majuscules ». Ensuite, vous allez utiliser ce symbole, quel qu'il soit. Ensuite, vous allez spécifier le nombre de validations auxquelles vous souhaitez revenir. que si j'en dis un ici, alors nous pouvons voir le dépôt ou le répertoire de travail, quoi cela ressemblait il y a un commit. Laissez-moi exécuter cette commande. Et cette fois, si je fais git log, accord, cette commande ne fonctionnait pas. Il nous demande d'ajouter cette option détacher. Alors faisons-le rapidement. Maintenant, faisons git log. Et vous n'allez voir que quelques commentaires. Actuellement, nous sommes dans un état de tête détaché. Permettez-moi donc de faire un commentaire ici. Touchez peut-être Apple point dx, dy. Et puis git, ajoutez Apple Dot TXT. Allez, mettez-les en trait d'union. Un certain message. Ça n'a pas d'importance. Si je fais git log. Vous verrez certainement cet engagement. Mais une fois que je reviendrai à l'une des branches, vous ne verrez plus ce commit. Ce commit serait perdu. Je vais donc faire git checkout. Ou vous pouvez aussi dire, la première fonctionnalité de Good Switch, git log. Et vous ne verrez plus le commentaire que nous venons de faire. 29. 0307 Annuler les modifications avec Git Reset HEAD: Bon, voyons comment annuler nos modifications ou inverser les commentaires que nous avons faits. Pour vous faire gagner du temps. J'ai créé un tout nouveau dossier ou un tout nouveau projet. Et nous avons essentiellement ces trois fichiers. Chacun de ces fichiers a été validé dans ses propres commentaires. Par exemple, si je fais git log, vous voyez que nous avons trois validations. Dans le premier commentaire, j'ai commis un fichier TXT à un point. Dans le deuxième commentaire, je me suis engagé dans le fichier TXT point et entrez commit. Nous avons engagé un fichier TXT à trois points. C'est juste pour gagner du temps. Nous créons des projets, créons des fichiers, les ajoutons à la zone de préparation et validons ces modifications depuis des fichiers, les ajoutons à un certain temps. J'espère ne pas avoir à vous expliquer ça encore et encore. Nous n'avons aucune autre agence pour le moment. Nous avons la branche master par défaut. Voyons comment nous pouvons également modifier notre groupe d'annulations de validations. Et nous allons également parler de quelques autres commentaires dont je trouve qu'il est pertinent de parler en ce moment. Supposons que j'ai accidentellement validé ces modifications et que je voulais les annuler. Il y a maintenant trois options pour moi. Je peux simplement annuler ce commit, mais conserver les fichiers dans le répertoire de travail. C'est la première option. La deuxième option est que je peux annuler ce commit, conserver les modifications dans le répertoire de travail et également mettre en scène ces fichiers. Et puis la troisième option, j'annule ce commit ainsi que je supprime toutes les modifications qui ont été apportées dans ce commentaire. Permettez-moi donc de vous montrer tous ces scénarios. Et la commande pour cela est git reset. Et je vais dire « tête ». Quel est le symbole ? Je ne sais pas quel est le symbole. Je suppose que ça s'appelle Tilda. Si je ne me trompe pas, j'espère avoir raison. Ensuite, je vais donner un chiffre ici. Si j'en spécifie deux ici, j'aimerais annuler les commentaires. Essayons avec un seul commit. J'ai appuyé sur Entrée. Ce que cela a fait, c'est que cela a annulé le dernier commit. Mais nous avons toujours les fichiers dans le répertoire de travail, mais pas dans la zone de transit. Donc, si je fais git log maintenant, vous ne verrez que le premier, le deuxième commit. Mais si je le fais, vous allez voir un fichier TXT à trois points. Parce que comme je l'ai déjà mentionné, nous avons toujours les modifications dans le répertoire de travail. Si je fais git status maintenant, vous voyez que ce fichier n'est pas mis en scène. Nous pouvons donc introduire tous les changements que nous voulions introduire. Effectuez toutes les mises à jour. Dès que j'ai fait quelques modifications dans le fichier TXT à trois points que je voulais maintenant valider. Je peux donc appeler ces modifications dès que j'ai fait ces modifications, je vais ajouter à nouveau un fichier txt point. Et puis je vais refaire le commit git log. Maintenant, vous voyez que nous avons ces trois commentaires. Voyons maintenant ce qui se passerait si je lançais cette commande avec une option logicielle, ceci pour Lambda, ce combat. Mais nous avons toujours les fichiers dans le répertoire de travail ainsi que dans la zone de transit. J'exécute cette commande. Journal Git. Vous ne voyez que deux commits. Et si tu le fais, tu verras les trois fichiers. Si vous utilisez git status, vous verrez également que ces modifications sont mises en scène. Je peux donc simplement valider ces modifications. Je vais faire ce commentaire. Et la vie est revenue à la normale. Disons maintenant que j'ai commis une terrible erreur. Et je voudrais juste non seulement annuler ces modifications sous le commit, mais aussi me débarrasser de toutes les modifications que j'ai apportées dans ce commentaire. Eh bien, l'option pour cela est que vous devez utiliser git reset head tilda, nombre de commentaires auxquels vous aimeriez revenir. Ensuite, vous allez utiliser l'option durement. Maintenant, si vous faites git log, vous verrez évidemment deux commits. Mais si tu le fais maintenant, tu ne verras que deux fichiers. C'est comme si je n'avais jamais fait le troisième commentaire. 30. 0308 Récupérer le mystère perdu avec reflog: Supposons maintenant que vous avez changé d'avis. Vous avez l'impression d'avoir accidentellement annulé le retour et vous aimeriez récupérer toutes ces modifications. Eh bien, il y a un moyen de le faire. Heureusement, get, nous conserverons ces objets de commit et leur dépôt pendant un bon moment avant qu'il ne décide de les supprimer. Quand il fait la collecte des ordures et tout. Voyons donc si nous pouvons récupérer toutes ces modifications. Tout d'abord, nous devons obtenir le HashCode du commit. Ces modifications aimeraient être récupérées. Alors, comment connaît-on l'ID de validation ? instant, nous pouvons simplement faire défiler vers le haut et obtenir l'ID de validation. Mais il se peut que vous ne puissiez pas faire défiler vers le haut à chaque fois. Par exemple, si je ferme cette fenêtre et que je la rouvre, elle disparaît. Alors, comment sommes-nous sortis de l'identifiant de validation ? Eh bien, get propose une commande qui nous aidera car cette commande est log, notre journal de référence. Chaque fois que nous avons mis à jour nos amis dans le dépôt local. Mais en exécutant une commande, les journaux de référence en ont un enregistrement. Et vous pouvez voir tous ces enregistrements en exécutant cette commande. Ici, vous pouvez obtenir le HashCode de ce commit. Eh bien maintenant, je pourrais simplement ajouter git checkout et aller à ce commit. Et cela nous amènerait à un État de tête détaché. Cependant, vous pouvez simplement copier toutes ces modifications, apporter toutes ces modifications et effectuer un nouveau commit. Mais nous avons une meilleure façon d'y faire face. Donc au lieu de faire git checkout et de spécifier le hashCode de ce commit. Ce que nous allons faire, c'est spécifier l'option tiret b, et je vais spécifier un nom. Et ce nom sera essentiellement le nom de la branche que nous allons créer. Par exemple, disons « nouvelle branche ». Au fait, pour les noms de branches, nous n'utiliserions jamais d'espaces. Nous voudrions plutôt utiliser un trait d'union. Donc lorsque nous avons cette option tiret b, cela créera non seulement cette branche particulière, mais nous passerons également à cette branche. Et cela va pointer vers ce commentaire. Exécutons cette commande. Comme vous pouvez le constater, nous sommes passés à nouvelle branche que nous venons de créer. Et si je fais git log maintenant, vous pouvez voir que nous avons le troisième et les deux autres commentaires proviennent en fait de la branche master et escaladent la branche à partir de laquelle nous avons créé cette branche. Mais comment pouvons-nous intégrer les trois changements de commit dans notre branche master ? Eh bien, nous pouvons le faire avec emerge. Nous n'avons pas parlé de fusions. Nous en parlerons lors des prochaines conférences. Mais peut-être que je vais juste vous le montrer rapidement, juste pour vous donner une idée de ce qu'est une fusion. Pour cela, j'aimerais revenir à la branche master. Je vais utiliser la commande git, merge out, merge out, spécifier la branche que je souhaite fusionner dans la branche master. Dans ce cas, il s'agit d'une nouvelle branche. Maintenant, si je fais git log dans la branche master, vous allez voir que nous avons ces nouveaux changements. Ce que nous venons de faire est ce que l'on appelle une fusion rapide. Encore une fois, nous allons en parler davantage lors des prochaines conférences. N'y pense pas trop. Une dernière chose que j' aimerais mentionner est que lorsque vous inversez les modifications ou inversez un commit. Mais si vous avez déjà appliqué ces modifications au dépôt distant, cela va créer un problème. Puisque nous n'avons pas parlé dépôt centralisé et de collaboration d'équipe, je ne vais pas parler du Seder, mais en règle générale, souvenez-vous, si vous souhaitez annuler le Commit, faites-le avant d'appliquer toutes ces modifications au dépôt distant. 31. 0401 Fusion rapide vers l'avant: L'objectif d'une branche corrigée d'une fonctionnalité ou d'un bogue est fusionner tous ces changements dans le courant dominant d'evolution, qui serait généralement la branche master. Dans cette vidéo, parlons de ce qu'est la fusion rapide. Imaginez que vous avez un projet avec branche master et avec ces trois commentaires. Et c'est à ce moment-là que j'ai décidé de travailler sur le premier long métrage. J'ai donc créé une branche feature one et j'y ai également fait un tas de commits. Supposons maintenant que nous n'avons pas d' autres commentaires supplémentaires dans la branche master. Une fois que j'ai créé la branche feature, disons que j'ai terminé tout le travail j'ai à faire à l'intérieur de la branche feature one. J'ai testé tous ces changements. Et je veux maintenant que toutes les fonctionnalités d' une branche soient modifiées à l'intérieur de la branche master. En d'autres termes, je souhaite fusionner la branche feature one dans la branche master. Maintenant, une question pour vous, que puis-je faire ici pour que cette branche principale, nous ayons tous les changements de la branche feature one. Mettez la vidéo en pause et essayez de la comprendre. Eh bien, laissez-moi vous donner un indice. Je vais réécrire ce diagramme de ceci en ceci. Je n'ai rien fait. Je viens de soulever la fonction d' une branche mais vers le haut. Mais cela devrait vous donner une idée de ce que nous pouvons faire pour avoir toutes les modifications de la fonctionnalité 1 dans la branche master. Essayez-le. Eh bien, je vais vous donner un autre indice. C'est pour cette raison que nous appelons cela une fusion rapide . Quel est le rôle de FastForward là-dedans ? Eh bien, que diriez-vous de demander à Master de pointer vers le dernier commit ou de proposer une branche. Cela ne résoudrait-il pas le problème ? Essentiellement, la branche master a été transmise à un groupe de comètes. La branche master pointe maintenant vers un commit qui possède un instantané pointant vers toutes les modifications de la branche master plus toutes les modifications de la branche feature one. Et puisque nous en avons fini avec la branche feature one et que j'ai fusionné tous ces changements dans la branche master. Nous pouvons continuer et supprimer complètement cette branche. Désormais, la fusion rapide ne fonctionnera que si vous ne faites aucun commentaire dans la branche master après avoir créé la branche feature. Maintenant, j'ai une autre question à vous poser. Nous venons de voir comment fusionner tous les changements de la branche feature one dans la branche master à l'aide de la fusion rapide. Maintenant, serait-il logique de dire que je voulais fusionner tous les changements de la branche master dans la branche feature one. Cela n'a pas de sens car la branche feature one possède déjà tous les commits sont tous les changements de la branche master. Toutefois, si vous avez fait des commentaires dans branche master après avoir créé la branche fonctionnalité, c'est une tout autre histoire. Et nous allons en parler lors des prochaines conférences. Dans la vidéo suivante, nous allons jeter un coup d'œil à toute cette inaction. On se voit dans le prochain. 32. 0402 Fusionner rapidement en action: Afin d'expliquer la fusion rapide, j'ai ramené le projet dans cet état. Nous avons la branche master avec ces trois fichiers, ABC, et ils sont livrés dans trois commits différents. De même, nous avons une branche avec les fichiers D, E, F, et ils sont tous livrés dans trois commentaires différents également. Jetons maintenant un coup d'œil à l'inaction rapide. Sur la gauche, nous avons le Git Bash. Sur la droite, nous avons le répertoire de travail. Vous pouvez observer simultanément ce qui se passe dans le répertoire de travail pendant que nous exécutons des commandes sur Git Bash. Je suis actuellement dans la branche master et vous voyez donc des fichiers ABC. Si je devais passer à la branche de fonctionnalité, alors vous verrez que le répertoire de travail serait rempli avec tous les fichiers, ce qui inclut les modifications de branche master ainsi que la branche feature. Voyons maintenant quels engagements cette marque ne fait que pointer du doigt. Je vais faire des git refs, chef maître. Et de même, examinons ce que veulent les branches de fonctionnalité. Et si je fais git log, vous pouvez voir que la branche feature pointe vers le tout dernier commit, mais que la branche master pointe vers son dernier commit dans la branche master, qui serait celui-ci. Maintenant, je ne peux pas fusionner la branche master dans la branche feature car les branches de fonction ont déjà toutes les modifications de la branche master, cela n'a pas de sens. Nous devons donc revenir à la branche master. Ensuite, ils comprendront que nous voulons intégrer toutes les modifications de la branche feature dans la branche master. Et une fois que j'ai exécuté cette commande, nous devrions être en mesure de voir la branche master pointant vers ce commit. Il obtient donc la commande git merge name de la branche que vous souhaitez fusionner. Dans ce cas, il s' agit d'une branche. Et comme vous pouvez le voir, le résumé montre que ce sont tous les fichiers qui font maintenant partie de la branche master. Et même le répertoire de travail est mis à jour avec tous ces fichiers. Si vous regardez vers quelle branche master pointe, alors cela pointe vers le commit exact. Cette branche de fonctionnalité pointe. C'est beaucoup plus rapide pour toi. Nous pouvons maintenant supprimer la branche de fonctionnalité, mais nous allons en parler lors de la prochaine conférence. Une chose que j'aimerais mentionner est que vous ne voudrez peut-être pas toujours supprimer la branche une fois que vous en avez terminé. Parfois, vous souhaiterez peut-être le conserver pendant un certain temps, car dans certains cas, vous devrez peut-être apporter ces modifications de dernière minute. Il se peut également que vous souhaitiez apporter certains correctifs dans le cadre de la même branche. Vous allez donc utiliser à nouveau la même branche de fonctionnalité pour effectuer toutes ces modifications, les tester, les faire réviser, puis finalement fusionner toutes ces modifications dans la branche master. Et oui, vous pouvez réutiliser la même branche et fusionner la même branche encore et encore. Cependant, le plus souvent, nous créons une autre branche pour les corrections ou l'une de ces modifications de dernière minute , puis nous fusionnons ces modifications dans la branche master. Une autre chose que je voudrais mentionner est que cela se produit généralement sur GitHub dans un rembourrage centralisé. Puisque nous n'avons pas exploré GitHub, cela n'a aucun sens pour moi d'en parler maintenant. Néanmoins, la fusion est également le dépositaire local de Londres dans certains cas. Je te verrai le prochain. 33. 0403 Supprimer la succursale et récupérer: Voyons comment supprimer une branche pour expliquer cela. Une fois de plus, le projet est revenu à cet état. Je suis actuellement dans la branche Picture One. Si j'ai essayé de supprimer la branche alors que je suis réellement dedans, une erreur s'affichera indiquant que vous ne pouvez pas supprimer une branche Jet Dot. Laisse-moi essayer de le faire. Donc, la commande que je dois utiliser pour supprimer les branches, git branch. Ensuite, je vais utiliser l'option tiret D, assurez-vous qu'il s'agit d'un d minuscule , puis je vais spécifier le nom de la branche. Nous allons voir une erreur et il est dit que impossible de supprimer fonctionnalité de branche une récupérée dans untel dossier. Je vais revenir à la branche master pour pouvoir supprimer la branche feature one. Si j'essaie de supprimer maintenant, get to va nous avertir qu'aucun des changements dans une branche, ce qui est le plus dans toutes les autres branches. Et comme vous pouvez le voir, la fonctionnalité de branche 1 n' est pas complètement fusionnée. Mais comment sait-il que cette branche n'est pas fusionnée ? Il examinera le dernier commit de la branche feature one. Et il remarque qu'il n'y a aucune autre branche pointant vers ce commit. Get nous donne un avertissement. En plus de cela, il nous suggère également si nous voulons toujours supprimer cette branche, alors nous pouvons continuer et le faire avec l'option trait d'union d. Il s'agit d'un D majuscule par rapport au D minuscule, que nous avions utilisé précédemment. Et get nous a fourni une commande par défaut. Je peux juste le coller ici. Et cela supprimerait la branche. Et bien sûr, nous perdrons tous les changements introduits dans la branche feature one. Lorsque nous avons supprimé cette branche, git nous a fourni le HashCode du dernier commit juste au cas où nous voudrions en faire quelque chose. Supposons maintenant que j'ai fait une erreur en supprimant cette branche et que je voulais la récupérer. Qu'est-ce qu'une commande qui m' aidera à récupérer cette branche ? Encore une fois, cela vous est déjà familier. Nous l'avions utilisé lors d'une de nos précédentes conférences. Eh bien, c'est git, checkout tiret b. Et puis vous allez spécifier un nom de branche. Nous pouvons donner n'importe quel nom de notre choix. Mais je vais faire le même nom, une pizza. Ensuite, nous allons spécifier le HashCode du combat vers lequel cette branche doit pointer. Essentiellement, cette commande ne crée pas seulement la fonctionnalité de branche, mais nous allons également basculer vers cette branche avec le dernier commit étant ce commit avec cette fonctionnalité HashCode, une branche serait créée, et cette branche pointait vers ce commit que nous venons de supprimer. Si vous exécutez cette commande après un très long moment, après avoir supprimé la branche, il se peut que vous ne puissiez plus voir ce commit et que vous perdiez les données. Nous allons donc récupérer cette branche une fois de plus. Comme vous pouvez le constater, nous sommes passés à cette nouvelle agence. Et si vous utilisez git log, vous pouvez voir que la branche pointe exactement vers le même commit. En fait, la bonne façon de le voir a pris en compte ce qui se trouve à l' intérieur d'un fichier de branche. Et comme prévu, il pointe vers ce commit. Nous pouvons maintenant fusionner toutes les modifications en revenant à la branche master. C'est quelque chose que nous avons déjà vu lors de notre précédente conférence. Git, fusionne la fonctionnalité 1. Et ça marche. Vous pouvez maintenant supprimer cette branche avec l'option d minuscule et il n'y a aucun problème. Jetons un coup d'œil à la liste des branches. Et vous verrez que la seule branche que nous avons maintenant est Master. 34. 0404 Comprendre le Commit de fusion à trois voies et le Commit de fusion: Parlons de la fusion à trois voies et obtenez. Supposons que c'est l'état actuel de notre projet. Nous avons la branche master avec trois commits, m1, m2 et m3. Et puis nous avons également la branche feature avec les commits F1, F2 et F3. Et imaginez que dans chacun de ces commits, nous avons livré un seul fichier. Par exemple, dans M1 commit, nous livrons m1 point TXT. Dans M2 commit, nous livrons m2 point TXT, ainsi de suite pour tous les autres commentaires. Maintenant, je ne vais pas conserver les noms de fichiers dans ce diagramme juste pour le garder propre. Supposons maintenant que pendant que je travaille sur les modifications de la fonctionnalité 1, j'ai deux commentaires supplémentaires et la branche master. Maintenant, une question pour vous, si je décide de fusionner la fonctionnalité 1 dans le master maintenant, pouvons-nous nous attendre à effectuer une fusion rapide dans ce cas ? La réponse est non, elle ne pourra pas le faire. Supposons hypothétiquement que bon a fait une fusion rapide. Nous avons donc maintenant la branche master pointant vers la dernière fonctionnalité de validation une branche. Peux-tu deviner ce qui va se passer ? Eh bien, nous voulions perdre les modifications introduites et les combattants mfour et m phi parce qu'ils ne font pas partie de la hiérarchie parent du commit vers lequel pointe la branche master. Ce n'est pas une chose idéale à faire et le bien n'effectue pas de fusion rapide dans ce cas. performances informatiques sont ce que l' on appelle une fusion à trois voies. Donc, ce qui fonctionne essentiellement, c'est lorsque nous décidons de fusionner la fonctionnalité 1 dans la branche master, nous sommes allés dans la branche master et demandé à get d'effectuer la fusion. Et quand nous le disons, get créera artificiellement un commit avec ce que nous l'avons initié. Ce commit aura deux parents. En d'autres termes, cet objet commit pointe vers deux autres objets communs et ces commentaires sur les derniers commentaires de ces deux branches, ce commit est appelé merge commit. Et l' instantané résultant de ce commit, la combinaison des modifications introduites dans les deux branches. Essentiellement, si vous voulez afficher le répertoire de travail de la branche master après avoir effectué la fusion, vous allez voir toutes les modifications introduites dans les deux branches. Une fois la fusion terminée, nous pouvons supprimer la branche feature one. Notez que la suppression de la branche feature one ne supprimera que cette branche, mais pas les commits qui se trouvent dans la branche feature. Parce que merge commit fait référence à commit. Donc, la branche de fonctionnalité, donc get ne sera pas en mesure de supprimer cela, sont qualifiés pour la récupération de la mémoire. Ce dont nous parlons en ce moment est le meilleur scénario. Le plus souvent, nous avons des conflits de fusion. Par exemple, si j'ai ajouté le même fichier dans les deux branches. Ensuite, lorsque nous avons essayé de fusionner ces branches, get va nous dire qu' il y a conflit de modifications dans les deux branches uniquement après avoir résolu ce conflit de fusion. Eh bien, le git fusionne toutes les branches. Je vais parler des conflits de fusion dans les prochaines conférences. Et vous vous demandez peut-être pourquoi on parle de fusion à trois facteurs. Eh bien, vous trouverez également une réponse à cela dans les prochaines conférences. Une fois après, nous parlerons des conflits de fusion. Ensuite, nous allons examiner un exemple de fusion à trois, en supposant que nous n' avons aucun type de conflit. Je te vois au prochain. 35. 0405Three Way fusionner en action: Afin d'expliquer beaucoup de choses à l"étranger, le projet est dans cet état. J'ai d'abord validé M1, M2, M3 dans la branche master, puis j'ai créé le commutateur de branche de fonctionnalité et j' ai également fait trois commentaires là-bas. F1, F2 et F3. Une fois de plus, je suis revenu au master et j'ai fait des commits supplémentaires, M4, M5. C'est l' état actuel de notre projet. Et sans oublier que pour chaque commit, j'ai validé leurs fichiers spécifiques. Voyons maintenant ce qui est fait. Actuellement, je suis maître interne. Ainsi, vous pouvez voir les cinq fichiers correspondant à ces cinq validations. Si je devais passer à une branche, vous verrez M1, M2, M3 et F1, F2 et F3, mais pas m quatre et m phi, mais pas m quatre et m phi, qui sont venus dans la branche master après la création de la branche feature one. C'est la raison pour laquelle nous ne pouvons pas effectuer de fusion rapide. Maintenant, revenons branche master, effectuons la fusion et voyons ce qui va se passer. Fonctionnalité Git Merge 1. Et nous devons le faire depuis l'intérieur de la branche master parce que nous voulons intégrer toutes les fonctionnalités modifiées dans la branche master. Et quand j'exécute cette commande, elle a ouvert l' éditeur de texte par défaut que j'ai choisi lors de l'installation du bon. Dans mon cas, c'est Notepad Plus, Plus. Dans votre cas, cela peut être différent selon ce que vous avez choisi lors de l'installation de Git. Et ce qu'il nous demande, c'est de saisir une sorte de message. Il s'agit du message qui serait associé au commit de fusion. Je peux changer le texte en quelque chose d'autre en master, quelque chose de ce genre. Enregistrez le fichier et fermez la fenêtre. Et cela a créé le commit de fusion. Sinon, lors de l' exécution de cette commande, je peux également fournir l'option tiret m et fournir le message. De cette façon, get n' ouvrira pas l'éditeur de texte. Bon, regardons maintenant get log n z si Dieu a créé un commit de fusion. Et bien sûr, il a créé le commit de fusion. Et il a également mentionné que ce comité est basé sur ces deux engagements. Ce ne sont que les dernières comètes des deux branches. Nous avons donc ce HashCode de la branche master, et il appartient à la branche feature. Regardons ce qu'il y a à l'intérieur de cet objet de commit de fusion. Je vais donc le copier. Je vais appuyer sur Q pour revenir à la ligne de commande afin de pouvoir saisir certaines commandes. Fichier Git cat, tiret b et HashCode du commit de fusion. Et si vous remarquez qu'il pointe vers ces deux commits. L'un est le dernier commit, la branche master, qui serait ceci. Et c'est la dernière branche de la fonctionnalité. Regardons ce qu'il y a à l' intérieur de cet objet arbre. Je vais utiliser exactement la même commande. Et voyons ce qu'il y a à l'intérieur cet objet arbre. Et laissez-moi m'étendre. Cet objet arbre est en fait une combinaison de toutes les modifications effectuées dans les deux branches. Vous voyez donc tous ces fichiers, F1 point TXT, après dxdy, F trois, M1, M2, M3, M4 et M5. Et même dans le répertoire de travail, vous allez maintenant voir tous les changements de branche de fonctionnalité. Si vous revenez à la branche feature , vous remarquerez qu'aucune modification n'est apportée ici. C'est exactement le même répertoire de travail qu'avant, l'hypothèque. Nous pouvons maintenant supprimer la branche feature one. Mais tout d'abord, revenons à branche master car nous ne pouvons pas supprimer la branche sur laquelle nous nous trouvons actuellement. Je vais donc utiliser la commande get. Je vais dire le trait d' union de la branche git D, feature one. Et cela a supprimé la branche. 36. 0406 Comprendre les conflits de fusionner: Parlons des conflits de fusion et supposons que j'ai fait un commit dans la branche master, appelons-le M1. Et dans le cadre de ce commentaire, j'ai introduit le fichier produit point TXT avec quelques lignes de code. Maintenant, évidemment, cela n'a aucun sens d' écrire du code et un fichier TXT point. Vous devez faire l' hypothèse qu'il s' agit d'une sorte de fichier source, comme un fichier Java Python ou autre. Maintenant, je dois également mentionner que nous n'avons généralement jamais tendance à faire des commits dans la branche master. Ce que nous avons habituellement dans la branche master, ou ce que l'on appelle les commits de fusion, dont nous avons parlé précédemment. Lorsque nous parlons de référentiel centralisé et de collaboration d'équipe. Vous comprendrez comment chacun créerait ses propres branches pour marcher sur ses propres fonctionnalités, puis fusionner tous ces changements dans la branche master dans le référentiel centralisé. Ensuite, lorsque nous mettrons à jour le projet localement, tous les commits de fusion seront effectués par les autres membres de l'équipe dans notre branche master. Si cela semble déroutant, vous devrez attendre jusqu'à ce que nous parlions référentiel centralisé et de collaboration d'équipe. Pour l'instant, pour les besoins de cet exemple, supposons que nous effectuons des validations dans la branche master. J'ai fait M1 commit, introduisant ce produit de fichier point TXT avec quelques lignes de code. Et puis j'ai fait un autre commit, appelons-le m2. Cette fois, j'ai mis à jour le fichier point TXT du produit avec quelques lignes de code supplémentaires. Supposons maintenant que j'ai décidé de travailler sur une autre fonctionnalité. Devine quoi ? Je vais créer une branche de fonctionnalité, travailler dessus, introduire tous ces changements. Et puis faisons un commit dans lequel j'ai modifié le fichier TXT point du produit en écrivant quelques lignes de code supplémentaires qui sont pertinentes pour la fonctionnalité 1. Pendant ce temps, je suis retourné à la branche principale. Notre fichier de projet devrait donc ressembler à ceci parce que la branche master pointe vers m pour valider. Supposons ensuite que j'ai créé une autre branche master engagée mettant à jour le fichier TXT point du produit, comme vous le voyez ici. Maintenant, j'ai une question pour toi. Supposons que j'ai décidé de fusionner branche feature dans la branche master. Et j'exécute la commande et j' arrive à fusionner la branche. Est-ce que vous vous attendez à ce que Get effectue la fusion ? La réponse est non. Pourquoi ? Parce que nous avons quelques versions du fichier point TXT du produit. Dans la branche master, nous avons produit point TXT que vous voyez sur la gauche. Et dans la branche fonctionnalité, nous avons le fichier que vous voyez sur la droite. Lorsque nous demandons à Good de fusionner, il ne peut pas conserver les deux fichiers. comprenez pas quels changements il doit conserver ou quels changements il doit conserver. Évidemment, ce n'est pas assez intelligent pour apporter des modifications en fonction de nos besoins. Il nous laissera donc le soin d' apporter tous les changements, de résoudre les conflits. Ce n'est qu'alors que vous pourrez réellement effectuer la fusion et créer un commit de fusion. Essentiellement, lorsque vous exécutez la commande pour fusionner, elle génère une erreur indiquant qu'elle a trouvé complexe dans certains fichiers. Et ce n'est qu'après les avoir résolus qu'il va fusionner les modifications et créer un commit de fusion ? Pourquoi cette fusion s'appelle-t-elle une fusion à trois ? Vous vous demandez peut-être, eh bien, c'est essentiellement parce que cette fusion implique trois instantanés, les deux derniers commentaires et le convect qui est un ancêtre immédiat de ces deux commentaires. Ce collègue comparera le fichier dans instantané de l'ancêtre immédiat avec les fichiers des derniers instantanés dans ces deux branches. Maintenant, si tu ne l'as pas compris, c'est tout à fait normal. Ça ne vaut pas vraiment la peine de le savoir. Pour l'expliquer. Eh bien, je dois vraiment aller plus loin et encore, entrer dans ces HashCode et tout, ce que je ne veux pas parce que ce n'est pas du tout ce qui se souvient simplement que ce type de modèle s'appelle une fusion à trois. Et cela devrait suffire. Et le mode avance rapide est également appelé pour émerger car il n' implique que quelques instantanés. Ensuite, nous allons examiner tout cela en action et voir comment nous pouvons résoudre les conflits. 37. 0407 Fusionner les conflits dans l'action Partie 1: Très bien, examinons les conflits de fusion, l'inaction. Et pour cela, j'ai un nouveau dossier qui n'a actuellement rien. Nous allons tout faire à partir de zéro. Dans cette vidéo, nous allons essayer de créer un scénario où nous avons des conflits. Ensuite, dans la vidéo suivante, nous verrons comment résoudre ces conflits pour pouvoir fusionner les branches. Tout d'abord, initialisons le projet. Supposons maintenant que j'ai reçu un projet de l'un des clients, alors qu'il m'a été demandé de créer une application de gestion de produit. Dans le projet, il se peut que j'aie ces fichiers. Il se peut que nous ayons un fichier produit contenant le code source associé au produit. Ensuite, nous pouvons avoir un fichier d'inventaire, puis peut-être un fichier d' administration également. Maintenant, évidemment, ces fichiers ne peuvent pas être des fichiers point TXT. Vous devez faire l' hypothèse qu'il s'agit d'une sorte de fichier source comme Java, Python, Node.JS ou autre. Maintenant allons-y et remplissons quelque chose dans ce fichier, simulant que nous sommes en train d'écrire du code source. Commençons par le fichier txt point du produit. Comme ça. Vous devez supposer qu'il s'agit en fait d'une sorte de code source. Enregistrez le fichier et fermez-le. Et je vais faire de même pour les deux autres dossiers. Enregistrez le fichier et fermez-le. Faisons de même pour le fichier d'administration. Enregistrez et fermez ça. Laissez-nous préparer tous ces fichiers. Git ajoute. J'utiliserai un caractère générique pour préparer tous les fichiers. Et validons ces changements. Peu importe, un message. Supposons maintenant que j'ai commencé à travailler sur une autre fonctionnalité. Je dois donc créer une autre branche pour travailler sur toutes ces modifications liées aux fonctionnalités. Je vais utiliser la commande git checkout hyphen b, puis le nom de la branche. Donc, cette commande créera une branche feature one et basculera vers elle. Nous sommes donc actuellement dans la branche feature one. Laissez-nous apporter quelques modifications et l'inventaire de ces deux fichiers ainsi que le fichier txt point produit. Mais nous allons laisser le fichier TXT point admin tel quel. Je vais simplement ajouter quelques lignes de code supplémentaires. Mais je vais dire feature au début de ces lignes, juste pour que nous sachions que ces lignes sont introduites dans la branche feature. Vous connaissez le but de tout cela dans un moment. Je vais faire de même pour le fichier txt de point d'inventaire. Ainsi, enregistrez le fichier et fermez-le. Mettons en scène tous ces changements. Certains messages et valident tous les changements. Permettez-moi de revenir au maître une fois de plus. Effacons l'écran et essayons de mettre à jour le fichier TXT point du produit. Mais laissez ces deux tailles de fichier. Évidemment, je ne verrai pas tous ces changements liés aux fonctionnalités ici parce que nous sommes revenus à la branche master. Fermons le fichier, préparons ces modifications et validons ces modifications. Comme ça. Donc juste pour réitérer ce que nous avons fait, nous avons tous ces trois fichiers qui n'ont pas été déposés en demande tels quels avant la création de la succursale. Le fichier de stock est mis à jour dans la branche fonctionnelle, mais pas dans la branche principale depuis la création de la branche, mais le fichier produit a été modifié dans les deux branches. Pouvez-vous maintenant deviner lequel de ces fichiers sera en conflit ? Lorsque nous avons essayé de fusionner, les modifications se poursuivront à partir de la vidéo suivante. 38. 0408 Fusionner les conflits dans l'action Partie 2: Tout ça. Essayons de réaliser la fusion et de voir ce qui se passerait. Je suis actuellement dans la branche master et quand exécuter la commande git merge feature one. Good dit qu'il a engendré des conflits dans le fichier TXT point du produit. Et il indique que la fusion automatique a échoué, corrige les conflits, puis valide le résultat. Cela va de soi. En plus de cela, Gateway indique également que notre projet est en état de fusion. En état de gestion. Git formate tous ces fichiers conflictuels de manière à ce qu' il soit plus facile pour nous comprendre la complexité et de les résoudre. Vous comprendrez ce que je veux dire dans un instant. Mais essayons d'exécuter la commande git status et voyons ce qu'elle a à dire. Cela dit que nous avons des chemins non fusionnés. Et il nous demande de corriger le complexe, puis d' exécuter la commande git commit. Et si nous décidions de sortir de cet état de fusion ? Nous pouvons exécuter cette commande avec dash, dash, j'ai acheté l'option, j'ai acheté l'état émergent et je ramènerai le projet tel qu'il était avant d' exécuter la commande merge. Il a préparé le fichier TXT du point d' inventaire car il n'y a aucun conflit. Il est prêt à être fusionné. Mais alors que pour le fichier TXT point du produit, il est classé dans des chemins non fusionnés. Donc, pour tous les fichiers répertoriés dans cette section, nous devrons résoudre les conflits et demander à get de valider toutes ces modifications pour terminer l'opération de fusion et créer la validation de fusion. Regardons maintenant le contenu du fichier TXT point du produit. Pendant que notre projet est en cours de fusion. Je voulais dire fichier TXT de produit cat. Et vous pouvez voir que c' est un peu différent de ce à quoi vous auriez pu vous attendre. Vous verrez la même chose même si vous ouvriez le fichier dans un éditeur externe. Cela signifie essentiellement que cette section de code appartient à head, qui signifie que cet appel appartient à la branche vers laquelle il pointait. Il s'agit essentiellement des modifications introduites dans la branche master. Ensuite, nous avons ces changements qui ont été introduits dans la branche feature 1. Si vous avez acheté l'état émergent en disant git merge trait d'union, tiret acheté. Vous verrez que tout ce formatage a disparu. Et notre projet est essentiel dans l'immobilier comme si nous n'avions jamais exécuté la commande de fusion. Essayons de fusionner à nouveau et voyons comment nous pouvons résoudre ces conflits. Maintenant, en tant que programmeur, vous devez décider laquelle de ces modifications vous souhaitez conserver. Ou si vous souhaitez conserver ces deux modifications, vous pouvez également le faire. Vous pouvez littéralement faire l'eau que nous voulons. Une fois que vous avez terminé, demandez simplement à get de valider ces modifications et de créer les objets de fusion. Comment terminer la fusion des deux branches. Je dois donc me débarrasser de ces personnages étranges qui ont été introduits. Et puis j'aimerais peut-être supprimer cette ligne de code, mais garder les trois. Juste un exemple. Quoi, oh, c'est logique. Vous aimeriez conserver ce code. Enregistrez et fermez-le. Et une fois que vous avez résolu tous ces problèmes manuellement, vous pouvez continuer et dire git commit. Avant d'entrer, nous devons réellement mettre en scène ce fichier, le fichier TXT point du produit. Ensuite, nous pouvons aller de l'avant et avec les modifications, nous demandons d' entrer un message de validation. Je suis satisfait de celui par défaut. Je voulais enregistrer ce fichier, le fermer. Et cela a réussi à créer un commit de fusion, ce qui signifie que notre marge est maintenant terminée. Ainsi, vous ne verrez plus le gène status more. Examinons maintenant le contenu de tous ces fichiers. Le fichier TXT admin point reste tel quel car il n'est jamais modifié dans aucune des branches. Bref. Dans le fichier de stock, vous allez voir toutes les modifications apportées aux fonctionnalités. Et elles ont été fusionnées à partir de la branche feature. Mettre dans le fichier txt point du produit. Il contient le code que nous avons mis à jour lors de la résolution des conflits. J'espère également que vous avez compris la nécessité de disposer d' un outil plus robuste pour gérer votre projet et ses fichiers. Et aussi être capable de visualiser tous les changements historiques, etc. Et c'est là que des outils tels que Visual Studio, Code, GitHub , Desktop, l'arbre source, etc. , Desktop, l'arbre source, etc., entrent en scène. Nous allons les explorer lors de prochaines conférences. 39. 0409 Installer et configurer le code Visual Studio pour fonctionner sur Git: Bon, il est temps de l'installer et d'utiliser l'un des outils disponibles pour nous aider à mieux gérer notre projet , car nous ne pouvons pas simplement continuer à utiliser le système de fichiers Windows et Git Bash pour travailler sur notre projet. fur et à mesure qu'un projet devient plus complexe, nous avons besoin d' un outil qui nous aidera à mieux gérer notre projet et à pouvoir visualiser certains des changements historiques ou la liste des validations que nous avons effectuées. Jetez un œil à la liste des branches tout en étant capable d' effectuer certaines opérations sans avoir à exécuter de commandes dans Git Bash. Il existe donc de nombreux outils disponibles en ligne et aucun outil unique ne convient à toutes sortes de choses. Si vous allez sur le site officiel de gate, qui est Git SCM.com, python SCM.com. Et si vous allez dans cette section des lignes de grille, vous verrez qu'ils recommandent tous ces outils. Si vous utilisez l'un de ces outils, il ne devrait pas être difficile pour vous d'utiliser les autres outils disponibles ici. Parce que bien qu'ils diffèrent en termes d'interface utilisateur graphique, ils offraient à peu près les mêmes fonctionnalités. Github, le bureau et l'arborescence des sources, ou deux des choix les plus populaires. Mais nous allons utiliser Visual Studio Code. La raison pour laquelle je le recommande est que Visual Studio Code est l'un des éditeurs de code les plus populaires. C'est l'un des choix les plus populaires pour développer des applications JavaScript Python, et il prend en charge de nombreux autres langages de programmation. Mais ce qui différencie le code Visual Studio de certains de ces outils est précieux ici , c'est sa capacité à installer des extensions. Et c'est ainsi que nous allons installer une bonne extension. Et cela vous donnera certaines des fonctionnalités offertes par certains de ces outils. Ces outils sont là. Visual Studio Code est plus un outil holistique, plutôt que de simplement viser à obtenir des informations spécifiques. Une fois que vous serez habitué à utiliser Visual Studio Code, il vous sera très facile comprendre certains de ces outils ET portes. Si vous voulez choisir l' un de ces outils, vous pouvez le faire si cela vous convient. Mais je vais utiliser Visual Studio Code avec une recherche rapide sur Google. Nous sommes arrivés à cette page. Téléchargez Visual Studio, en fonction du système d'exploitation que vous utilisez. Je l'ai déjà fait. Laissez-moi lancer le programme d'installation. L'installer est assez simple. Vous pouvez tout laisser aux valeurs par défaut sauf si vous souhaitez modifier quelque chose. Ok, c'est installé. Lancez Visual Studio Code. Tout d'abord, allons dans l'Explorateur et quand ouvrir le projet en cliquant sur Ouvrir le dossier. Je vais choisir l'application que nous avons créée précédemment. En plus de cela, je vais aller la section intitulée « extensions ». Je chercherais Get. Get Lens est l'un des choix les plus populaires. Get graph est également un bon choix. Laissez-nous l'installer. Très bien, dans la vidéo suivante, nous allons voir comment gérer conflits de fusion dans le code Visual Studio. Cela vous donnera donc une certaine exposition à Visual Studio Code ainsi qu' aux opérations d'obtention que nous pouvons effectuer dessus. Je te verrai le prochain. 40. 0410 Explorer le code VS et exécuter des opérations GIT: Bien, avant de voir comment créer des conflits de fusion et les résoudre dans le code Visual Studio. Permettez-moi de vous présenter l' état actuel de notre projet. Si vous vous souvenez, nous avions fusionné nos modifications de la fonctionnalité 1 à la branche master. Voici la liste complète des fichiers de notre projet. Vous pouvez simplement cliquer dessus pour voir leur contenu. Et si vous allez dans cette section contrôle de source, vous pouvez également y accéder en appuyant sur Ctrl Shift G. Et comme nous avions installé cette extension good graph, vous devriez pouvoir regarder cette icône. Vous pouvez voir ici tous les changements historiques que nous avons introduits. Vous pouvez également voir la représentation graphique de toutes les listes de validations que nous avons effectuées, des branches que nous avions créées, et même de la fusion que nous avions effectuée précédemment. C'est le premier commit que nous avons effectué dans la branche master, puis nous créons une branche de fonctionnalité. Nous y avons fait un commentaire. Ensuite, nous avons fait un commentaire et une branche master et finalement des branches de fonctionnalités fusionnées à l'intérieur de la branche master. Pour créer la commande de fusion. Il n'a pas cliqué sur l'un de ces commits et a jeté un œil aux modifications introduites dans ce commit particulier en cliquant sur un fichier particulier. Et vous pouvez voir les changements. Allons de l'avant et créons des conflits dans lesquels nous, les humains, sommes naturellement doués. Revenons à Explorer. Mais avant cela, voyons comment créer une nouvelle branche. Je vais créer une nouvelle branche ici. Je vais donc cliquer avec le bouton droit de la souris sur ce commit particulier et dire Créer une branche. Appelons ça fonction à branche, peu importe. Et j'aimerais également passer à cette branche. Je coche donc cette case à cocher créer une branche. Nous sommes donc passés à cette fonctionnalité de branche que nous venons de créer. Vous pouvez le voir en jetant un œil ici. Vous pouvez voir ici la liste complète des succursales. Une fois que vous avez cliqué dessus, vous pouvez voir la liste complète des branches. Si vous souhaitez basculer vers l'une des branches, il vous suffit de cliquer dessus. Nous souhaitons donc simplement maîtriser la branche. C'est donc ce que vous voyez ici. Permettez-moi de revenir à la branche feature two et de faire un commit. Je vais voir l'Explorateur. Permettez-moi simplement d'apporter quelques modifications et de fonctionnalités de fichier de stock aux modifications apportées au fichier de stock ou autre. Je vais revenir à cette section Contrôle de source. Je vais cliquer sur cette icône en forme de coche. En faisant ça. Il me montre un message disant qu' il n'y a pas de changement progressif à venir. Souhaitez-vous mettre en scène tous les changements et les valider directement ? Si je clique sur Oui, maintenant, il va mettre en scène les changements avant s'engager sans que je doive le faire. Ou si vous souhaitez le faire vous-même, vous pouvez également le faire. Cliquez avec le bouton droit sur ce fichier qui se trouve actuellement dans la catégorie des modifications. Puis cliquez sur Stage Changements. Cela placerait ce fichier dans la catégorie des modifications planifiées. Et maintenant, si tu y arrives , tu ne devrais pas avoir de problème ou quoi que ce soit. Mais laissez-nous entrer une sorte de message de validation. Peu importe. Cliquez sur cette icône et venez de faire un nouveau commit et de présenter deux branches. Regardons le graphique. Comme vous pouvez le voir, nous avons maintenant ajouté un nouveau commit dans le graphique. Et voilà. Revenons maintenant à la branche master. Laissez-nous apporter des modifications à ce même fichier de stock. Pour créer des conflits, enregistrez le fichier. Retournez ici. Cette fois. Appuyez sur le S. Si vous n'aimez pas voir cette invite à nouveau, vous pouvez simplement appuyer sur Jamais. Revenons en arrière pour obtenir le graphique une fois de plus. Comme vous pouvez le voir, nous avons maintenant une nouvelle branche commit et master. Essayons maintenant de réaliser la fusion. Quelles sont nos performances dans Visual Studio Code ? Mais cette extension, eh bien, c'est assez simple. Cliquez avec le bouton droit sur l' une des branches. Je vais cliquer sur la fonctionnalité vers la branche. Et vous pouvez choisir cette option qui dit fusionner dans la branche actuelle. Qu'est-ce que la branche actuelle, c'est-à-dire le masque ? Eh bien, c'est simplement la branche vers laquelle cela pointait. En d'autres termes, il s'agit de la branche master. Cliquons dessus et voyons ce qui se passe. Il nous demande si nous voulons créer un nouveau commit, même si la fusion rapide est possible ? Je n'aime pas répondre. Oui, fusionnez. Comme prévu, nous avons un inventeur de fusion automatique de conflits ou dxdy. Et puis ça dit qu'il y a eu un conflit. Rejetez-le, allez dans l' Explorateur, allez dans ce fichier. Et cette fois, il a le format chez nous de cette manière, comme avant. Mais nous utilisons aujourd'hui Dieu nous a donné peu d'options. Si vous le remarquez, acceptez les modifications actuelles, les modifications entrantes ou les modifications qui arrivent de la fonctionnalité vers la branche principale. Ou acceptez les deux modifications. Vous pouvez également comparer les modifications. Tu peux choisir. Chacune de ces options est si vous souhaitez effectuer votre propre modification, vous pouvez donc le faire également. Il suffit de tout supprimer et d'apporter vos propres modifications ou de modifier les modifications existantes. Peu importe. Ajoutons comme pour conserver les deux modifications ou cliquez sur ce qui dit accepter les modifications. Enregistrez maintenant le fichier. Revenez au contrôle de source. Avant de l'engager. Mettons en scène ces changements sont assez mis en scène. Cliquez sur cette case à cocher. Je suis satisfait du message existant. Et devine quoi ? Cela vient de créer le commit de fusion. Maintenant, si vous utilisez un outil différent, non le code Visual Studio, vous devriez être en mesure d'examiner toutes ces opérations d' une manière ou d'une autre. Seule l' interface utilisateur graphique peut changer. Mais dans tous ces outils, vous pouvez effectuer à peu près le même ensemble d'opérations. Par exemple, si vous allez sur le site officiel de l'arbre source, en jetant simplement un œil à cette image, vous pouvez en dire long. Nous avons donc une histoire qui montre les changements historiques. Vous avez également ce graphique, tout comme celui que nous avons dans Visual Studio Code. Vous pouvez également aller dans cette section branches pour jeter un œil aux branches et faire quelque chose avec cela, comme les créer, les supprimer, etc. Vous pouvez également effectuer des validations. Et certaines des autres opérations que nous n'avons pas explorées. Nous allons certainement explorer dans les prochaines conférences. Mais j'espère que tu as compris. Peu importe l'outil que vous utilisez. En fin de compte, chaque outil a le même objectif, qui est de simplifier votre travail. Maintenant je suppose que nous pouvons supprimer cette branche. Nous n'en aurions plus besoin. Je vais donc cliquer avec le bouton droit de la souris sur cette branche et dire Supprimer la branche. Peut faire la même fonction, une branche également. Et bien sûr, la marque leader ne supprime pas ses commits. Comme nous l'avions déjà dit. J'espère que c'est logique, non ? Faire ce que je viens de faire dans Visual Studio Code et avoir une idée de la façon dont tout fonctionne. Et ne vous laissez pas intimider par cet outil. C'est assez simple. L'outil est tout simplement comme un éditeur de texte avec des fonctionnalités vraiment intéressantes. C'est là pour nous faciliter la vie, pas la rendre plus difficile. Je te verrai le prochain. 41. 0411 Git Rebase vs Merge: Parlons de git rebase. Git rebase est une sorte d'alternative à la fusion. Cela sert à peu près le même objectif qu'avec une opération de fusion. Cela étant dit, vous ne pouvez pas remplacer l'un par l'autre. Nous ne pouvons pas remplacer VBS par la fusion, et vice versa, nous ne pouvons pas remplacer la fusion par le rebase. Il a ses avantages et inconvénients et chacun a son propre objectif. C'est ce dont nous allons parler dans cette conférence et dans les deux prochaines conférences. Tout d'abord, essayons de comprendre ce qu'est exactement le rebase. En cas de fusion en trois étapes, demande GET de créer un commit de fusion dont l'instantané constituerait les modifications des deux branches. Bien que cela ne semble pas être un problème, nous commençons à y voir des problèmes, en particulier lorsque notre projet s' agrandit de plus en plus. Tout d'abord, la fusion créerait ce commit de fusion supplémentaire, ce qui pourrait être inutile. Deuxièmement, cela crée le problème de ce que l'on appelle l' historique des commits spaghetti. Si vous effectuez trop d' opérations de fusion dans votre projet. Voici à quoi pourrait ressembler l'historique de notre projet. Maintenant, si vous deviez jeter un œil à tous les commits historiques effectués , disons que vous avez exécuté commande git log dans la branche master. Tout ce que vous allez voir, c'est un tas de commits de fusion. Vous ne pouvez pas voir les modifications introduites dans les branches individuelles. Vous devez parcourir la hiérarchie parent pour pouvoir consulter toutes les modifications ou tous les commentaires relatifs à la branche. Cela va créer beaucoup de confusion. Rebus put résoudre ces problèmes que nous voyons avec les commits de fusion. Afin de comprendre comment fonctionnent exactement les remises, supposons que nous n'avons pas fusionné ces deux branches. C'est l' état actuel de notre projet. Supposons maintenant que je suis dans la branche feature one et que j'ai lancé la commande git rebase. Ce qui serait bon maintenant , c'est d'abord essayer de trouver l'ancêtre commun des deux branches, qui dans ce cas est N3 commit. Ensuite, il stockera temporairement toutes ces modifications introduites dans la fonctionnalité 1. Quelque part dans le dépôt. Il pointerait alors la branche feature one vers la pointe de la branche master, qui dans ce cas est m phi commit. Git réappliquera tous les commits stockés un par un. C'est ainsi que nous avons créé la branche AT MY commit et introduit toutes ces fonctionnalités qui conduisent à des changements dans la branche de fonctionnalité. Auparavant, notre fonctionnalité est basée sur M3 commit. Maintenant, après avoir exécuté la commande rebase, elle est maintenant rebasée sur m phi. Maintenant, en faisant cette opération, vous pouvez aussi bien voir des conflits. Nous pouvons les résoudre de la même manière que nous avions résolu des conflits en cas d'opération de fusion. Nous sommes allés voir un exemple de cela dans les prochaines conférences. Maintenant, si vous jetez un œil à ce diagramme, vous remarquez que nous pouvons réellement effectuer une fusion en avant rapide de cette façon. Devine quoi maintenant ? Aucun commentaire supplémentaire n'a été introduit. Les validations d'un allo sont linéaires avec une opération de fusion. Si vous avez eu ce problème d'historique des commits spaghetti avec rebase, nous avons un développement linéaire comme vous le voyez ici, ce qui nous permet de regarder plus facilement ce qui nous permet de regarder plus facilement l'historique des commits. Et si vous deviez exécuter la commande git log maintenant, vous verrez non seulement comment les modifications introduites dans la branche master, mais également tous les commentaires liés aux fonctionnalités manière linéaire. Maintenant, vous pensez peut-être que nous pouvons commencer à utiliser rebase et que nous n' aurions plus jamais à utiliser la fusion. Tu peux te tromper. Il existe certains scénarios où rebasage est la chose idéale à faire, et il existe d'autres scénarios où beaucoup est une meilleure option. Vous en saurez plus à ce sujet. 42. 0412 Réaliser un nouveau fond dans le code VS: Très bien, regardons un exemple de git rebase. Mais avant cela, laissez-moi vous expliquer l'état actuel de notre projet. J'ai créé un tout nouveau projet dans ce but et j'ai fait un tas de validations. Permettez-moi de vous expliquer exactement ce que j'ai fait. Depuis la branche master dans le cadre du tout premier commit, je viens d'introduire ces fichiers TXT, l'inventaire administratif et les fichiers TXT point produit. Et dans chacun de ces fichiers, je viens d'ajouter quelques lignes de texte comme si nous avions écrit du code. Le commit suivant est également entré dans le master. Et avant cela, j' ai bien sûr créé une branche basée sur le tout premier commit. cadre du deuxième commit, comme le message nous le suggère, admin édite et master. Je viens d'ajouter une ligne de texte dans le fichier TXT admin point, comme ça. Ensuite, j'ai fait mon premier commit dans la branche de fonctionnalité et le message suggère des modifications d'inventaire à partir de la branche feature one. Je viens d'ajouter une ligne de texte dans le fichier inventé ou TXT. La prochaine fois, faites un commit dans la branche master. Et cette fois, j' ai ajouté une ligne de texte dans le fichier TXT point du produit. Et puis j'ai fait un autre commentaire dans la branche fonctionnalité où j'ai édité le fichier TXT point du produit. En bas de la ligne. Lorsque nous effectuons le rebasage, nous allons avoir des conflits dans fichier TXT point du produit car nous avons effectué un commit dans master où nous avons édité le fichier TXT point du produit, et la même chose est faite dans le branche de fonctionnalité également. La prochaine fois, j'ai créé une autre branche master engagée. Eh bien, ce n'est pas vraiment nécessaire pour que je l'explique, mais j'ai fait ce commentaire juste pour que le graphique ressemble à ce que nous voulons. Actuellement, cette ligne bleue représente la branche principale, tandis que la ligne rouge représente la branche de l'entité. Cependant, ce n'est peut-être pas toujours le cas. Quelle que soit la branche dans laquelle nous effectuons le dernier commit qui sera affiché en premier. Par exemple, si je devais créer une autre branche de fonctionnalité de commentaire, branche de fonctionnalité deviendrait bleue et la branche principale deviendrait rouge. Cela peut sembler déroutant. Et c'est pourquoi j'ai ajouté ce commit supplémentaire afin que la branche master apparaisse en premier, puis la branche feature. Maintenant, avant de poursuivre, il est vraiment important que vous compreniez ce qui se passe exactement et quels sont tous les changements que nous avons introduits dans chacun de ces commits. Je vais donc mettre ce projet à votre disposition pour que vous puissiez le télécharger. Vous pouvez simplement l'importer dans code Visual Studio et consulter la liste des modifications, comprendre, et ensuite seulement continuer. Sinon, vous allez commencer à vous embrouiller. Si tu es capable de suivre, c'est génial. Si ce n'est pas le cas, faites une pause, comprenez ce qui se passe ici, puis continuez à regarder. Comme vous pouvez le voir, la branche feature one est actuellement basée sur le tout premier commit sur la branche master. Nous voulons maintenant rebaser la fonctionnalité d' une branche vers la dernière branche master de validation. Comment faisons-nous cela ? Eh bien, cliquons avec le bouton droit de la souris sur le tout dernier commit, la branche master. Et puis nous avons cette option appelée rebaser la branche actuelle sur ce commit. La branche actuelle est la branche principale. Quand passer à la branche de fonctionnalité. Et nous savons que nous avons poussé pour inclure une branche parce que ce cercle ici pointe vers une branche auparavant, il pointait vers la branche principale. Maintenant, cliquons avec le bouton droit sur la dernière validation la branche master et choisissons cette option qui dit rebaser la branche actuelle. Sur ce point, les branches actuelles comportent une branche. Et cela devrait idéalement rebaser, sauf si nous avons des conflits. Bien sûr, nous allons voir des conflits car, comme je l'ai déjà mentionné, nous avons édité le fichier TXT point du produit dans les deux branches. Nous allons donc cliquer sur rebaser. Comme vous pouvez le constater, nous sommes en conflit. Laissons tomber cela. Eh bien, nous devrions idéalement voir ces fichiers avec des fichiers complexes, laissez-moi rafraîchir. Et voilà, vous l'avez. Vous pouvez résoudre les conflits comme vous le souhaitez. Dans mon cas, je veux simplement accepter les deux modifications. Enregistrez le fichier. Ensuite, je vais appuyer sur cette icône plus pour mettre en scène ce fichier. Ensuite, je peux cliquer sur cette icône de vérification pour procéder à l'opération de rebase. Et le message qui est renseigné par défaut ici est le message de la fonctionnalité de commentaire, une branche qui crée réellement le conflit. Nous avons ouvert cet éditeur. Mais je vais juste laisser le message tel quel, fermer le dossier. Et cela devrait terminer l'opération de rebase. Comme vous pouvez le voir, les quatre premiers commits sont hors branche master et les deux autres commentaires appartiennent à la branche feature. Nous pouvons maintenant procéder à la marche rapide en avant. Je vais donc revenir à la branche master. clic droit sur ce commit. Ensuite, je peux choisir de fusionner dans la branche actuelle. Je veux donc fusionner la branche feature one dans la branche master. Je ne veux pas créer un nouveau commit pour la fusion rapide. C'est ainsi que vous effectuez le rebasage. Et si vous remarquez, nous avons ce développement linéaire, ce que nous attendons avec rebase. Je te verrai ensuite. 43. 0413 Git Rebase dans Git Bash Sauter les conflits et avorter le Rebase: Très bien, voyons comment nous pouvons exécuter git rebase à partir de Git Bash. Actuellement, nous sommes dans la branche master pour passer à une branche afin de pouvoir exécuter cette commande. Et d'ailleurs, nous avons ramené le projet à son apparence au début de notre vidéo précédente. Pour que nous puissions refaire les choses et voir comment cela fonctionne depuis Git Bash. Je vais passer à la branche Feature. Il peut observer simultanément ce qui se passe dans ce graphique. Rebase Git. Où est-ce que je veux rebaser pour effectuer un commit ? Cette branche principale pointe vers quelqu'un qui dit Maître. Et comme vous pouvez vous y attendre, nous allons voir les conflits. Allons-y et dissolvez-les. À mon avis, encore une fois, je n'accepterais pas les deux modifications, sauvegarderais le fichier et retournerais à Git Bash, allé préparer ce fichier, git add product dot fichier TXT. Ensuite, nous devons exécuter cette commande. Git rebase, tiret, trait d'union continue à effectuer le rebasage. Et c'est exactement ce que je vais faire. Vous avez également la possibilité d'ignorer. Si vous exécutez cette commande, git ignorera simplement le commit à l' origine des conflits. C'est comme si vous n'aviez pas créé la branche de fonctionnalité de commentaire l'origine des conflits. Si vous exécutez cette commande, peut-être après avoir réussi le rebasage, vous souhaiterez peut-être réappliquer toutes ces modifications manuellement. Cependant, puisque nous avons résolu le problème, vous n'avez pas besoin d' utiliser cette option, mais n'hésitez pas à l' expérimenter. Une fois que j'ai exécuté cette commande. Encore une fois, cela va nous montrer le message. Nous pouvons le garder tel quel. Ou si vous souhaitez le modifier, vous pouvez le modifier. Fermons. Comme vous pouvez le voir ici, nous avons rebasé notre branche feature avec la branche master. Passons maintenant à la partie fusion, que nous allons revenir à master git fonctionnalité master git merge 1. Et comme vous pouvez le voir, les deux branches sont appariées. Si c'est un os de la commande git log maintenant, vous allez voir tous les commits introduits dans les deux branches de manière linéaire, ce dont nous avons besoin. Et au fait, une opération de rebase performante. Et pour une raison quelconque, vous avez décidé de l'abandonner, alors vous pouvez utiliser cette option, git rebase, trait d' union, tiret que j'ai acheté. Je te verrai ensuite. 44. 0414 Git Interactive Rebase: Attendez, parlons du rebasage interactif. Et pour cela, j' ai ramené le projet en une seconde à ce qu' il était auparavant. Avant d'effectuer l'opération de rebase. Permettez-moi de passer à une branche et d'effectuer le rebasage. Je veux faire un clic droit sur le dernier commit hors Master, cliquer sur rebaser la branche actuelle sur ce commentaire. Mais cette fois, je vais choisir cette option qui dit rebase interactive blonde dans un nouveau terminal. Cela revient à exécuter la commande git rebase avec dash, dash interact to option. Cliquez sur Oui pour rebaser. Cette fois, nous allons ouvrir l'éditeur de texte. Ici, vous allez voir la liste des détenteurs des commits qui font partie de la branche feature one. Ce que le rebasage interactif nous permettrait de faire, c'est que nous pouvons réellement effectuer de nombreuses personnalisations en fonction de nos besoins. Si vous voyez, nous avons un tas de commandes ici, que nous pouvons utiliser pour indiquer à git ce que nous voulons faire avec les commits ou pour utiliser une branche. Par défaut, cette commande est utilisée pick, ce qui signifie que nous voulons utiliser ce comité. Cela signifie essentiellement que nous voulons que ces comètes de la branche 1 soient candidates à l'opération de rebase. Mais vous pouvez remplacer cette commande par une autre en fonction de vos besoins. Par exemple, j'aimerais peut-être utiliser cette récompense de commande, qui signifie utiliser commit, mais ajouter le message de validation. Essentiellement, si vous souhaitez modifier le message, vous pouvez utiliser cette commande. Je voudrais changer le message de ce comité en particulier. Et faisons-le. J'aimerais utiliser cette commande drop. Pour supprimer ce commit en particulier. Je sais que ce commentaire va créer des conflits parce que nous avons édité le fichier txt point du produit dans ce commit. Je vais donc laisser tomber ça. De même, vous avez un tas d' autres commandes que vous pouvez utiliser. Vous pouvez simplement parcourir la description et voir s'ils correspondent à vos besoins. Enregistrez le fichier et fermez-le. Nous allons donc voir une autre invite nous demandant de chaîner le message de ce commit. Si vous vous souvenez de ce commit en particulier, nous avions utilisé la récompense de commande. C'est là que j'obtiens cela qui nous incite à enchaîner le message à autre chose. Vous pouvez le remplacer par ce que vous voulez. Bien sûr, ne dites pas blah, blah, tapez quelque chose de significatif. Je veux enregistrer le fichier et le fermer. Donc, cette fois, si vous remarquez que nous n'avons que cinq commits. Parce que nous avons supprimé l'un des commits dans la branche feature où nous avons apporté des modifications dans le fichier TXT point du produit. Et aussi pour l'autre fonction de commentaire, une branche changerait le message en blah, blah. Alors allez-y et essayez d'expérimenter le rebasage interactif. Je te verrai ensuite. 45. 0501 Git Rebase vs Merge: Parlons de git rebase. Git rebase est une sorte d'alternative à la fusion. Cela sert à peu près le même objectif qu'avec une opération de fusion. Cela étant dit, vous ne pouvez pas remplacer l'un par l'autre. Nous ne pouvons pas remplacer VBS par la fusion, et vice versa, nous ne pouvons pas remplacer la fusion par le rebase. Il a ses avantages et inconvénients et chacun a son propre objectif. C'est ce dont nous allons parler dans cette conférence et dans les deux prochaines conférences. Tout d'abord, essayons de comprendre ce qu'est exactement le rebase. En cas de fusion en trois étapes, demande GET de créer un commit de fusion dont l'instantané constituerait les modifications des deux branches. Bien que cela ne semble pas être un problème, nous commençons à y voir des problèmes, en particulier lorsque notre projet s' agrandit de plus en plus. Tout d'abord, la fusion créerait ce commit de fusion supplémentaire, ce qui pourrait être inutile. Deuxièmement, cela crée le problème de ce que l'on appelle l' historique des commits spaghetti. Si vous effectuez trop d' opérations de fusion dans votre projet. Voici à quoi pourrait ressembler l'historique de notre projet. Maintenant, si vous deviez jeter un œil à tous les commits historiques effectués , disons que vous avez exécuté commande git log dans la branche master. Tout ce que vous allez voir, c'est un tas de commits de fusion. Vous ne pouvez pas voir les modifications introduites dans les branches individuelles. Vous devez parcourir la hiérarchie parent pour pouvoir consulter toutes les modifications ou tous les commentaires relatifs à la branche. Cela va créer beaucoup de confusion. Rebus put résoudre ces problèmes que nous voyons avec les commits de fusion. Afin de comprendre comment fonctionnent exactement les remises, supposons que nous n'avons pas fusionné ces deux branches. C'est l' état actuel de notre projet. Supposons maintenant que je suis dans la branche feature one et que j'ai lancé la commande git rebase. Ce qui serait bon maintenant , c'est d'abord essayer de trouver l'ancêtre commun des deux branches, qui dans ce cas est N3 commit. Ensuite, il stockera temporairement toutes ces modifications introduites dans la fonctionnalité 1. Quelque part dans le dépôt. Il pointerait alors la branche feature one vers la pointe de la branche master, qui dans ce cas est m phi commit. Git réappliquera tous les commits stockés un par un. C'est ainsi que nous avons créé la branche AT MY commit et introduit toutes ces fonctionnalités qui conduisent à des changements dans la branche de fonctionnalité. Auparavant, notre fonctionnalité se ramifie à partir de M3 commit. Maintenant, après avoir exécuté la commande rebase, elle est maintenant rebasée sur m phi. Maintenant, en faisant cette opération, vous pouvez aussi bien voir des conflits. Nous pouvons les résoudre de la même manière que nous avions résolu des conflits en cas d'opération de fusion. Nous sommes allés voir un exemple de cela dans les prochaines conférences. Maintenant, si vous jetez un œil à ce diagramme, vous remarquez que nous pouvons réellement effectuer une fusion en avant rapide de cette façon. Devine quoi maintenant ? Aucun commentaire supplémentaire n'a été introduit. Les validations d'un allo sont linéaires avec une opération de fusion. Si vous avez eu ce problème d'historique des commits spaghetti avec rebase, nous avons un développement linéaire comme vous le voyez ici, ce qui nous permet de regarder plus facilement ce qui nous permet de regarder plus facilement l'historique des commits. Et si vous deviez exécuter la commande git log maintenant, vous verrez non seulement comment les modifications introduites dans la branche master, mais également tous les commentaires liés aux fonctionnalités manière linéaire. Maintenant, vous pensez peut-être que nous pouvons commencer à utiliser rebase et que nous n' aurions plus jamais à utiliser la fusion. Tu peux te tromper. Il existe certains scénarios où rebasage est la chose idéale à faire, et il existe d'autres scénarios où beaucoup est une meilleure option. Vous en saurez plus à ce sujet. 46. 0502 Performing Rebase in VS Code & Handling Conflits: Très bien, regardons un exemple de git rebase. Mais avant cela, laissez-moi vous expliquer l'état actuel de notre projet. J'ai créé un tout nouveau projet dans ce but et j'ai fait un tas de validations. Laissez-moi vous expliquer ce que j'ai fait exactement. Depuis la branche master dans le cadre du tout premier commit, je viens d'introduire ces fichiers TXT, l'inventaire administratif et les fichiers TXT point produit. Et dans chacun de ces fichiers, je viens d'ajouter quelques lignes de texte comme si nous avions écrit du code. Le commit suivant est également entré dans le master. Et avant cela, j' ai bien sûr créé une branche basée sur le tout premier commit. cadre du deuxième commit, comme le message nous le suggère, admin édite et master. Je viens d'ajouter une ligne de texte dans le fichier TXT admin point, comme ça. Ensuite, j'ai fait mon premier commit dans la branche de fonctionnalité et le message suggère des modifications d'inventaire à partir de la branche feature one. Je viens d'ajouter une ligne de texte dans le fichier inventé ou TXT. La prochaine fois, faites un commit dans la branche master. Et cette fois, j' ai ajouté une ligne de texte dans le fichier TXT point du produit. Et puis j'ai fait un autre commentaire dans la branche fonctionnalité où j'ai édité le fichier TXT point du produit. En bas de la ligne. Lorsque nous effectuons le rebasage, nous allons avoir des conflits dans fichier TXT point du produit car nous avons effectué un commit dans master où nous avons édité le fichier TXT point du produit, et la même chose est faite dans le branche de fonctionnalité également. La prochaine fois, créez une autre branche master engagée. Eh bien, ce n'est pas vraiment nécessaire pour que je l'explique, mais j'ai fait ce commentaire juste pour que le graphique ressemble à ce que nous voulons. Actuellement, cette ligne bleue représente la branche principale, tandis que la ligne rouge représente la branche de l'entité. Cependant, ce n'est peut-être pas toujours le cas. Quelle que soit la branche dans laquelle nous effectuons le dernier commit qui sera affiché en premier. Par exemple, si je devais créer une autre branche de fonctionnalité de commentaire, branche de fonctionnalité deviendrait bleue et la branche principale deviendrait rouge. Cela peut sembler déroutant. Et c'est pourquoi j'ai ajouté ce commit supplémentaire afin que la branche master apparaisse en premier, puis la branche feature. Maintenant, avant de poursuivre, il est vraiment important que vous compreniez ce qui se passe exactement et quels sont tous les changements que nous avons introduits dans chacun de ces commits. Je vais donc mettre ce projet à votre disposition pour que vous puissiez le télécharger. Vous pouvez simplement l'importer dans code Visual Studio et consulter la liste des modifications, comprendre, et ensuite seulement continuer. Sinon, vous allez commencer à vous embrouiller. Si tu es capable de suivre, c'est génial. Si ce n'est pas le cas, faites une pause, comprenez ce qui se passe ici, puis continuez à regarder. Comme vous pouvez le voir, la branche feature one est actuellement basée sur le tout premier commit sur la branche master. Nous voulons maintenant rebaser la fonctionnalité d' une branche vers la dernière branche master de validation. Comment faisons-nous cela ? Eh bien, cliquons avec le bouton droit sur le tout dernier commit, la branche master. Et puis nous avons cette option appelée rebaser la branche actuelle sur ce commit. La branche actuelle est la branche principale. Quand passer à la branche de fonctionnalité. Et nous savons que nous avons poussé pour inclure une branche parce que ce cercle ici pointe vers une branche auparavant, il pointait vers la branche principale. Maintenant, cliquons avec le bouton droit sur la dernière validation la branche master et choisissons cette option qui dit rebaser la branche actuelle. Sur ce point, les branches actuelles comportent une branche. Et cela devrait idéalement rebaser, sauf si nous avons des conflits. Bien sûr, nous allons voir des conflits car comme je l'ai déjà mentionné, nous avons édité le fichier TXT point du produit dans les deux branches. Cliquons donc sur rebaser. Comme vous pouvez le constater, nous sommes en conflit. Laissons tomber cela. Eh bien, nous devrions idéalement voir ces fichiers avec des fichiers complexes, laissez-moi rafraîchir. Et voilà, vous l'avez. Vous pouvez résoudre les conflits comme vous le souhaitez. Dans mon cas, je veux simplement accepter les deux modifications. Enregistrez le fichier. Ensuite, je vais appuyer sur cette icône plus pour mettre en scène ce fichier. Ensuite, je peux cliquer sur cette icône de vérification pour procéder à l'opération de rebase. Et le message qui est renseigné par défaut ici est le message de la fonctionnalité de commentaire, une branche qui crée réellement le conflit. Nous avons ouvert cet éditeur. Mais je vais juste laisser le message tel quel, fermer le dossier. Et cela devrait terminer l'opération de rebase. Comme vous pouvez le voir, les quatre premiers commits sont hors branche master et les deux autres commentaires appartiennent à la branche feature. Nous pouvons maintenant procéder à la marche rapide. Je vais donc revenir à la branche master. Cliquez droit sur ce commit. Ensuite, je peux choisir de fusionner dans la branche actuelle. Je veux donc fusionner la branche feature one dans la branche master. Je ne veux pas créer un nouveau commit pour la fusion rapide. C'est ainsi que vous effectuez le rebasage. Et si vous remarquez, nous avons ce développement linéaire, ce que nous attendons avec rebase. Je te verrai ensuite. 47. 0503 Git Rebase dans Git Bash Sauter les conflits et avorter le Rebase: Très bien, voyons comment nous pouvons exécuter git rebase à partir de Git Bash. Actuellement, nous sommes dans la branche master pour passer à une branche afin de pouvoir exécuter cette commande. Et d'ailleurs, nous avons ramené le projet à son apparence au début de notre vidéo précédente. Pour que nous puissions refaire les choses et voir comment cela fonctionne depuis Git Bash. Je vais passer à la branche Feature. Il peut observer simultanément ce qui se passe dans ce graphique. Rebase Git. Où est-ce que je veux rebaser pour effectuer un commit ? Cette branche principale pointe vers quelqu'un qui dit Maître. Et comme vous pouvez vous y attendre, nous allons voir les conflits. Allons-y et dissolvez-les. À mon avis, encore une fois, je n'accepterais pas les deux modifications, sauvegarderais le fichier et retournerais à Git Bash, allé préparer ce fichier, git add product dot fichier TXT. Ensuite, nous devons exécuter cette commande. Git rebase, tiret, trait d'union continue à effectuer le rebasage. Et c'est exactement ce que je vais faire. Vous avez également la possibilité d'ignorer. Si vous exécutez cette commande, git ignorera simplement le commit à l' origine des conflits. C'est comme si vous n'aviez pas créé la branche de fonctionnalité de commentaire l'origine des conflits. Si vous exécutez cette commande, peut-être après avoir réussi le rebasage, vous souhaiterez peut-être réappliquer toutes ces modifications manuellement. Cependant, puisque nous avons résolu le problème, vous n'avez pas besoin d' utiliser cette option, mais n'hésitez pas à l' expérimenter. Une fois que j'ai exécuté cette commande. Encore une fois, cela va nous montrer le message. Nous pouvons le garder tel quel. Ou si vous souhaitez le modifier, vous pouvez le modifier. Fermons. Comme vous pouvez le voir ici, nous avons rebasé notre branche feature avec la branche master. Passons maintenant à la partie fusion, que nous allons revenir à master git fonctionnalité master git merge 1. Et comme vous pouvez le voir, les deux branches sont appariées. Si c'est un os de la commande git log maintenant, vous allez voir tous les commits introduits dans les deux branches de manière linéaire, ce dont nous avons besoin. Et au fait, une opération de rebase performante. Et pour une raison quelconque, vous avez décidé de l'abandonner, alors vous pouvez utiliser cette option, git rebase, trait d' union, tiret que j'ai acheté. Je te verrai ensuite. 48. 0504 Git Interactive Rebase: Attendez, parlons du rebasage interactif. Et pour cela, j' ai ramené le projet en une seconde à ce qu' il était auparavant. Avant d'effectuer l'opération de rebase. Permettez-moi de passer à une branche et d'effectuer le rebasage. Je veux faire un clic droit sur le dernier commit hors Master, cliquer sur rebaser la branche actuelle sur ce commentaire. Mais cette fois, je vais choisir cette option qui dit rebase interactive blonde dans un nouveau terminal. Cela revient à exécuter la commande git rebase avec dash, dash interact to option. Cliquez sur Oui pour rebaser. Cette fois, nous allons ouvrir l'éditeur de texte. Ici, vous allez voir la liste des détenteurs des commits qui font partie de la branche feature one. Ce que le rebasage interactif nous permettrait de faire, c'est que nous pouvons réellement effectuer de nombreuses personnalisations en fonction de nos besoins. Si vous voyez, nous avons un tas de commandes ici, que nous pouvons utiliser pour indiquer à git ce que nous voulons faire avec les commits ou pour utiliser une branche. Par défaut, cette commande est utilisée pick, ce qui signifie que nous voulons utiliser ce comité. Cela signifie essentiellement que nous voulons que ces comètes de la branche 1 soient candidates à l'opération de rebase. Mais vous pouvez remplacer cette commande par une autre en fonction de vos besoins. Par exemple, j'aimerais peut-être utiliser cette récompense de commande, qui signifie utiliser commit, mais ajouter le message de validation. Essentiellement, si vous souhaitez modifier le message, vous pouvez utiliser cette commande. Je voudrais changer le message de ce comité en particulier. Et faisons-le. J'aimerais utiliser cette commande drop. Pour supprimer ce commit en particulier. Je sais que ce commentaire va créer des conflits parce que nous avons édité le fichier txt point du produit dans ce commit. Je vais donc laisser tomber ça. De même, vous avez un tas d' autres commandes que vous pouvez utiliser. Vous pouvez simplement parcourir la description et voir s'ils correspondent à vos besoins. Enregistrez le fichier et fermez-le. Nous allons donc voir une autre invite nous demandant de chaîner le message de ce commit. Si vous vous souvenez de ce commit en particulier, nous avions utilisé la récompense de commande. C'est là que j'obtiens cela qui nous incite à enchaîner le message à autre chose. Vous pouvez le remplacer par ce que vous voulez. Bien sûr, ne dites pas blah, blah, tapez quelque chose de significatif. Je veux enregistrer le fichier et le fermer. Donc, cette fois, si vous remarquez que nous n'avons que cinq commits. Parce que nous avons supprimé l'un des commits dans la branche de fonctionnalité où nous avons apporté des modifications dans le fichier TXT point du produit. Et aussi pour l'autre fonction de commentaire, une branche changerait le message en blah, blah. Alors allez-y et essayez d'expérimenter le rebasage interactif. Je te verrai ensuite. 49. 0505 Rebase à un commit spécifique ou à une autre branche de fonctionnalité: Dans cette vidéo, nous allons voir comment nous pouvons nous rebaser sur un commit particulier. Nous n'avons pas nécessairement besoin rebaser sur la pointe d'une branche. Nous pouvons également nous baser sur un commit particulier. Actuellement, une branche est basée sur le tout premier commit de la branche master, mais je peux la rebaser sur la seconde branche master. Dans Visual Studio Code, je dois basculer vers cette branche, que je souhaite rebaser. Je choisis une branche. Une fois cela fait, je vais faire un clic droit sur le commit où je voudrais reconstruire la fonctionnalité une branche deux. Et puis je peux choisir cette option qui dit rebaser la branche actuelle sur ce commit. Si vous deviez faire la même chose depuis le Git Bash ici pour activer rapidement une branche. Ensuite, vous allez dire git rebase. Et puis le HashCode du commit sur lequel vous souhaitez rebaser. Dans ce cas, il s'agira du deuxième commit de la branche master. Je vais copier les premiers caractères de ce commit, comme ça. Retournez dans Git Bash, collez-le ici. Et cela devrait maintenant rebaser une branche à ce commentaire. Eh bien, ce diagramme n'a peut-être pas l'air si évident. Mais si vous remarquez, nous avons la branche feature one, qui est basée sur la seconde branche master commit off. Ces deux commits qui appartenaient à la branche master ne font pas partie de la branche feature one. Comme prévu, le graphique serait plus évident si nous faisions un autre commentaire dans la branche master. Alors faisons-le très rapidement. Je vais revenir à la branche principale. Je vais juste ajouter une ligne de code, fichier produit, enregistrer le fichier. Revenons ici et validons ces modifications dans la branche master avec le message. Maintenant, si vous revenez au graphique, nous avons la branche principale en bleu et la branche entité en rouge. Mais si vous remarquez que les branches de fonctionnalités sont maintenant basées sur le deuxième commentaire sur la branche master, parce que nous l'avons rebasée sur cela. Et nous ne devons pas nécessairement toujours rebaser sur la branche master. Nous pouvons également utiliser au mieux une branche particulière vers une autre branche qui n' est pas une branche principale. Laissez-moi vous montrer ce que je veux dire. Tout d'abord, créons une nouvelle branche. Mais cette fois, au lieu de créer une branche au bout de la branche master, je vais le faire à ce commit particulier. Et oui, nous pouvons également créer de nouvelles branches basées sur un commit particulier. Je peux simplement cliquer avec le bouton droit sur le commit à partir duquel je souhaite créer une branche. Ensuite, cliquez sur Créer une branche, entrez le nom de la branche, et c'est bon. Mais voyons comment nous pouvons faire de même avec Git Bash. Permettez-moi de passer à master, par exemple, git branch, puis au nom de la branche que vous souhaitez créer. Appelons ça la fonction deux. Ensuite, vous allez spécifier cette entrée en fonction de ce que vous souhaitez créer cette branche. Je vais copier les premiers caractères de cet objet de validation. Retournez dans Git Bash, collez-le ici. En fait, si vous exécutez cette commande, vous n'aurez pas vraiment à passer aux marques principales. Vous pouvez l'exécuter depuis n' importe quelle autre branche. Nous avons donc créé une branche basée sur ce combat particulier. Et vous pouvez voir cette branche ici. Faisons un commit dans cette branche. Pour cela, laissez-moi passer à la branche feature two. Accédez peut-être à une fiche produit. Le produit passe d'une fonctionnalité à une autre. Enregistrez le fichier. Et nous allons valider ces changements dans la fonctionnalité dans la branche. Si vous remarquez, la première ligne représente l' entité à brancher, et elle est basée sur le troisième commit de la branche principale. C'est donc FY21 be hash, que nous avons saisi précédemment. Ensuite, cette ligne rouge représente la branche principale, vert représente la branche de l' entité une. Si vous voulez que ce graphique soit plus évident, faisons un commit dans la branche master. Encore une fois. Nous allons valider ces modifications avec le message. Si vous revenez au graphique, vous verrez que nous avons la branche master, la branche feature de la branche feature un qui est basée sur le deuxième commit et la branche feature deux qui est basée sur la troisième. commentaire. Passons maintenant à la lecture de la meilleure fonctionnalité d' une branche jusqu'à la pointe de la fonctionnalité à branche. Passons d'abord à une branche. Ensuite, je vais faire un clic droit sur ce commit. Rebaser la branche actuelle sur ce comité. Nous sommes en conflit. Laissez-nous les résoudre rapidement. Acceptez les deux modifications enregistrées dans le fichier, restez le fichier. Puis il s'est engagé. Cela devrait ouvrir un éditeur. Il suffit de le fermer. Et cela terminerait l'opération de rebase. Encore une fois, le graphique peut ne pas avoir l'air donc il faut évidemment faire un commentaire de plus. Dans la branche principale. Je vais revenir à la branche principale, au point TXT du produit et ajouter simplement une ligne de code supplémentaire. Je vais utiliser le même texte que le message de validation. Et validons à ce stade, si vous remarquez que la première ligne représente la branche master. Mais le point ici est que nous avons pu rebaser la fonction d' une branche à l'extrémité de la fonction vers la branche. Donc ces deux commits appartenaient à pitcher one branch qui sera simplement rebasé pour présenter deux branches. Maintenant, si vous le souhaitez, vous pouvez simplement fusionner ces deux branches et ces deux branches et supprimer l'une d'entre elles ou faire quoi que ce soit. Si vous voulez faire la même chose à partir de Git Bash, vous pouvez simplement revenir à la branche feature one, git rebase, feature two. Et cela devrait rebaser votre fonctionnalité sur branche à la pointe de la fonctionnalité vers la branche. Puisque nous l'avons déjà fait, je n'ai pas besoin d' exécuter cette commande. Mais j'espère que tu as compris. Alors allez-y, expérimentez cela, jouez avec tout ce dont je viens de parler. Si vous ne pratiquez pas, tout ressemblera à des pays et par la suite, vous commencerez à être frustré. On se voit ensuite. 50. 0506 Quand utiliser rebase et quand utiliser Merge usecases: Donc, rebasez ou fusionnez. Parlons-en. Imaginez qu'il s'agit de l'état actuel de votre projet. Vous avez créé une branche de fonctionnalité ou le tout premier commit sur la branche master. Ensuite, vous avez un tas de validations effectuées dans la branche master après la création de la branche feature. Disons maintenant que, pour une raison quelconque, vous réalisez que vous êtes trop tôt pour créer cette branche. Vous aviez peut-être besoin de certaines des modifications introduites dans branche master après la création de la branche feature. Devine quoi ? Vous pouvez simplement rebaser la branche feature un commit spécifique qui est venu par la suite, sorte que vous aurez toutes ces modifications dans la branche master, qui serait disponible dans la branche feature. Il s'agit d'un cas d'utilisation dans lequel vous pouvez utiliser le rebasage au lieu d'une fusion. Un autre cas d'utilisation hors rebase. Supposons que vous ayez créé quelques branches comme vous le voyez ici. Maintenant, supposons que vous avez réalisé que ces deux branches ne sont pas censées se trouver dans deux branches différentes. Ils peuvent résoudre le même problème ou appartenir à la même fonctionnalité. Peut-être aimeriez-vous qu'ils fassent partie d'une seule succursale. Devine quoi ? Vous pouvez simplement rebaser l'une des branches avec l'autre, comme ça, et c'est parti. Cependant, dans certains scénarios le rébus n'est pas la meilleure option. Rebasez-vous, vous modifiez et réécrivez la bonne histoire. Chaque fois que vous rebasez, vous réécrivez les objets Comment pointant vers un parent différent. Ce n'est pas le cas de grand-chose. Vous allez conserver l'historique des validations et quitter la fusion. Et c'est la raison pour laquelle vous devriez éviter d'utiliser rebase. Si plusieurs développeurs travaillent sur une même branche. Par exemple, imaginez que nous ayons un B2 plus terne et plus terne, puis que nous ayons également le référentiel centralisé. Il s'agit de la structure actuelle du projet. Dans tous ces endroits, nous avons la branche master avec quelques commentaires et la branche feature avec un seul commit. Maintenant, supposons que le dollar par personne a été rebasé sur un engagement différent. Cela ne sera pas reflété dans tous les autres systèmes. Par exemple, tous les autres développeurs, et même dans le référentiel centralisé. Maintenant, pour faire court, cela va créer de nombreuses incohérences et pourrait détruire le but même de notre rebase, qui est d'avoir un historique des commits propre. En règle générale, rappelez-vous simplement si vous êtes le seul à travailler sur une branche particulière, une branche de fonctionnalité, disons que nous pouvons ensuite utiliser rebase avant de pousser ce code dans le référentiel centralisé. Si plusieurs développeurs sont impliqués et qu'ils contribuent tous à la même branche. Puis fusionne l'option pour vous dans ce cas. Je te verrai ensuite. 51. 0601 Qu'est-ce que le stashing C'est un exemple de stashing: Parlons de la mise en réserve. Laissez-nous travailler actuellement sur les modifications liées à la première fonctionnalité. Je suis donc actuellement dans la branche vedette un. Alors que je travaille encore sur ce sujet, mon patron vient à mon bureau et m'a demandé de continuer à travailler sur la deuxième fonctionnalité et de la livrer d'abord avant de travailler sur la première, peut-être que ce client est impatient en attente de fonctionnalité aussi. Maintenant, dans l'espoir d'une évaluation, je pourrais dire oui à mon patron et je ne voudrais pas commencer à travailler sur une fonctionnalité. Mais que se passe-t-il si j'ai des modifications non validées dans la fonctionnalité 1 ? Permettez-moi d' aller de l'avant et d'apporter quelques modifications à l'un de ces fichiers. Comme si j'introduisais quelques changements liés à la première fonctionnalité. Je vais simplement ajouter une ligne de texte, ainsi , enregistrer le fichier et le fermer. Permettez-moi de revenir à Git Bash. Nous avons donc introduit quelques modifications pour la première fonctionnalité. Et puis je voulais maintenant travailler sur la fonctionnalité pour me permettre de passer de la fonctionnalité à la branche. Je suis donc actuellement en fonction de la branche. Maintenant, si j'ouvre ce fichier admin point TXT, verriez-vous les modifications que je viens d'introduire ? Laissez-nous y jeter un œil. Vous constatez toujours ces changements. En effet, entre les branches, vous emporte toutes ces modifications non validées. Ce sont les modifications qui sont liées à la fonctionnalité 1. Et je peux le voir même après être passé à la deuxième fonction. Pourquoi est-ce un problème ? Eh bien, lorsque vous travaillez sur des modifications liées à une fonctionnalité, cela peut en fait créer beaucoup de confusion, en particulier lorsque vous essayez de mettre en scène tous les fichiers liés à la fonctionnalité 2. Vous pouvez rencontrer des changements liés à la première fonctionnalité et vous risquez de vous embrouiller. Quelle est donc la solution ici ? Une solution consiste évidemment à valider les modifications liées à la fonctionnalité 1 avant de passer à la branche feature two. Mais ce n'est pas une solution, car nous n'en avons pas fini avec les modifications apportées à la fonctionnalité 1. Eh bien, qu'en est-il de la fonctionnalité qui nous permet de stocker temporairement toutes nos modifications non validées quelque part dans le référentiel ? nous permet de stocker temporairement toutes nos modifications non validées Ensuite, nous serions en mesure de les récupérer quand nous le voulons. C'est exactement ce qui se cache dans Git. Je suis actuellement dans une future agence. Donc, avant de passer à deuxième fonctionnalité et de commencer à travailler dessus, j'aimerais cacher toutes nos modifications non validées. La commande pour cela est bonne. Planque. Désormais, cette commande ne cachera que les fichiers suivis par défaut. Pour créer un fichier suivi par Git. Comme vous le savez peut-être déjà, nous devons le mettre en scène au moins une fois. Donc, si nous avons un tout nouveau fichier qui n'a jamais été mis en scène auparavant, nous ne pouvons pas le stocker. Si vous voulez également stocker tous ces fichiers non suivis, Inuit inclut une option. Inclure un trait d'union non suivi. Besoin d'exécuter cette commande avec cette option afin que les modifications mises en scène et les modifications mises en scène, même les nouveaux fichiers qui ne sont jamais traités auparavant, soient cachés. Sinon, le raccourci pour cette option est simplement d'utiliser le trait d'union nouveau. Actuellement, nous n'avons aucun fichier non suivi de toute façon. Nous voyons donc un message indiquant Répertoire de travail enregistré et date d'index. Wip représente la progression du travail sur la branche de la fonctionnalité 1. Et il pointe vers le dernier commit de la branche feature one, qui signifie que cette commande a caché les modifications qui sont venues après le dernier commit, cette branche. Maintenant, si vous ouvrez le fichier TXT admin point, vous ne verrez plus toutes ces modifications car elles sont juste cachées. Nous sommes maintenant libres de passer à la fonctionnalité deux branches. Et ici, je travaille sur la fonctionnalité des modifications connexes ou je fais un tas de validations. Et une fois que j'en aurai fini, je pourrai à nouveau revenir au premier long métrage. Et je peux récupérer toutes ces modifications cachées avec la commande git stash, pop. Exécutons cette commande. La bonne commande pop. Après avoir récupéré toutes ces modifications non validées, il les supprimera du magasin temporaire. Mais en coulisse, il a essentiellement créé un objet commit, et c'est le HashCode qui en est issu. Et cet objet de validation ne fera partie d'aucune branche. L'historique est juste un objet de validation temporaire créé avec son instantané juste dans le but de le stocker. Et comme vous pouvez le voir sur cette ligne, cet objet commit a été supprimé. Si vous ouvrez le point administrateur TXT maintenant, vous pouvez à nouveau voir toutes les modifications qui étaient précédemment cachées. Il existe d'autres cas d'utilisation où il est caché peut s'avérer utile. Nous les exporterons lors nos prochaines conférences. Je te verrai ensuite. 52. 0602 Appliquer le stock dans plusieurs succursales: Il peut arriver un moment ou un cas d' utilisation où vous devrez appliquer les mêmes modifications à plusieurs branches. Dans ce cas, git stash pop ne sert pas à ses fins. Quand utiliser git stash, demandez-en de même. Laissez-moi vous montrer ce que je veux dire. Je suis actuellement dans une branche future et nous avons certaines modifications non validées. Permettez-moi de revenir à Git Bash et de cacher toutes ces modifications non validées. Nous en avons donc fait une copie de sauvegarde et nous n' plus pu voir ces changements. Maintenant, faisons git, stash, appliquons. Et voyons ce que ça va donner. Une fois de plus, good a ramené toutes ces modifications non validées depuis le magasin temporaire. Mais cette fois, il n'a pas supprimé toutes ces modifications du magasin temporaire comme il l' a fait dans gas off git stash pop. Ce qui signifie que nous pouvons également appliquer ces modifications dans une autre branche. Mais avant cela, permettez-moi de valider tous ces changements. Supposons que j'ai terminé toutes les modifications liées à la fonctionnalité 1. Commencez par préparer ces fichiers, puis validez les modifications. Permettez-moi maintenant de passer à la fonctionnalité git stash à deux branches. Je peux maintenant exécuter la commande apply pour appliquer toutes ces modifications cachées. Encore une fois, nous n'avons pas tous ces changements à l'avenir pour la branche. Mais une fois que j'ai exécuté cette commande, vous allez voir ces modifications ici. 53. 0603 Résoudre un stash spécifique: Voyons comment nous pouvons jeter un œil à la liste des caches et être en mesure de récupérer une réserve spécifique ? Oui, c'est possible. Laissez-moi vous montrer ce que je veux dire. Afin de mieux expliquer cela, j'ai une fois de plus ramené le projet à ce qu'il était au début de ce chapitre. Donc, en gros, nous n'avons aucune réserve. Je suis dans la première branche. Permettez-moi de modifier l'un des fichiers. Permettez-moi simplement d' ajouter une ligne de texte, comme ça, enregistrez le fichier, fermez-le, revenez à Git Bash et laissez-nous stocker ces modifications. Revenez en arrière et ouvrez le fichier. ne verrais plus tous ces changements parce qu'ils étaient juste cachés. Permettez-moi d'ajouter une ligne de texte supplémentaire, ainsi, enregistrez le fichier, fermez-le. Laissez-moi également planquer ces modifications. Maintenant, nous avons fait du stashing plusieurs fois, et cela a dû être conservé quelque part dans le dépôt. Comment y jeter un œil ? La commande pour cela est git stash list. Cela serait listé sur toutes les listes de cachettes. Nous pouvons récupérer une réserve spécifique en utilisant son identifiant. Mais si vous remarquez, le message est ici ne sont pas très descriptifs. Ce n'est que le dernier commit sur la branche feature one et le même que celui utilisé pour toutes les stashes. Maintenant, au fil du temps, au fur et à mesure que vos réserves augmentent, il peut être difficile d' identifier quelles sont les modifications apportées ? Heureusement, git nous permet de donner un message descriptif pendant le stockage. Permettez-moi donc de modifier un autre fichier. Peut-être inventé ou TXT comme ça. Et je vais faire de même pour la fiche produit. Sauvegardez-le et fermez-le. Je viens donc de faire des modifications et quelques fichiers. Permettez-moi de cacher ces modifications, mais cette fois, je vais vous donner un message descriptif. Enregistrer est l'option que nous devons utiliser et vous allez envoyer un message, quelque chose comme ça. Nos modifications sont cachées. Pour jeter un œil à la liste des réserves. Vous allez maintenant voir un message descriptif. Maintenant laisse-moi essayer de récupérer cette cachette en particulier. Encore une fois, nous pouvons soit afficher les modifications appliquées, soit les modifications. Permettez-moi d'appliquer les modifications. Je voulais préciser l'idée de la cellule de cachette. Vous pouvez voir que les modifications ont été récupérées et sont appliquées. De même, nous pouvons également récupérer cette réserve particulière. Et nous allons voir ces changements dans le fichier TXT admin point. Mais voyons ce qui se passerait si je devais récupérer cette réserve particulière où nous avons édité exactement le même fichier. Cette opération, je dois vraiment échouer. Et bien sûr, nous avons une flèche qui indique que vos modifications locales apportées aux fichiers suivants seraient écrasées par la fusion. Veuillez valider vos modifications avant de les fusionner. Donc, en gros, ce Stash va réagir aux changements qui pourraient entrer en conflit avec nos modifications non validées existantes. Alors, à quoi sert la solution ? La solution est déjà fournie ici. Nous pouvons valider toutes ces modifications ou les stocker une fois de plus, puis récupérer cette réserve particulière. Ou bien, nous pouvons simplement utiliser la commande git restore point pour effacer toutes les modifications non validées. De cette façon, nous devrions pouvoir récupérer une réserve spécifique sans aucun problème. Mais nous avons également perdu tous les changements. Nous allons parler de la façon dont nous pouvons gérer les conflits pendant le stockage. Quand nous parlerons de git pull dans les chapitres suivants. Je te verrai ensuite. 54. 0604 Mettre fin aux changements sélectifs et les récupérer Comprendre Hunk: Il n'est pas nécessaire que nous ayons à stocker toutes les modifications. Nous pouvons également être sélectionnés pour demander d'arroser toutes les modifications que nous voulons stocker et celles que nous ne voulons pas stocker. Et encore une fois, pour le bien de cet exemple, j'ai ramené le projet à ce qu'il était au début de ce chapitre. Nous n'avons donc aucune réserve pour le moment. Permettez-moi de modifier quelques fichiers. Comme ça. J'ai enregistré le fichier. Mais cette fois, cachons les modifications partielles. Cette fois, je vais utiliser l'option tiret P signifie partiel. Et voyons ce que cela nous permet de faire. Cela nous a fourni un tas d'options. Si vous ne savez pas en quoi consistent ces options, vous pouvez simplement saisir un point d'interrogation et vous pourrez voir une description de celui-ci. Donc, en gros, cette commande vous demandera toutes les modifications que nous avons apportées une par une. Et nous pouvons dire ce qu'il faut faire de ces changements en fonction de cette liste d'options. Donc, actuellement, il pointe vers ce changement particulier appartenant au fichier TXT de point d'inventaire. Si on tape y, ça va planquer le beau gosse. Vous pouvez considérer Hunk comme un changement qui est présenté ici. Il s'agit donc d'une nouvelle ligne de textes qui viendrait d'être ajoutée. Si vous tapez N, cela signifie que vous ne voulez pas l'inclure dans stash. Cela signifie que vous ne voulez pas cacher ces modifications. Q comme dans quipped, ne planquez pas ce morceau ni aucun des autres. Mais quels sont tous les mecs que vous avez peut-être dit oui à ce qui est encore caché en arrêtant de fumer. Essentiellement, nous allons quitter cette opération tout en cachant toutes les modifications auxquelles nous avons dit oui ici signifierait planquer ce morceau et tous les morceaux suivants dans le fichier. Dans le même dossier. D signifierait qu'ils ne sont pas cachés ce morceau ou aucun des derniers morceaux dans le fichier, c'est l'opposé de l'option a. Il voudrait dire éditer manuellement le morceau actuel. C'est quelque chose que nous n'utiliserons jamais. Personnellement, je ne l'ai jamais utilisé. Je ne pense pas à un cas d' utilisation pour utiliser ceci. En gros, si nous voulons modifier quoi que ce soit, nous préférons le faire en marchant dans un arbre, puis en cachant les modifications. Supposons que j' aimerais cacher ces modifications. Je vais donc dire y ici. Ensuite, il va nous demander le deuxième morceau, qui appartient au fichier point TXT du produit. Et voici les changements. Disons que je ne veux pas planquer quelqu'un pour dire non à ça. Laissez-nous faire git restore point pour simplement nettoyer notre répertoire de travail. Appelons-le avec cette commande. Nous supprimons toutes ces modifications non validées. Laissez-moi essayer de réappliquer cette réserve. Cette commande appliquerait simplement la dernière réserve que nous avons dans la liste. Mais avant d'exécuter cette commande, assurons-nous que nos modifications sont perdues. Comme vous pouvez le constater, nos changements ne sont pas là. Mais une fois après avoir exécuté cette commande, nous allons voir les modifications appliquées dans le fichier TXT de point d'inventaire. Parce que ce beau gosse était planqué. Où est-ce que dans le fichier TXT point du produit, nous ne voyons aucun changement. Je te verrai ensuite. 55. 0605 Explorer le plan d'établissement dans le code VS Supprimer un plan d'établissement: Voyons maintenant comment nous pouvons effectuer le stockage de Visual Studio Code. Et encore une fois, dans ce but, j'ai ramené le projet à ce qu'il était au début de ce chapitre. Et nous n'avons actuellement aucune réserve. Allons-y et apportons des modifications à deux de ces fichiers. Peut ajouter une ligne de texte comme un fichier TXT de point d'administration. Et laissez-moi faire la même chose dans le fichier TXT de point d'inventaire , enregistré le fichier. Passons au Contrôle de source. Cliquez sur ces trois points et vous verrez l'option pour effectuer le cachet. Vous trouverez donc ici une routine que nous avons apprise jusqu'ici dans ce chapitre. Nous pouvons jouer Stash. Stash, qui inclut également les fichiers non suivis. Nous pouvons appliquer la dernière réserve. C'est aussi bon que nous exécutons la commande git stash apply. Ou nous pouvons choisir cette option qui dit appliquer la réserve. Ensuite, nous pouvons choisir celle des caches sauvegardées. Allons-y et planquons. Il nous demande de saisir un message, laisser Center ou quelque chose comme ça, d'appuyer sur Entrée. Cela a donc dû enregistrer les modifications. 1 seconde, allons planquer. Nous pouvons cliquer sur Appliquer la cachette des lettres, ou nous pouvons choisir cette option qui dit une cachette plus. Ensuite, nous pouvons choisir la réserve que nous aimerions appliquer. Actuellement, nous n' avons qu'une seule réserve et nous disons qu'elle est en train d'être affichée. Si nous avions une liste de caches, celles-ci seraient également affichées. Permettez-moi de cliquer dessus. Et comme vous pouvez le constater, les modifications pour le moment s'appliquent à ces deux fichiers. Voyons quelles sont les autres options qui s'offrent à nous. Nous avons également la possibilité d'afficher la dernière réserve, d'afficher une réserve spécifique. Ou nous pouvons même laisser tomber ce tiret ou toutes les réserves. Essentiellement drop signifierait supprimer une cachette. Cela est similaire à l'exécution de la commande git stash drop. Ensuite, vous allez spécifier cet identifiant de tableau de bord. Ou vous pouvez simplement dire git stash, clear. Et cela supprimerait toutes les cachettes. Nous pouvons soit le faire à partir d' ici, soit nous pouvons également exécuter la commande. Laisse-moi exécuter la commande. Maintenant. Si je fais git stash list, vous ne verrez rien car nous venons de tout supprimer. Mais c'est ainsi que vous utilisez le stashing dans Visual Studio Code. Je te verrai ensuite. 56. 0701 Git Ignore et c'est une importance (cours de crash): Parlons du gitignore et de sa signification. Il se peut que vous ne souhaitiez pas valider certains fichiers ou que vous ne souhaitiez pas qu'ils soient disponibles pour que d'autres puissent les télécharger et les utiliser. quelques exemples de tels fichiers. Il se peut que des fichiers journaux soient générés pendant l'exécution. Et évidemment, nous ne voulons pas les valider et les rendre disponibles dans un dépôt centralisé pour que d'autres puissent les télécharger. De même, nous pouvons avoir compilé du code comme fichiers de classe point ou des fichiers point p-y, C, etc. Ou vous pouvez avoir des dossiers de dépendance locaux tels que modules Node dans le cas de projets hors nœud. Mais nous pouvons ignorer ces fichiers simplement en ne les mettant pas scène et en ne les validant pas. Mais il peut arriver que des personnes aient tendance à commettre accidentellement certains de ces fichiers, créant ainsi un gâchis qui n'est pas prévu. Le fichier gitignore est donc très pratique. fichier Gitignore vous permettra de spécifier certains modèles. Et tous les fichiers et dossiers qui correspondent à ces modèles seraient ignorés pour la mise en scène ou l'adaptation. Si vous essayez de rester en tant que fichiers qui correspondent à ces modèles spécifiés dans le fichier à ignorer par points, vous verrez une erreur. Jetons un coup d'œil à quelques exemples de tels modèles. Lorsque vous dites « star dot log » par exemple, star est considéré comme un caractère générique. Cela signifie que vous pouvez avoir n'importe quel fichier votre dépôt ou de votre projet avec n'importe quel nom. Tant qu'il a l'extension dot log, ces fichiers seront ignorés. Voici donc quelques exemples de fichiers qui seraient ignorés lorsque vous avez ce modèle spécifié dans le fichier ignore doute. Nous avons ajouté dot log dans le répertoire racine , puis info dot log sous le dossier logs. Ces deux fichiers seraient ignorés. Regardons un autre exemple de modèle. Nous avons des poumons tranchés. Lorsque vous spécifiez une barre oblique, cela signifie un répertoire. Ce modèle ignorerait essentiellement tout le contenu, y compris les sous-répertoires de tous les dossiers portant le nom logs. Voici quelques exemples de fichiers qui seraient ignorés avec ce modèle. Mettez la vidéo en pause, prenez une seconde et essayez de comprendre cela. Tous ces fichiers appartiennent au répertoire Logs. Tous ces fichiers seraient donc ignorés. Nous ne pouvons pas les mettre en scène, donc nous ne pouvons même pas les atteindre. Supposons que vous ayez cette structure de projet. En général, nous avons tendance à avoir un fichier ignorant un point et qui irait dans le répertoire racine du projet. Cependant, cela ne vous empêche pas d'avoir des fichiers à ignorer les points dans les sous-répertoires également. Le fichier à ignorer par points et ses modèles sont appliqués au dossier dans lequel il se trouve, y compris ses sous-dossiers. Ainsi, tous les motifs du fichier ignorant les points résidant dans un sous-dossier ne sont applicables que sur un sous-dossier. Et tous ses sous-répertoires, y compris tous les fichiers. Mais cela ne s'applique pas à son dossier parent, qui dans ce cas est le dossier de mon application. Dans certains cas, vous pouvez avoir des conflits de modèles. Par exemple, nous pouvons avoir un motif qui peut être en conflit dans ces deux fichiers ignorant les points. Dans ce cas, les motifs du sous-dossier auront une priorité plus élevée sur les modèles du dossier de mon application. Nous allons maintenant examiner un exemple de cela. Et ainsi, vous aurez une meilleure clarté. Si vous avez des modèles qui ne s'appliquent pas à l'ensemble de l'équipe, mais qui ne s'appliquent qu' à votre inscription locale. Vous pouvez mentionner la partie en masse du fichier d'exclusion. Et le fait que ce fichier appartient au dossier point git signifie que cela ne peut pas être aggravé ou que vous ne pouvez pas valider ces modifications. Et pour tous les modèles applicables à l' ensemble de l'équipe, c'est un fichier à ignorer les points qui entrerait en image et il est versionné, ce qui signifie qu'une fois que vous effectuez une mise à jour dans le fichier à ignorer par points, vous devez les valider et envoyer toutes ces modifications dans le dépôt centralisé afin que tout le monde télécharge le fichier Dart ignore. Et tous les modèles de fichiers de ce fichier seraient ignorés pour tout le monde. Personne ne serait donc en mesure de valider tous ces fichiers qui ne sont pas destinés à être partagés au sein de l'équipe. Vous pouvez également spécifier des modèles globaux applicables à tous les projets qui sont à tous les projets qui sont référentiels dans votre inscription locale. Vous pouvez le faire en exécutant la commande que vous voyez ici. Cela ajouterait essentiellement une configuration supplémentaire dans le fichier de configuration Git résidant dans le répertoire de l'utilisateur. Je te verrai ensuite. 57. 0702 Git Ignore en action Global exclut le config: Supposons que git ignore une action. Ce que nous avons ici, c'est notre bonne vieille application my app avec un tas de fichiers et peut-être aussi avec un tas de commits. Oubliez tous les commits que nous avons effectués et ne vous souciez pas des fichiers qu'il contient. Concentrons-nous sur Gitignore. Imaginez maintenant que j'ai téléchargé ce projet depuis le référentiel centralisé et lance même l'application. Quand je fais cela, je risque de voir que les fichiers journaux sont générés automatiquement par l'application. Maintenant que nous n'avons pas d'application en cours d'exécution, simulons le comportement en créant manuellement les fichiers journaux. Permettez-moi de créer peut-être un fichier journal de points. Ici, il a considéré que ce fichier est en fait comment le créer par l'application. Peut également créer un dossier avec le nom info où nous pourrions avoir dans les journaux. Permettez-moi donc de créer un fichier avec le nom de dot log. Comme ça. Maintenant, si je lance Git Bash, je peux réellement mettre en scène ces fichiers. Git ajoute un journal de points. Comme vous pouvez le voir, je suis capable de mettre en scène ce fichier, qui n'est pas quelque chose que je souhaite faire. Permettez-moi donc de mettre rapidement en scène ce dossier. Comment puis-je m'empêcher de transférer accidentellement ces fichiers journaux ? Eh bien, une solution est d'aller dans le dossier point git info. Ensuite, nous avons ce fichier d'exclusion dans lequel vous pouvez spécifier les modèles que vous souhaitez qu'il ignore. Nous pourrions donc spécifier un journal de points en étoile de motif, et de cette façon nous ne pouvons pas les mettre en scène ou les valider. Mais cette fois, nous ne voulons pas utiliser ce fichier. Peux-tu deviner pourquoi ? Parce que ces fichiers journaux ne sont pas locaux pour mon inscription. Elle s'applique à tous les membres de l'équipe. Tous les membres de mon équipe qui téléchargent ces projets et exécutent l'application pourront voir ces fichiers journaux. Je ne veux pas non plus qu'ils puissent valider ces fichiers et le référentiel centralisé. Eh bien, c'est là que Gitignore entre en scène. Permettez-moi donc de créer un fichier point gitignore, point git. Ignorer. Assurez-vous que le nom est correct. Ouvrons ce fichier et ajoutons ce journal de motif en étoile. Cela devrait donc ignorer tous les fichiers journaux de notre projet. Maintenant, si je reviens à Git Bash et que j'essaie de mettre en scène ce fichier, il y aura une erreur qui indique que les parties suivantes sont ignorées par l'un de vos fichiers à points ignorés. Si je veux quand même ajouter ce fichier, je peux utiliser cette option tiret F pour quatre étapes de ce fichier, qui devait être ignoré. Mais vous ne voulez pas le faire si vous ne savez pas ce que vous faites. Nous ne pouvons même pas préparer un journal de points qui se trouve dans le dossier info. Nous obtenons la même erreur. Et si vous souhaitez ignorer certains fichiers et que vous souhaitez que tous ces modèles soient applicables à tous les référentiels de votre machine locale. Ensuite, vous voulez spécifier le fichier global d'exclusion avec la commande git config global. Ensuite, vous allez dire fichier d'exclusion du noyau. Et ici, vous devez fournir le chemin, le fichier ignore les points. Une fois cette commande exécutée, fichier de configuration Git global sera mis à jour. Cela se trouve dans le répertoire de votre utilisateur. Je t'y emmène en fait. Il n'y a donc actuellement que les informations d'identification globales que je souhaite utiliser pour tous les référentiels de mon inscription locale. Mais une fois que vous aurez exécuté cette commande, vous verrez cette propriété particulière être renseignée dans ce fichier. Quel que soit le fichier qu'ils ignorent vers lequel il pointe, ses modèles seront applicables à ses modèles seront applicables tous les référentiels de votre machine locale. D'une manière générale, vous souhaitez spécifier les modèles qui sont pertinents pour les fichiers du système d'exploitation tels que point, DS, store, et non les fichiers liés au projet. Puisque nous n'avons rien, je veux juste ne pas le gérer. Une fois que vous avez créé ou mis à jour le fichier point Git ignore, vous souhaitez valider ces modifications et même les transférer dans le référentiel centralisé afin que tous ces modèles soient applicables pour tous les membres de votre équipe. Nous allons parler de la façon dont vous pouvez pousser vos validations locales vers le dépôt distant dans les chapitres suivants. Mais pour l'instant je peux aller de l'avant et entrer dans le dossier Gitignore. Git add, git, ignore le statut, git commit, tirez-le, peu importe. Et nous sommes en mesure de valider ce changement. Je te verrai ensuite. 58. 0703 Precedence de Precedence de débogage du modèle: Parlons des précédents. Supposons que nous ayons encore un fichier point gitignore dans l'un des sous-répertoires. Permettez-moi de copier ce fichier dans le répertoire info comme ça. Mais au lieu de ce modèle, je veux avoir ce modèle. Ou ce modèle signifie que nous voulons ignorer tous les fichiers qui n' ont pas d'extension point log. Maintenant, si vous remarquez que nous avons un conflit de modèles. Dans le répertoire racine. Nous avons un modèle qui indique que nous voulons ignorer tous les fichiers journaux de points. Mais alors qu'ici avec ce modèle, nous disons que nous voulons ignorer tous les fichiers. Il ne s'agit pas d'un fichier journal de points. Quel modèle devrait être suivi. C'est là que les précédents vont entrer en scène. Dans ce cas, ce modèle est préférable à celui du répertoire parent. La façon dont cela fonctionne est que lorsque vous avez un fichier comme info point log in, il vérifie s'il y a des fichiers point gitignore dans le même répertoire que celui où se trouve ce fichier. Si c'est le cas, il essaiera de trouver des motifs, une correspondance avec ce fichier. Si aucun modèle ne correspond à ce fichier, il recherchera les modèles dans le répertoire parent. S'il ne le trouve toujours pas, il essaiera de trouver les motifs dans le fichier d'exclusion. S'il ne trouve pas non plus de modèles qui correspondent au fichier particulier. Ensuite, il ira à l'intérieur et vérifiera le fichier global ignore. Si nous l'avions configuré. S'il ne trouve nulle part, cela nous permettra de mettre en scène ce fichier. C'est ainsi que se passerait le précédent. Maintenant, si je vais dans Git Bash, voyons si nous pouvons mettre en place le journal des points d'information. Nous pouvons, comme vous pouvez le voir, nous sommes en effet capables de mettre en scène le journal des points d' information parce que le modèle dans ce dossier, ventes que nous voulons inclure ce fichier et ne voulons pas l'ignorer. Dans la plupart des cas cependant, généralement dans presque tous les projets, vous n'avez qu' un seul fichier gitignore point qui se trouve dans le répertoire racine. Mais je partage ça juste pour ton information. Je dois également mentionner que nous ne sommes pas limités à quelques modèles. Nous avons un tas de modèles que nous pouvons utiliser en fonction de tous les fichiers que vous voulez ignorer. Dans la plupart des cas, il s'agirait généralement de ceci. Ou vous pourriez finir par spécifier un dossier comme celui-ci. Tous les modèles, vous pouvez vous référer à la documentation officielle. Il n'y en a pas beaucoup. Vous pouvez simplement jeter un coup d'œil et avoir une idée du poids en tant que modèles pris en charge. Cela n'a pas de sens pour moi de vous expliquer chaque schéma et de prendre tout votre temps. Il vous suffit de vous référer à la documentation qui contient tout ce dont vous avez besoin. Parfois, vous pouvez avoir tellement de fichiers ignorés. Il est donc difficile de comprendre pourquoi un fichier particulier est ignoré. Dans ce cas, nous avons une commande à portée de main. Tu as dit « Get, check ». option Ignorer avec trait d'union v signifie « bavard ». Ensuite, vous allez spécifier le nom du fichier. Par exemple, Error dot loc. Et cela va imprimer pourquoi ce fichier est ignoré. Comme vous pouvez le voir, nous avons un fichier point ignore dans le répertoire racine. Et ce modèle correspond à ce fichier. C'est pourquoi on l'ignore. Cela peut s'avérer pratique, en particulier si vous avez plusieurs fichiers ignorés ou si vous n'êtes pas certain de la raison pour laquelle un fichier particulier est ignoré. 59. 0704 Ignorez les fichiers déjà engagés: Et si nous avions déjà validé les modifications qui seraient censées être ignorées ? Laissez-moi vous montrer ce que je veux dire. À cette fin. Une fois de plus, j'ai ramené le projet à ce qu'il était au début de ce chapitre. Nous avons encore une fois ces trois dossiers et nous allons commencer par là. Permettez-moi de créer un fichier journal. Appelons-le journal des points d'erreur. Permettez-moi d'aller de l'avant et de valider ce fichier journal. Comme si je commettais ce fichier accidentellement, avec de nombreux autres changements. Git ajoute le journal des points d'erreur, git, commit Typhon, un message, et nous avons validé le fichier journal. Imaginez maintenant que notre projet est tout nouveau, notre équipe est toute nouvelle. Personne n'est familier avec le fichier dot ignore. Supposons que nous ayons un tas de fichiers dans le dépôt, ils se trouvent dans le dépôt centralisé que des fichiers sont censés être ignorés. Maintenant, c'est à ce moment-là que je me suis rendu compte que j' avais besoin d'un fichier point gitignore dans mon répertoire racine. Je vais donc l'inclure point Git, ignore. Je vais spécifier un ensemble de modèles, que je voulais ignorer. Dans mon cas, je vais simplement dire «  point d'étoile ». Comme ça. Permettez-moi de renommer correctement ce fichier. C'est censé être bon. Ignorez comme ça. Maintenant, il est déjà trop tard car nous avons déjà validé tous les fichiers qui ne sont pas censés le devenir. Permettez-moi également d'en venir à ce dossier. Git add, git, commit Typhon introduit ignore le fichier. Maintenant, j'ai introduit ce fichier, qui est excellent. Et cela va maintenant ignorer tous les fichiers qui sont censés être ignorés. Mais qu'en est-il de tous les fichiers déjà validés ? Comment s'en débarrasser ? Eh bien, une solution simple consiste simplement à identifier tous ces fichiers, les supprimer, puis à effectuer un commit. Tous ces fichiers seront supprimés. Et à partir de maintenant, nous avons le fichier point gitignore, tout moyen d'empêcher cela. Mais en pratique, si vous avez beaucoup de fichiers, il devient vraiment peu pratique d'identifier tous les fichiers que vous vouliez supprimer. Avons-nous une meilleure solution ? La réponse est oui. Nous avons une solution sournoise pour résoudre ce problème plus efficacement. Laissez-moi vous montrer ce que je veux dire. Je vais revenir à Git Bash. Laissez-moi effacer l'écran. Laissez-moi faire git status pour m' assurer que tout est propre. Laisse-moi exécuter la commande. Git RM, tiret r signifie récursif. Ensuite, je vais utiliser l'option mise en cache, suivie d'un point. Qu'est-ce que j'essaie de faire ici ? J'essaie de supprimer tous les fichiers mis en cache. Maintenant, en ce qui concerne les fichiers mis en cache, vous pouvez me demander, eh bien, les fichiers mis en cache sont essentiellement les fichiers qui sont suivis par Git. Git stocke tous les fichiers qu'il souhaite suivre dans un cache. Et avec cette commande, nous les nettoyons. Cela donne l'impression que nous avons effectivement supprimé tous les fichiers sans avoir à les supprimer du répertoire de travail. Exécutons cette commande et voyons ce qui se passe. Et comme vous pouvez le constater, tous ces fichiers ont été supprimés du cache. Cela inclut donc littéralement tous les fichiers de notre répertoire de travail. Comme vous pouvez le constater, nous avons cinq dossiers ici. Nous avons cinq dossiers ici. Ensuite, ce que nous allons faire, c'est mettre en scène tous les fichiers détectant ce qui va se passer. Mais avant cela, laissez-moi exécuter à nouveau la commande git status. Et cette fois, si vous remarquez dans la section des modifications à valider, elle a répertorié tous ces cinq fichiers. C'est parce que nous pensons que nous avons effectivement supprimé tous ces fichiers. Bien que nous ne les ayons pas supprimés du répertoire de travail. Nous venons de vider le cache et nous sommes convaincus que nous avons effectivement supprimé ces fichiers en même temps. La section Fichiers non suivis répertorie tous les fichiers qui ne sont pas actuellement suivis. Maintenant, prenez note. Cette liste n' inclut pas le journal des points d'erreur car il fait maintenant partie du modèle dans le fichier point gitignore. Git ne veut pas le suivre. Maintenant, ajoutons tous ces fichiers non suivis et faisons en sorte qu'ils soient suivis par Git. Git ajoute ce terme. Je vais utiliser le caractère point que même les fichiers commençant par un point soient ajoutés et suivis par Git. Maintenant, si je fais git status, vous verrez que error dot log est le seul fichier dont nous avons besoin. C'est comme si nous avions supprimé ce fichier et que nous avions fait un commentaire. Essentiellement avec cela, nous sommes en mesure supprimer tous les fichiers qui ne sont pas censés être validés sont ceux qui sont censés être ignorés. Maintenant que nous avons préparé cette pile pour être supprimée, il y a une dernière chose que nous devons faire est de valider les modifications. Le nettoyage en a ignoré cinq, c'est comme une cellule. Et get a supprimé dans un journal de points. Cela signifie simplement que le nouvel instantané n'a plus ce fichier. Mais bien sûr, nous l'avons toujours dans le répertoire de travail. s'agit donc d'un simple contournement sournois pour se débarrasser de tous les fichiers que nous avions précédemment commentés et qui sont censés être ignorés. Maintenant, si vous n'êtes toujours pas clair, prenez votre temps et testez ces commandes et vous les comprendrez. Je te verrai ensuite. 60. 0705 Générer les fichiers Ignore pour votre projet: Si vous introduisez le fichier point gitignore dans votre projet, vous n'avez pas vraiment besoin de réfléchir aux modèles que vous souhaitez conserver dans ce fichier. Vous pouvez simplement utiliser l'un des outils existants avec un générateur rapide de recherche Google git ignore. Je suis tombé sur ce lien. Ça a arrêté al.com. Vous pouvez consulter un autre site Web, mais ils font le même travail en générant des modèles pour vous en fonction du type de projet que vous créez. Par exemple, supposons que je crée une application Android. Donc, il suffit de taper Android et de cliquer sur Créer. Et il m'a fourni une liste de modèles que je peux ajouter dans le fichier point gitignore de mes projets. Nous connaissons déjà la majorité de ces modèles. Toutes les lignes avec un hachage signifieraient des commentaires. Ici, nous essayons d'ignorer le répertoire Gradle du DOD. Ici, nous essayons d' ignorer le répertoire de compilation. Donc tout son contenu, tous les fichiers ainsi que les sous-répertoires seraient ignorés pour la mise en scène. Ici, nous essayons d'ignorer le fichier de propriétés de point local. Star dot log signifie que nous voulons ignorer tous les fichiers journaux. Et nous en avons déjà vu un exemple. De même, nous avons un tas d'autres modèles. Essayons de taper dans Node. Et voyons ce que ça va générer. Encore une fois, nous avons un tas de modèles auxquels vous pouvez ajouter un nouveau nœud. Le projet JS a une attribution. Copiez simplement l'un de ces fichiers et essayez expérimenter ces modèles et de voir quels sont tous les fichiers qui sont ignorés et de faire en sorte que tous les fichiers ne soient pas ignorés. Je te verrai ensuite. 61. 0801 Pourquoi GitHub GitHub vs Bit Bucket vs GitLab: Très bien, il est maintenant temps de parler de GitHub. Nous avons en quelque sorte déjà abordé ce point au début du cours. Mais essayons de réitérer et d'essayer de comprendre la nécessité d'avoir un service d'hébergement de code centralisé comme GitHub. Si vous êtes le seul à travailler sur le projet, vous n'avez pas besoin de quelque chose comme GitHub. Vous pouvez simplement utiliser Git qui est installé localement pour gérer les versions de votre projet. Cependant, au fur et à mesure que votre projet prend de l'ampleur, vous souhaiterez peut-être embaucher des personnes supplémentaires qui peuvent contribuer à votre projet. Bien qu'il ne s'agisse que d'une ou deux personnes, vous pouvez facilement gérer sans avoir à utiliser un service comme GitHub. dizaines et des centaines d'employés qui pourraient vouloir contribuer à votre projet, alors vous avez sûrement besoin d'un meilleur moyen de gérer votre code et son historique de versions. Et c'est là que GitHub entrerait en scène. Et GitHub agit comme un dépôt de code centralisé où tout le monde peut apporter son code. Essentiellement, ils effectuent un tas de validations dans leur Git local, puis téléchargent ou diffusent toutes ces modifications vers le référentiel centralisé. Ensuite, tout le monde pourrait télécharger toutes les modifications apportées par les autres membres de l'équipe. Supposons que tout le monde ait une copie de l'ensemble du projet sur l'ordinateur local. plus, nous avons également une copie du projet dans le référentiel centralisé comme GitHub avec son historique des versions. Et c'est ce que l' on appelle un système de contrôle de version distribué. Cependant, get ne se limite pas à héberger votre code ou à maintenir l'historique des versions. Il offre de nombreuses autres fonctionnalités qui sont très utiles pour une organisation. Par exemple, être capable de gérer les membres de l'équipe pour déterminer qui peut faire quoi. Être en mesure de revoir les changements introduits par l'un des membres de l'équipe avant de les fusionner dans le courant principal du développement. Vous pouvez faire à peu près tout ce que vous pouvez faire dans votre bon logiciel local, comme valider le code, créer des branches, etc. Il vous proposera également de commenter le travail de quelqu'un. Nous pouvons également discuter de choses au sein de la communauté , etc. GitHub n'est pas la seule option pour nous. Nous avons également d'autres joueurs sur le marché qui ont exactement le même objectif. Celui que vous souhaitez utiliser dépend entièrement de vos besoins. Si votre organisation utilise projets de l'écosystème Atlassian tels que Jira, Bamboo , etc., alors Bitbucket peut vous être utile car il s' intègre mieux à ces outils. Et parmi ces trois, git lab est open source. Les deux autres ont des niveaux gratuits et payants. Et get lab et Bitbucket offre une meilleure prise en charge de l'intégration continue, qui est un concept de DevOps abordé dans mon cours DevOps. Mais GitHub est le plus ancien de ces trois. Des millions de projets s'appuient sur GitHub et des millions et des millions de développeurs dans le monde entier utilisent activement GitHub. Github possède une communauté incroyable et est également le meilleur choix pour les projets open source. L'interface utilisateur est également assez minimaliste, mais elle a un coût. Il ne dispose pas de la prise en charge intégrée de l'intégration continue comme avec GitLab et Bitbucket. Mais ce n'est pas grave, vous pouvez utiliser certains outils tiers pour cela. Mais peu importe lequel de ces outils vous allez apprendre. Ils ont finalement le même objectif de gérer votre projet. Ils peuvent différer en termes d' interface utilisateur et de terminologies utilisées. Mais sinon, ils ont tous le même objectif. 62. 0802 Compte Creatig GitHub: Voyons comment créer un compte GitHub et même créer quelques référentiels. À cette fin, j'ai créé un faux compte Gmail, qui est sous Corp 96 sur gmail.com. Comme si cette société était créée en 1996 ou WhatsApp. Désormais en tant que pigiste, il va créer un compte GitHub pour sa propre organisation afin que tout le monde et son équipe puissent maintenant commencer à contribuer au projet sur GitHub. Cliquons sur « S'inscrire ». En fait, les instructions sont assez simples. Je n'ai pas vraiment besoin de t'expliquer ça, mais je le fais juste pour une formalité. Il nous demande donc de saisir l'adresse e-mail. Je vais juste utiliser ce mot de passe. Je l'ai déjà à portée de main. Donc je vais juste le coller. Le nom d'utilisateur va être là Corp 96. Et levez-vous dit que ce n'est pas disponible. Nous devons donc changer cela pour quelque chose d'autre, peut-être 1996, maintenant il est disponible. Continuons. Il nous demande si nous aimerions recevoir les mises à jour et les annonces par e-mail, je dirais non pour l'instant. Si vous le souhaitez, vous pouvez y participer. Suivant. Il nous demande de résoudre un casse-tête pour nous assurer que nous ne sommes pas un robot. Je dois juste choisir cette galaxie spirale. Dans mon cas. C'est exactement ce que je vais faire. J'ai fait un excellent travail là-bas, donc je peux créer le compte. Nous avons reçu ce mail avec le code, que je n'ai qu'à le copier et le coller ici. Et nous avons fini de créer un compte GitHub. Plutôt. Je voulais simplement sauter cette étape. Si vous le souhaitez, vous pouvez choisir le nombre de membres de votre équipe et si vous êtes étudiant ou enseignant. Mais je vais simplement l'ignorer pour l' instant. Et c'est fini. Maintenant, dès le premier coup d'œil sur cette page d'accueil que vous voyez une fois que vous vous connectez pour la première fois, get up nous donne déjà des suggestions sur ce que nous pouvons faire ensuite. Nous pouvons créer un dépôt ou importer un dépôt existant. Nous pouvons introduire un fichier Lisez-moi dans notre projet. Nous pouvons même explorer les possibilités de contribuer à certains projets existants, dont nous parlerons plus tard dans le cours. Et il y a plein d' autres choses que vous pouvez simplement jeter un coup d'œil et avoir une idée de ce dont il s'agit. Vous n'avez pas besoin d' aller trop loin car nous allons tout explorer lors des prochaines conférences. 63. 0803 Créer et comprendre des référentiels publics et privés dans GitHub: Voyons comment créer des référentiels GitHub. Nous pouvons ajouter cet important dépôt existant. Je vais en créer un nouveau. Et c'est exactement ce que je vais faire. Ici. Vous allez voir le nom du propriétaire. Dans ce cas, nous n'avons qu'un seul propriétaire. Et c'est ce qui est choisi par défaut. Ici, vous devez fournir le nom du dépôt, le nom du dépôt que vous souhaitez faire. Maintenant, nous devons décider si vous souhaitez rendre le projet public ou privé. Si votre objectif est de lancer un projet open source, il peut être judicieux que vous choisissiez l'option publique ici. Ou si vous êtes une entreprise dans laquelle votre logiciel ou votre application est propriétaire et que vous avez un client pour lequel vous travaillez, il peut être plus judicieux d' utiliser un référentiel. S'il s'agit d'un dépôt public, n'importe qui dans le monde entier pourra voir le contenu de votre projet, le télécharger, le cloner, etc. Alors que si le dépôt est privé, vous pouvez choisir qui peut faire ce que vous pouvez contribuer au projet, qui peut voir le projet, etc. Je vais vous montrer la création des deux. Le dépôt suppose que je suis en train de créer une sorte de projet open source. Permettez-moi d'appeler mon application en tant qu'application publique ou autre. Si tu le souhaites. Vous pouvez également séparer ces noms par un trait d'union. Vous ne pouvez pas utiliser de caractère d'espace. Si vous incluez un caractère d'espace, alors get suppose automatiquement un trait d'union, comme il le suggère. Au fait, je pourrais utiliser les mots Git et GitHub de manière interchangeable selon le contexte. C'est donc le nom de l'application que j'ai donné. Je peux également écrire une brève description du projet, mon application publique, peu importe. Et puis lève-toi. Il nous montre des options pour inclure certains de ces fichiers, comme le fichier Lisez-moi, qui aurait quelques détails sur le projet. Le fichier à ignorer par points, quels que soient les modèles de fichier vous incluez dans ce fichier, serait ignoré pour être validé. Ensuite, nous pouvons également choisir le fichier de licence. Il existe certaines licences prédéfinies que nous pouvons utiliser si nous le souhaitons. Par exemple, si vous créez un projet open source, le GPU ou la licence publique générale peuvent vous convenir. Pour le moment, je ne vais pas en choisir un seul parce que nous pourrons les ajouter plus tard. Mais si vous choisissez l'un d'entre eux, get créera automatiquement un commit notre nom en validant ces fichiers. C'est ton choix. Vous pouvez le choisir ou ne pas le choisir. Les deux sont à peu près les mêmes. Nous allons quand même les ajouter dans les prochaines conférences. Il s'agit donc simplement de créer un dépôt public. Cliquons sur Create Repository. Et GitHub propose quelques prochaines étapes dont vous n'aurez pas à soucier, car nous allons les explorer de toute façon dans les prochaines conférences. Mais si vous revenez ici, vous pouvez voir que notre dépôt est listé ici. Si vous copiez le lien, le lien ressemblera à ceci. Vous avez Github.com, puis la barre oblique du nom d'utilisateur, le nom du dépôt. Et c'est ainsi que tout le monde pourrait accéder à votre dépôt public. Maintenant, n'importe qui dans le monde peut cliquer ce lien pour voir notre projet de Watson parce qu'il est public. Créons maintenant également un dépôt privé. Vous cliquez sur le nouveau nom du dépôt , disons, application bancaire, peu importe. Dans mon application bancaire, je vais choisir l'option privée, afin que seules les personnes auxquelles je donne accès puissent voir le projet et y contribuer. Je parle en fait de collaborateurs, que nous allons bientôt explorer. Cette fois-ci. Laissez-moi peut-être choisir l'un de ces fichiers. J'aimerais peut-être ajouter un fichier de licence. Par exemple. Il ne peut probablement pas s'agir d'une licence publique générale. Mais tu peux utiliser n'importe quoi. Vous n'avez pas à être vraiment sérieux à ce sujet, sauf si vous êtes une véritable organisation qui s'inquiète des licences. Je choisis simplement quelque chose aléatoire et je crée un dépôt. Cette fois, github a fait un commit pour nous. Et dans ce commit a validé le fichier de licence. Vous pouvez cliquer sur ce fichier pour voir son contenu. Vous pouvez le modifier si vous le souhaitez et effectuer un autre commit. Mais nous allons explorer tout cela dans les prochaines conférences. Revenons à la page d'accueil. Et maintenant, vous pouvez voir ces deux référentiels. Comme il s'agit d'un dépôt privé, personne d'autre ne peut y accéder . Malheureusement, les dépôts privés et GitHub n'ont pas beaucoup de fonctionnalités que les référentiels publics. Si vous voulez ces fonctionnalités et des référentiels privés. Et plus encore, pensez prendre certains des niveaux payants proposés par GitHub. À moins d'être une organisation, cela n'a pas vraiment de sens que vous les payiez. pour cette raison que, dans la plupart des cas, nous allons utiliser le dépôt public dans ce cours. Je te verrai ensuite. 64. 0804 Faire des engagements dans le fichier GitHub et comprendre le fichier ReadMe: Voyons comment nous pouvons effectuer notre premier engagement et nous relever. Et nous allons le faire dans le dépôt public. Ce que nous allons trouver c'est le fichier Lisez-moi de notre projet. Qu'est-ce que le fichier Lisez-moi ? Quoi que vous vouliez faire savoir, les contributeurs de votre projet iront dans le fichier Lisez-moi pour mieux le comprendre Jetons un coup d'œil à certains projets existants et GitHub et à quel point les fichiers Lisez-moi. Je vais simplement choisir l'un des projets choisis au hasard. Je clique donc sur ce lien qui indique trouver les rapports qui ont besoin de votre aide. Je vais simplement choisir l'un des projets disponibles au hasard ici. Peut-être que voici la liste des tuples à lever. Les deux sont publics. Laissez-moi choisir celui-ci. Tous les projets et GitHub auront probablement le fichier Lisez-moi. Et cela se trouve généralement dans le répertoire racine du projet. est donc ici. Voyons ce qu'il contient. Fondamentalement, vous pouvez écrire des informations comme vos coordonnées. Certains des liens que vous souhaitez partager avec les billets d'un dollar. Vous pouvez également leur indiquer comment ils peuvent soulever des problèmes et à qui s'adresser en cas de problème avec l'application. Vous pouvez également parler de l' application et de ses fonctionnalités, comme c'est le cas ici. Voici la liste des fonctionnalités prises en charge par cette application. Ils affichent des instructions sur la façon de télécharger ce projet. Et de nombreuses autres informations que nous partageons leur feuille de route afin que les développeurs aient une vue d'ensemble de l'ensemble du projet. Ils semblent avoir listé ici toute la liste des contributeurs, ou peut-être les meilleurs contributeurs qui ont contribué à ce projet. Ainsi de suite et ainsi de suite. Allons-y et créons un fichier Lisez-moi dans notre dépôt public. Je vais choisir le dépôt public qui a été créé. Et actuellement, nous n'avons aucun commit. Nous pouvons soit créer un nouveau fichier, soit télécharger un fichier existant, soit choisir l'une de ces options. Et gate sera pré-renseigné avec du contenu. Nous avons déjà vu qu' en cas de fichier de licence, nous avons déjà des modèles prédéfinis. Nous avons également certains modèles prédéfinis sont préremplis pour le fichier à ignorer les points. Mais nous n'allons pas l'utiliser parce que nous n'en avons pas encore parlé. Laissez-moi choisir le fichier Lisez-moi. C'est donc le fichier Lisez-moi point md. C'est enseigné la vulgarisation MD. Ici. Tu peux écrire ce que tu veux. Et une fois que vous avez terminé, vous pouvez faire défiler vers le bas et cliquer sur ce bouton qui dit valider un nouveau fichier. Vous pouvez voir ici que certains messages par défaut sont déjà renseignés par GitHub. Il indique Create, Read Me dot RMD file. Si vous souhaitez le modifier, vous pouvez le modifier. Vous pouvez également ajouter la description de ce commit. Mais je suis satisfait du message par défaut. Je vais donc simplement le laisser tel quel et cliquer sur Commit. Aucune étape de mise en scène n'est requise. Cela ferait ce travail en interne pour nous. Une fois que vous aurez validé le fichier, vous verrez ce fichier ici. Faisons encore un commit en introduisant un autre fichier. Permettez-moi de revenir en arrière et de cliquer sur cette option qui indique Ajouter un fichier, créer un nouveau fichier. Peut-être aimerais-je ajouter un fichier TXT à quatre points, un fichier d'informations sur le contenu. Permettez-moi de développer cela. Je vais faire défiler la page vers le bas. Et 1 seconde. Je suis satisfait du texte prérempli, mais je peux le remplacer par autre chose si je le souhaite. Je vais laisser cette option en l'état. Puisque nous n'avons pas parlé de pull request. Je ne suis pas en mesure de vous expliquer quoi consiste cette option. Nous allons en parler lors des prochaines conférences. Venez avec le nouveau dossier. Nous avons maintenant quelques commentaires. Si vous cliquez sur ces validations, vous pouvez voir la liste des validations que nous avons effectuées. Voici le HashCode de chacun de ces commentaires afin que vous puissiez les copier en cliquant sur cette icône. Vous pouvez également accéder à l'état d' un projet lors d'un commit particulier. En cliquant sur ce bouton. Par exemple, si je clique dessus, la comète apparaîtra dans le fichier ReadMe. À ce stade, nous n' avons pas le fichier info, donc nous ne le voyons pas. Laisse-moi y retourner. Ici. C'est à vous de choisir la succursale. Actuellement, nous n' avons qu'une seule branche et c'est la branche principale par défaut. Sinon, la liste des branches s'afficherait et nous serions en mesure de basculer vers l'une d'entre elles. C'est ainsi que vous faites des commentaires et GitHub. Nous avons créé le dépôt et avons également ajouté certains des fichiers de base qui le rendent prêt pour que d'autres puissent contribuer à notre projet. Je te verrai ensuite. 65. 0805 Créer une succursale et engager des changements Gérer des succursales dans GitHub: Voyons comment créer une nouvelle branche et même y ajouter des commentaires dans GitHub. Pour cela, laissez-moi aller dans l' un des référentiels. Je vais utiliser le dépôt public pour cela. Vous pouvez voir ici une liste de succursales. Actuellement, nous n' avons qu'une seule branche, la branche principale, qui est également la branche par défaut. Ici vous pouvez voir ce lien qui indique voir toutes les branches. Vous pouvez soit cliquer ici, soit cliquer sur ce lien qui indique une succursale. Il est indiqué « une succursale », car nous en avons actuellement une. Cliquons sur ce lien. Vous voyez ici l'option permettant de créer une nouvelle branche. Il suffit de cliquer sur ce bouton, saisir le nom que vous souhaitez attribuer à cette branche. Quelque chose comme ça. Vous pouvez également choisir la branche source à partir de laquelle vous souhaitez créer cette branche. Dans ce cas, nous n'avons qu'une seule branche et elle est passée par défaut à la branche principale. Je vais le garder tel quel et cliquer sur Créer une branche. Cela a créé la succursale pour nous. Vous pouvez également consulter la liste spécifique des succursales. Par exemple, si je clique sur activer, cela va être listé sur toutes les branches de l' Acte deux. En d'autres termes, il s'agit des branches dans lesquelles au moins un engagement a été effectué au cours des trois derniers mois. Vous n'allez cependant pas voir la branche par défaut. Vous pouvez voir la branche qui vient d'être créée. Cette branche de queue est l' opposé de deux branches. S'il y a des branches pour lesquelles vous n'avez effectué aucun commit au cours des trois derniers mois, vous allez en voir la liste ici. Si vous êtes le propriétaire du dépôt, vous aimeriez peut-être entrer en contact avec collaborateurs, des développeurs qui travaillent sur ces branches et vérifier auprès eux s'ils souhaitent toujours conserver ces branches. ou pas. Vous en aurez une meilleure idée au fur et à mesure que nous progresserons dans ce cours. Et les branches de cette section seraient listées telle sorte que la branche avec le plus ancien commit soit listée en premier. Alors qu'ici, dans la section active, toutes ces branches seraient listées de manière à ce que les branches avec le commit récent soient listées en premier. Si vous cliquez sur toutes les branches, ce pied affiche simplement la branche par défaut, suivie de toutes les autres branches classées par branches ayant le commit le plus récent en premier. Vous pouvez également supprimer une branche et la restaurer. Si vous supprimez une branche, actualisez la page, il est alors trop tard pour la restaurer. Nous sommes donc en mesure de créer une nouvelle branche. Revenons au dépôt. Ici, nous pouvons choisir la branche vers laquelle nous voulions basculer. Basculez vers la branche de fonctionnalité. C'est comme si nous avions exécuté cette commande ou cette commande paiement mentionnant le nom de la branche. Et si vous remarquez, nous avons maintenant deux branches affichées ici. Nous pouvons soit ajouter un nouveau fichier dans cette branche, soit modifier l'un des fichiers existants. Essayons de l'ajouter. Fichier Lisez-moi point MD. Je clique sur cette icône, ce qui me permettra de modifier certains messages. Je veux faire défiler la page vers le bas. Je suis content du message par défaut si vous le souhaitez, vous pouvez le modifier. Je vais laisser cette option en l'état. Et cliquez sur Commit Changes. Cela a engagé les changements dans la nouvelle branche. Nous sommes actuellement dans la branche principale. Et si vous cliquez sur Read Me dot md file et vérifiez son contenu, vous remarquerez qu'il n'a pas les modifications introduites dans la nouvelle branche de fonctionnalité. Mais si vous passez à la branche de fonctionnalité, comme vous pouvez vous y attendre, vous verrez les modifications que nous venons d'introduire et la branche de fonctionnalité. Je te verrai ensuite. 66. 0901 Cloner un repo public et explorer d'autres options: Auparavant, nous avions créé un compte GitHub sous le nom de Centre Corp 1996. Nous avons également créé quelques référentiels. L'un est public, l'autre est un dépôt privé. Ou un dépôt public devrait être disponible pour que n'importe qui dans le monde puisse le voir, le télécharger, le piloter, etc. Maintenant disons que j'ai trouvé un gars avec le nom de Luke et que je voulais qu'il contribue à mon dépôt public. Imagine maintenant que je suis dans l'ordinateur de Luke. Ce que vous devez d'abord faire est d'avoir un compte GitHub. Donc, dans ce but, j'ai créé un nouveau compte Gmail avec le nom Centre Corp sur le site gmail.com rouge et son compte GitHub correspondant également. C'est donc le récit de Luke et maintenant il se prépare à contribuer au dépôt public de cylinder cop 1996. Il s'agit de l'URL de ce référentiel. Et je suis en mesure de voir le projet et son contenu car il s' agit d'un dépôt public. S'il s'agit d'un dépôt privé, je ne pourrai pas le voir. En fait, toute personne disposant de ce lien devrait pouvoir voir le projet et son contenu car il s'agit d'un dépôt public. La première chose que Loop doit faire pour commencer à contribuer à ce projet est d'avoir une copie locale de ce dépôt sur son ordinateur local. Ce dont je parle, c'est de git clone. Et comme son nom l'indique, il clonait essentiellement le dépôt central ou le projet dans votre inscription locale. Vous cliquez donc sur ce bouton qui indique le code. Et nous disposons de plusieurs méthodes pour cloner le projet. Nous pouvons le faire par le biais de l'interface de ligne de commande. Get up CLI est un outil proposé par GitHub. C'est un outil open source qui vous permettra essentiellement d'interagir avec GitHub depuis la ligne de commande de votre ordinateur. Mais cet outil est initialement destiné à gagner du temps, mais ce n'est pas un outil obligatoire en tant que tel. L'autre option est d'utiliser SSH, qui est une procédure longue car pour cela, vous devez créer des clés publiques et privées puis stocker la clé publique dans le dépôt, etc. Parler des sciences humaines devrait faire l'objet d'un autre cours. Si vous utilisez SSH, vous pouvez opter pour cette option. Si ce n'est pas le cas, nous avons une meilleure option. En fait, c'est une option recommandée même par GitHub, qui utilise le protocole HTTPS. C'est la meilleure option parmi toutes ces options pour deux bonnes raisons. Premièrement, les pare-feu n'ont généralement pas tendance à s'arrêter en tant que trafic HTTPS. Nous avons donc un avantage sur ce point. Deuxièmement, cela aidera également l'assistant d'identification votre système d'exploitation à pouvoir mettre en cache ou stocker les mots de passe, ce qui n'est pas le cas avec les deux autres options. C'est le plus simple de tous, et nous pouvons y aller aveuglément sans avoir à nous soucier de SSH ou de la CLI. Nous avons également la possibilité de télécharger le projet. Eh bien, si vous téléchargez le projet, vous ne téléchargerez pas les données historiques ou l'historique des versions téléchargera simplement les fichiers du projet. Nous pouvons également l'ouvrir avec GitHub Desktop. Si vous avez installé GitHub Desktop, vous pouvez l'ouvrir et choisir le dossier dans lequel vous souhaitez cloner ce projet. Puisque nous n'utilisons pas cet outil pour le moment, nous pouvons l'ignorer. Ce que nous allons faire, c'est simplement copier ce lien HTTPS. C'est le lien exact, comme vous le voyez ici, qui est le lien vers le dépôt, c'est github.com slash nom d'utilisateur de ce dépôt, le propriétaire du dépôt, barre oblique le nom du dépôt lui-même, puis point obtenir l'extension. C'est essentiellement de quoi s'agit-il ? Vous êtes littéralement simplement copié. Une fois que nous avons copié ce lien dans notre ordinateur local, je suis dans le répertoire def. Permettez-moi de le copier à nouveau. Vous ne pouvez pas imaginer que c'est l'ordinateur de Luke. Je vais utiliser la commande git clone. Ensuite, vous allez coller cette URL. Ici, il est dit clonage dans ce dossier. Essentiellement, il a créé un dossier avec ce nom, qui est le nom exact du dépôt. Et son contenu constituerait exactement le contenu que nous avons vu dans le dépôt GitHub. Et si vous remarquez qu'il a réellement compressé tous les objets. Fondamentalement, pour faciliter le transfert de tous les fichiers sur Internet vers votre ordinateur local. Enfin, il a extrait tous les objets. Au total, neuf objets ont été reçus. Jetons un coup d'œil au contenu de ce répertoire. Voici donc ma casquette publique. Permettez-moi de l'agrandir un peu. Comme vous pouvez le voir, nous avons sorti dxdy ainsi que le fichier Read Me dot TXT. Dossier git à l'intérieur du point. Tu vas voir ce que nous voyons d'habitude. Vous avez peut-être observé certaines choses qui peuvent vous sembler étranges à ce moment-là. Nous allons en parler lors des prochaines conférences. Par exemple, nous avons des « télécommandes », qui n'étaient pas disponibles lorsque nous avons créé le dépôt localement. Nous en parlerons lors des prochaines conférences. C'est comme si vous avez créé un dépôt local, sauf que cette fois-ci, nous avons cloné un dépôt existant depuis GitHub. Si vous deviez télécharger le projet, vous ne verrez pas le dossier dot git. Vous ne verrez que ces deux fichiers de projet. C'est la raison pour laquelle il est appelé système de contrôle de version distribué. Vous disposez d'une copie de l' intégralité du dépôt ainsi que de son historique des versions sur votre ordinateur local. Et vous en avez également une copie dans le référentiel centralisé, qui est ouvert. Et tout le monde au sein de l'organisation ou de votre entreprise aurait une copie de l'intégralité du référentiel. Si l'un d'entre eux tombe en panne, vous avez d'autres systèmes à partir desquels vous pouvez le récupérer. C'est un système de contrôle de version distribué pour vous. Revenons à Git Bash. Maintenant, si je lance la commande git branch, nous devons d'abord aller dans ce répertoire. Mon CAP public, branche git. Vous n'allez voir que la branche principale, bien que nous ayons créé une branche de fonctionnalité dans le référentiel centralisé GitHub, ici nous ne voyons que la branche principale. Pourquoi est-ce que c'est ? Eh bien, vous y trouverez une réponse dans les prochaines conférences. 67. 0902 Cloner un référentiel privé et ajouter des collaborateurs de projet sur GitHub: Voyons comment cloner un dépôt privé. Je suis actuellement connecté en tant qu'expéditeur Qui est le propriétaire de ces référentiels ? L'un est le dépôt public et l'autre est le dépôt privé. Nous avons déjà vu comment cloner un dépôt public. N'importe qui dans le monde peut le voir, le cloner sur le système. Mais quand il s'agit d' un dépôt privé, tout le monde ne peut pas y accéder ou le cloner à moins que l'expéditeur ne l'adresse en tant que collaborateur de son projet. Afin de le démontrer, je me suis connecté en tant que cylindre et Luke, qui contribuerait au dépôt privé de cylindre. Afin de faire la distinction entre ces deux comptes. Celui avec l'équipe noire appartient à Sunder et celui avec l'équipe blanche appartient à Luke. Maintenant, vous devez supposer que ces deux personnes se sont connectées depuis leur propre ordinateur. Et bien sûr, pas du même système, comme nous le faisons ici. Permettez-moi de copier le lien du dépôt privé et j'ai essayé d'y accéder depuis le compte de Luke. Et nous obtenons une erreur qui indique 404. Ce n'est pas la page que vous recherchez. C'est parce que under n'a pas donné l'autorisation de chercher à accéder à ce projet. L'expéditeur doit donc aller dans ce référentiel, accéder aux paramètres, puis ajouter Luke en tant que contributeur. Laissez-moi entrer le mot de passe très rapidement. Vous verrez cette option qui indique Ajouter des personnes. Je vais chercher. Il regarde sous la carpe. Puisque Luke a un contenu, github, pourra le voir. Laissez-moi les choisir et cliquez sur Add looks on the Corp à ce dépôt. Une fois cela fait, loop recevra un e-mail pour accepter l'invitation de sun does à être le collaborateur du dépôt privé de l'expéditeur. Permettez-moi donc de cliquer sur ce lien. Cliquez sur Mutation acceptée. Maintenant, si vous allez sur le tableau de bord de Luke, vous pouvez voir ce dépôt privé être rempli. Laisse-moi cliquer dessus. Je peux maintenant aller de l'avant et planifier ce projet. Mais ce n'est pas très simple car avec un dépôt public, nous devons réellement l'authentifier. Laissez-moi vous le montrer. Donc ça ressemble à un ordinateur. Supposons que je suis dans le lecteur F. Et lançons la commande git clone et collons l'URL et voyons ce qui va se passer. Eh bien, bien ouvre cette invite particulière. Et il existe de nombreuses façons de s'authentifier. Mais j'aimerais opter pour cette option qui dit « se connecter avec un code ». Si vous choisissez de vous connecter avec votre navigateur, vous serez simplement redirigé vers une page Web où il vous sera demandé de vous connecter à votre compte GitHub. De cette façon, vous serez authentifié et le processus de clonage se poursuivra. Mais essayons de choisir cette voie. Lorsque je clique sur Connexion avec code, vous verrez un code que nous devons utiliser pour nous authentifier. Permettez-moi d'abord d'ouvrir une fenêtre de navigateur. Je vais aller sur github.com slash login slash device. Cela nous amène à cette page. Laissez-moi copier ce code, contrôler C et contrôler V. Et cliquez sur Continuer. Cliquez sur Autoriser. Il nous demande de saisir le mot de passe du compte de Luke. Faisons ça très vite. C'est tout. Notre processus de clonage s'est poursuivi. Et nous pouvons maintenant commencer à accéder à l'application bancaire. Regroupe les listes avec l'option de césure, mais affiche également les dossiers masqués. À partir de ce moment, tout resterait tel quel, comme dans le dépôt public. Mais c'est ainsi que vous clonez un dépôt privé. Je te verrai ensuite. 68. 0903 Comprendre les succursales de suivi et la succursale par défaut: Parlons du suivi des branches. Imaginez que c'est l'état actuel de notre projet sur GitHub. Supposons maintenant que j'ai lancé la commande git clone pour cloner le projet sur mon ordinateur local. Maintenant, c'est ce qui va se passer mon ordinateur local sans ordre particulier. Initialement, tous les objets seraient téléchargés , puis obtenir créera ce que l' on appelle des branches de suivi. Qu'est-ce que la branche de suivi ? Branches de suivi, branche locale qui représente une branche distante. Et cela indiquerait toujours exactement le même commit. Les branches distantes pointent vers cet emplacement uniquement pour représenter les branches distantes. Pour rappel, une branche est simplement un pointeur vers un commit spécifique. Désormais, ces branches de suivi ne seront pas mises à jour automatiquement. Elles seront mises à jour chaque fois que nous exécuterons certaines commandes comme git-fetch et git pull, dont nous parlerons dans les prochaines conférences. Et puis par défaut avec l'opération clone, git checkout vers la branche par défaut, qui est la branche principale. Ainsi, une branche Min locale serait créée automatiquement. Nous pouvons en fait configurer la branche par défaut dans notre GitHub, ce qui va exploser dans les prochaines conférences. Si vous vous souvenez dans notre cours précédent, lorsque nous exécutons la commande git branch, elle ne listait que la branche principale, mais pas la branche feature. Eh bien, c'est la raison de cela. Si vous voulez également voir la branche de fonctionnalité, nous devons vérifier dans cette branche afin qu' une branche de fonctionnalité locale soit créée par good et puisse la voir. Supposons maintenant que j'ai fait un commit local dans la branche principale comme la cellule, la branche de suivi resterait telle quelle, parce que c'est ce vers quoi pointe même la branche principale distante . Mais la branche principale locale serait mise à jour pour pointer vers le dernier commit sur notre machine locale. Vous comprendrez l' importance du suivi des branches lorsque nous explorerons des commandes telles que git-fetch, git, pull, git push, etc. Une autre chose que vous avez peut-être remarquée est que toutes ces branches de suivi sont nommées en tant que barre oblique d'origine principale ou fonctionnalité d'origines. Eh bien, qu'est-ce que l'origine ici ? Il s'agit essentiellement du plus ancien créé par get qui représente le dépôt distant. En gros, chaque fois que nous exécutons des commandes, winter fournit l'URL du dépôt distant. Il est très difficile de se souvenir de l'URL. C'est pourquoi nous avons créé ce ERP. Ainsi, au lieu d'utiliser l'URL, nous pourrions simplement utiliser ce nom. À la place. Nous pouvons changer ce nom si nous le souhaitons, ou nous pouvons le conserver tel quel. Nous allons certainement en parler davantage dans les prochaines conférences. voit ensuite. 69. 0904 Explorer des branches de suivi Configurer la branche par défaut Understanding Origin Head: Bon, regardons d'abord liste des branches de suivi. Et la commande pour cela est git. Succursale. Le trait d'union r signifie Remote. Vous pouvez voir ici à la fois la branche principale et la nouvelle branche de fonctionnalité. Et ce sont les branches de suivi qui seront représentées dans les branches distantes. Dans GitHub. Vous pouvez dire qu'il s'agit de branches de suivi car elles commencent par une barre oblique d'origine, puis le nom de la branche. Vous pouvez également le trouver dans le dépôt Git. Laissez-moi passer au projet. Et à l'intérieur du dossier git point, vous devriez être capable de localiser ce fichier avec le nom de dérives de tirets compressés. Ouvre ça. Et vous pouvez voir que nous avons ces deux branches. Et le point dans des commentaires spécifiques. Jetons un coup d'œil à ce qu'ils pointent. Pour ça, laisse-moi me lever. Je suis actuellement dans la branche principale. Et ici vous pouvez voir le HashCode du dernier commit. C'est E 0, le triple six vaut sept. Et nous sommes dans la branche principale. Et si vous remarquez, la branche principale pointe vers la même comète. Voyons également avec la nouvelle branche de fonctionnalité. Il doit pointer vers ce commit qui commence par 855 D, D2. Revenons en arrière et passons à la branche de fonctionnalité ou à la nouvelle branche de fonctionnalité. Et bien sûr, il pointe vers ce commit avec le HashCode 855, double D vers C. Même si vous deviez faire un commit local, cela resterait tel quel. Cela ne serait mis à jour lorsque nous exécutions certaines commandes comme git, fetch, git pull, etc. Nous les explorerons lors des prochaines conférences. branche Git listerait la liste des branches locales. Et quelle que soit la branche par défaut et que GitHub ne soit pas vérifié automatiquement chaque fois que nous clonons le projet, la branche par défaut est la branche principale. L'en-tête ici pointe toujours vers la branche par défaut, qui est la branche principale. Allons voir où nous pouvons configurer la branche par défaut. Si vous allez dans les paramètres. Sous les branches. Vous verrez ici que les branches par défaut, la branche principale. Si vous le souhaitez, vous pouvez basculer vers une autre agence. Par exemple, je peux choisir la branche de fonctionnalité et cliquer sur Mettre à jour. Mais ce n'est pas une pratique recommandée. Je vais sauter ça. Mais tu peux le faire si tu le souhaites. Dans le dépôt Git. Si vous allez dans refs remote origin et que vous regardez ce qu'il y a dans le fichier d'en-tête, il devrait pointer vers la branche par défaut, comme ceci. Et c'est ce que nous voyons ici. Maintenant, pour créer une branche locale pour la nouvelle branche de fonctionnalité, allez dans cette branche. Faisons git checkout. Nouvelle fonctionnalité. Maintenant, si vous faites git branch, il va lister toutes les branches locales. Et il inclut désormais également la nouvelle branche de fonctionnalité. Nous pouvons maintenant commencer à travailler sur cette branche de fonctionnalité. Vous obtiendrez de plus en plus de clarté sur ce dont nous venons parler au fur et à mesure que nous progresserons dans ce chapitre. Je te verrai ensuite. 70. 0905 Comprendre l'origine à distance d'ajouter, éditer, supprimer les télécommandes: Parlons de l'origine. Origin est un peu comme un alias sur votre système pour un dépôt distant particulier. Laissez-moi vous expliquer ce que je veux dire. Il existe certaines commandes et vous devez spécifier l'URI du dépôt distant. Comme dans le cas de git push. Nous parlerons plus en détail commande git push dans les prochaines conférences. Mais ce que cette commande nous permet essentiellement de faire, c'est qu'elle nous permettra de pousser nos commits locaux sur le dépôt distant. Eh bien, de telles commandes nécessitent que nous saisissions l'endroit où nous voulons pousser nos commits en spécifiant l'URI du dépôt distant. Maintenant, que diriez-vous de donner un nom à cet ERA de sorte que chaque fois que nous devons exécuter une telle commande, au lieu de spécifier l'ERA dans son intégralité, il suffirait de taper ce nom à la place. Cela va nous apporter beaucoup de commodité. Et c'est essentiellement ce qu'est l'origine. Origin est un peu un nom abrégé pour l'étude de dépôt distante à partir de laquelle le projet a été cloné à l'origine. Ainsi, au lieu de saisir l'URI, nous pourrions simplement dire origine, comme ça. Et c'est Asda. Nous avons saisi l'URI du dépôt distant. Nous pouvons renommer ce nom avec un autre nom. Nous pouvons également ajouter des télécommandes supplémentaires. Quand je dis remote est simplement un nom représentant un dépôt distant particulier, comment pouvons-nous même supprimer ces télécommandes. Laissez-moi vous montrer ce que je veux dire. Si vous allez dans le dossier dot git, dans votre projet et ouvrez le fichier de configuration. Vous remarquez que nous avons une télécommande avec le nom origin et qu'elle pointe vers un dépôt distant dans le champ URL. C'est exactement ce qu'est le mode. Donc, chaque fois que nous devons exécuter la commande, où serait-il nécessaire d'entrer le CR ? Nous pouvons simplement saisir l'origine du nom à la place. Nous pouvons également le renommer, mais bien sûr, nous ne devons pas le faire directement sur ce fichier. Au lieu de cela, allez exécuter la commande. Faisons ça. À l'intérieur du Git Bash. Créons d'abord une nouvelle télécommande. Et oui, nous pouvons avoir plusieurs télécommandes et dans certains cas, nous pouvons avoir besoin de plusieurs télécommandes. Nous allons en parler lors des prochaines conférences. Mais pour l'instant voyons comment créer une télécommande, renommer et même la supprimer. La commande pour cela est git remote. Ajoutez le nom du serveur distant, le nom que vous souhaitez, à ce référentiel distant. Appelons ça temporaire, rapport, peu importe. Ensuite, vous allez spécifier l'URI du dépôt distant. Il s'agit simplement d'une URL factice qui n'existe pas. Et si j'appuie sur Entrée, et si nous revenons au fichier de configuration, vous verrez qu'il existe une nouvelle télécommande créée avec le nom de pôle temporaire, dont l'URL est l'URL que nous venons de spécifier dans le commande. Je vais essayer de renommer cette télécommande. Git remote, renommez-les ripple. Le nom de la télécommande que vous souhaitez renommer. Ensuite, vous allez spécifier le nom que nous aimerions lui donner. Un nouvel intérim, un dépôt, disons. Et cela va changer le nom pour ce nouveau nom. Enfin, voyons comment supprimer une télécommande. Git. La suppression à distance est l'option. Ensuite, vous allez spécifier la télécommande que vous souhaitez supprimer. Et c'est ça. Cela a supprimé la télécommande. Lorsque nous avons exécuté la commande clone pour cloner un dépôt distant particulier, git a essentiellement créé un dépôt distant pour nous. Le nom de cette télécommande est origin, dont l'URL est l'URL que nous avons utilisée pour cloner le projet. Vous en saurez davantage sur les télécommandes au fur et à mesure que nous progresserons dans ce cours. Je te verrai ensuite. 71. 1001 Comprenez Git Fetch et ce sont des usecases: Parlons de git-fetch. Imaginez que c'est l'état actuel de notre projet dans un dépôt distant et local. Maintenant, mettez la vidéo en pause, prenez une minute et essayez de comprendre ce diagramme. Vous renouvelez tous cela. Eh bien, nous avons juste quelques commentaires dans la branche principale fois dans le dépôt local et le dépôt distant. Ensuite, nous avons un seul commit dans la branche de fonctionnalité à la fois dans le référentiel local et distant, sauf dans le dépôt local, nous avons également des branches de suivi supplémentaires qui représentent les branches dans le dépôt distant référentiel. Et actuellement, ils pointent exactement vers les mêmes comètes que celles vers lesquelles pointent les branches du dépôt distant correspondantes . Parlons de Git-Fetch. Imaginez qu'il y ait quelques commentaires supplémentaires dans la branche feature du dépôt distant. Et si je voulais télécharger les objets qui correspondent à ces comètes en même temps ? Je ne veux pas voir toutes ces modifications dans mon répertoire de travail. Maintenant, vous avez peut-être une question qui vous vient à l'esprit pour savoir pourquoi voulons-nous télécharger ces objets ? Mais je ne veux pas que ces modifications apparaissent dans un répertoire de travail. Eh bien, il existe de nombreux cas d'utilisation où cela peut être utile. Par exemple, supposons que je voudrais comparer mon dépôt local avec le dépôt distant pour vérifier combien de commentaires le dépôt distant est en avance sur mon dépôt local dans une branche particulière, ou vice versa. J'aimerais vérifier combien de commentaires mon dépôt local devance le dépôt distant dans une branche donnée ? Ou que se passe-t-il si je souhaite obtenir l'état exact du référentiel distant tel qu'il est dans mon inscription locale, pour commencer à travailler dessus ? En même temps. Je ne veux pas que cela ait d'incidence sur le travail que j'ai déjà fait localement. Ou il se peut que je veuille simplement vérifier s'il existe des branches ou des balises supplémentaires, des références présentes dans le dépôt distant mais non présentes dans le dépôt local. Eh bien, Git-Fetch est la solution. Lorsque vous exécutez la commande git fetch localement, elle télécharge tous les objets supplémentaires qui ne sont pas déjà présents dans votre dépôt local. Et mettez également à jour ces branches de suivi pour pointer vers ces nouveaux commits ou les nouveaux objets qui viennent d'être téléchargés avec git-fetch. Dans cet exemple, nous supposons simplement que nous avons des commentaires supplémentaires et une branche de fonctionnalité. Ainsi, seule la branche de suivi de la branche de fonctionnalité est mise à jour pour pointer exactement vers le même commit que les branches distantes pointant vers. Toutefois, s'il y a des commentaires supplémentaires dans d'autres branches, les branches de suivi correspondantes votre machine locale seront également mises à jour. Maintenant, le fait que les branches locales, comme la branche principale et la branche feature pointent toujours vers les anciens commits. Vous allez entrer dans cette pièce, vous n'aurez pas tous ces changements récemment introduits. Tout cela peut vous sembler très déroutant, mais dans les prochaines conférences, vous comprendrez parfaitement pourquoi nous avons besoin git-fetch et vous en comprendrez la signification. Je ne peux pas tout placer sous une seule vidéo. Je te verrai ensuite. 72. 1002 Git Fetch dans Action Part1 (variations de commandes Vérifier le statut avec les commandes): Bon, voyons comment fonctionne git fetch. Je suis actuellement connecté en tant que propriétaire du dépôt. Et juste pour votre information, les dépôts locaux et distants sont actuellement exactement les mêmes. Aucun commentaire supplémentaire n' a été fait à aucun des endroits. Permettez-moi maintenant d'aller dans le dépôt public et de faire un nouveau commit. Nous pouvons le faire dans la branche principale ou dans la branche feature. Je vais simplement ajouter un nouveau fichier. Je voudrais le nommer comme peut-être Apple point dx, dy. Peu importe que vous souhaitiez inclure un dossier et simplement indiquer le nom du dossier. Peut-être. Comme envoyer une barre oblique à un nouveau fournisseur. Cela créerait un dossier avec le nom My Folder à l'intérieur duquel se trouvera ce fichier avec le nom apple point TXT. Je voudrais simplement commenter le dossier. Cliquez sur Commit. Nous venons de créer un commentaire. Permettez-moi maintenant de créer également une branche. Laissez-moi d'abord passer à la branche principale. Parce que ça vient de là. J'aimerais créer une nouvelle branche. Ce type dans le nom de la branche que j'aimerais faire , peut-être en comporte deux. Et puis ici, nous obtenons une option pour créer une fonctionnalité de branche, cliquons dessus. Et cela devrait créer une fonctionnalité vers une branche. Permettez-moi de revenir à la branche nouvelle fonctionnalité et de cliquer sur la liste des commentaires. Voici le commit que nous venons de faire, dont le hachage commence par E8, AF, peu importe. Passons maintenant à l'inscription locale. Maintenant, vous devez imaginer que c' est l'un des ordinateurs de l' employé, peut-être celui de M. Luke, peu importe. Maintenant, avant de faire git fetch, laissez-moi exécuter la commande git log. Et remarquez que je suis actuellement dans la branche des nouvelles fonctionnalités. Ici. Comme vous pouvez le voir, la nouvelle branche de fonctionnalité, qui est la branche locale, pointe vers ce commit particulier. Et même la branche de suivi pointe vers ce commit. Maintenant, une fois que j'ai fait git fetch, il devrait télécharger tous les objets supplémentaires présents dans le dépôt distant et également mettre à jour cette branche de suivi pour pointer vers cet objet commit. Voyons voir si ça arrive. Mais avant cela, laissez-moi une autre commande pour vérifier les détails de la télécommande d'origine. Git, distant, affiche l'origine. Cela affichera les informations relatives à la télécommande d'origine. Laissez-moi vous expliquer ce qui est affiché ici. Nous avons le fetchone, qui est récupéré dans le fichier de configuration, pousse quelque chose dont nous n'avons pas encore parlé. Mais lorsque nous utilisons la commande push, il s'agit d'une URL qui doit être utilisée pour pousser nos modifications locales. Branches de tête pointant vers la branche principale, qui possède une branche par défaut, comme nous l'avons vu précédemment. Voici la liste des succursales. Il s'agit des branches disponibles dans le référentiel distant. Si vous remarquez, pour la nouvelle branche qui a été créée dans le GitHub, Twitter vers la branche. Il indique que la prochaine récupération sera stockée dans l'origine de la barre oblique distante. Cela signifie que lorsque nous récupérons, git créera une branche de suivi pour la fonctionnalité à branche qui est présente dans le dépôt GitHub distant. Cependant, la branche principale et la branche nouvelle fonctionnalité, ce qui a déjà été suivi. Voici la liste des branches locales configurées pour git pull. Nous allons bientôt parler de Good Pull. Voici les branches pour git push. Nous n'avons pas cette branche ici parce que nous n'avons pas encore récupéré de dettes et que nous n'avons pas vérifié dans cette succursale. Voyons maintenant ce qui se passerait si je faisais git fetch. Eh bien, idéalement, je dois spécifier le nom de la télécommande à partir de laquelle je voudrais récupérer les objets. Mais si je ne spécifie rien, il s'agirait par défaut de la télécommande d'origine, que nous avons déjà. Si vous souhaitez récupérer des objets correspondant à une branche spécifique sur une télécommande spécifique. Ensuite, la syntaxe pour cela est que vous allez spécifier l'origine distante dans ce cas. Ensuite, il vous suffit de spécifier le nom de la branche, par exemple, new feature ou autre. Si vous souhaitez télécharger des objets pour toutes les distantes et toutes les branches, il vous suffit d'utiliser l'option. Tout. Actuellement, nous n'avons qu'un seul village isolé d'origine. Je peux donc simplement exécuter cette commande telle quelle sans avoir à spécifier quoi que ce soit. Tous ces objets supplémentaires étaient donc téléchargés et décompressés localement. Et si vous remarquez, nous avons cette nouvelle branche, qui est fonction à branche pour laquelle une branche de suivi est créée. Et puis c'est une ligne importante. La nouvelle branche de fonctionnalité. Plus tôt, il indiquait ce commit en particulier. Mais maintenant, la nouvelle branche de suivi des fonctionnalités, ou la branche de suivi locale, pointe vers ce nouveau commit. agit du commit exact que nous avons effectué dans le dépôt distant il y a un instant. Le voici donc. C'est E8 un F E à E. Et c'est exactement pareil. Maintenant, laissez-moi réexécuter la commande remote show origin et voir ce qu'elle doit montrer par rapport à ce qu'elle a montré précédemment. Eh bien maintenant, si vous observez que la fonctionnalité vers branche est en cours de suivi, mais cette branche n'est toujours pas disponible dans cette liste. C'est parce que nous n'avons pas encore vérifié dans cette agence. Si j'obtiens la fonctionnalité 2 de Switch, vous pouvez également dire la fonctionnalité Git checkout. Nous passerions à cette branche. Et maintenant, si vous exécutez cette commande, vous verrez également cette branche dans cette liste. Permettez-moi de revenir à la nouvelle branche de fonctionnalité. Chaque fois que je passe à cette branche, vous voyez ce message qui indique que vos branches sont derrière la nouvelle fonctionnalité d'origine, qui est la branche de suivi par un commit, ce qui signifie que le référentiel distant est un commit avant notre agence de dépôt locale. Cela signifie également que nous pouvons réellement effectuer une fusion rapide, dont nous parlerons dans les prochaines conférences. Et cela nous suggère également d' utiliser git pull pour mettre à jour votre branche locale. Une fois que nous aurons mis à jour la branche locale avec un bon sondage ou avec l'opération de fusion, avec un bon sondage ou avec l'opération de fusion, vous verrez toutes ces nouvelles modifications disponibles dans le répertoire de travail. Pays, étant donné que les branches locales pointent toujours vers tous les commits, votre répertoire de travail n'est actuellement pas impacté du tout. Si je fais git log maintenant, vous verrez seulement que notre nouvelle branche locale de fonctionnalité pointe vers cet ancien commit. Plus tôt, si vous vous souvenez, nous avons également vu la branche de suivi pointant vers ce commit. Mais après la récupération, les branches de suivi pointent maintenant vers ce nouvel objet de validation qui a été téléchargé avec git-fetch. Je vais laisser, je te verrai ensuite. 73. 1003 Git Fetch in Action Part2 (Exploring refs FETCH HEAD): Ok, j'ai mentionné que git-fetch téléchargerait les objets et mettrait même à niveau les branches de suivi. Disons que si j'ai bien raison, laissez-moi aller sur GitHub et copier le HashCode du dernier commit en cliquant sur cette icône. Et je suis actuellement dans la branche des nouvelles fonctionnalités et sur GitHub. Laissez-moi aller à Git Bash et laissez-moi essayer d' imprimer cet objet, conserver le trait d'union P. Et puis je vais coller le HashCode que je viens de copier. Nous sommes donc en mesure de voir le contenu de l'objet commit, ce qui signifie que git-fetch a bien téléchargé cet objet. Si vous parcourez cet arbre parent de cet objet comète, vous devriez également être en mesure de localiser les objets blob et leur contenu correspondant. Voyons maintenant si les branches de craquage sont mises à jour. J'ai mentionné que les branches de suivi sont en fait conservées dans le fichier des toiles de fond. Ouvrons-le. Ici. Si vous remarquez, la nouvelle branche de fonctionnalité pointe toujours vers l'ancien commit. Ai-je tort de dire que les branches de suivi seraient mises à jour ? La réponse est non. Voyons ce qu'il y a dans ce répertoire. Origine distante et nouvelles références de fonctionnalités, origine distante. Et laissez-moi ouvrir le fichier avec le nom new feature. Et vous voyez ici le HashCode du dernier commit. Maintenant, pourquoi ce code de hachage est-il disponible ici mais pas disponible dans le fichier refs aura généralement tendance à stocker des références dans la structure de répertoire. Il n'est pas nécessairement toujours stocké dans un fichier compressé. Utilisez ce fichier compressé pour plus d'efficacité. Mais ça ne garantit pas comment il ne peut même pas prédire où il stockera les références. Il peut se trouver dans le fichier compressé ou sous la forme d'une structure de données. S'il stocke les différences dans un fichier compressé, il n'a pas besoin de créer la structure de répertoire juste pour stocker la référence. Tout est interne pour se lever. Et c'est l'un des exemples qui montrent pourquoi nous ne devrions pas trop nous inquiéter de la qualité des choses pour nous. Il suffit d'exécuter les commandes, de faire confiance et de s'y mettre. Vous avez peut-être remarqué ce fichier, fetch head, qui est créé lorsque vous effectuez l'opération de récupération. Voyons le contenu. C'est encore une fois pour cela que vous ne devriez pas trop vous inquiéter. Mais si vous remarquez que nous avons trois lignes, chacune correspondant à une branche individuelle, sauf la branche où nous avons tiré la commande git-fetch. Toutes les branches sont marquées comme pas pour beaucoup. Mais encore une fois, n'essayons pas de tout apprendre car vous risquez vous embrouiller et de ne pas être en mesure de comprendre les vrais concepts qui sont nécessaires. Mais ce fichier est généralement utilisé par Gibbs. Lorsque nous exécutons certaines commandes comme git pull par exemple, dont nous parlerons dans les prochaines conférences. Par exemple. Si vous utilisez git log, vous ne pouvez pas voir la ou les deux branches de suivi qui apparaissent au niveau des branches de suivi pointant vers. Mais si vous dites git log et récupérez la tête du trait de soulignement par exemple. Ensuite, il listera également l'objet comète où les branches de suivi pointent comme ça. De même, nous avons certaines commandes qui utiliseraient en interne le fichier d' en-tête fetch. Je te verrai ensuite. 74. 1004 Passage à l'État de Repo à distance: Maintenant, avec git-fetch, puisque nous avons téléchargé tous ces objets, nous pouvons vérifier le commit particulier et détacher ce qui est resté. De cette façon. Nous pouvons avoir le même état que le dépôt distant sans avoir à impacter notre travail existant. Laissez-moi vous montrer ce que je veux dire. Revenons à GitHub et laissez-moi passer à nouvelle branche de fonctionnalité et récupérer le code de hachage du dernier commit. En fait, quelques premiers caractères suffiraient. Dans Git Bash. Je vais dire git checkout. Voilà le HashCode. Cela devrait amener notre projet à détacher cet état. En gros, notre projet n'est pas exactement dans le même état qu'avec le dépôt distant. Si vous remarquez, nous avons ce fichier, le fichier Apple Dot TXT, qui est ce dont nous avons besoin. Si vous lisez ce message, vous pouvez voir qu'il indique que vous êtes détaché à l'état. Vous pouvez regarder autour de vous, apporter des modifications expérimentales et les valider. Et vous pouvez ignorer tous ces commentaires une fois que vous revenez à une autre branche. Je peux donc aller de l'avant et faire quelques commentaires. Est-ce que l'application ou importe quelle vésicule expérimente mes changements ? Et une fois que j'ai terminé, je peux simplement revenir à une branche afin que tous ces commentaires soient perdus. Si je veux conserver ces commentaires, je peux utiliser cette commande pour obtenir quel trait d'union Z. Et puis je vais spécifier un nom de la nouvelle branche. Donc cette commande créerait cette branche et tous ces commentaires dans leur tête ne pointent pas vers ce commit particulier, pas vers une branche particulière. Et c'est pourquoi il s'agit d'un État de tête détaché. Permettez-moi de revenir à la nouvelle branche de fonctionnalité. Nouvelle fonctionnalité. Et nous sortons de l'État de tête détaché. Vous ne voudriez bien sûr plus CD de fichier TXT apple dot. Maintenant, tu peux peut-être prendre ça comme une mission. Allez sur detach set state, faites quelques commentaires avant de revenir à une branche. Assurez-vous que ces modifications sont bien, les commentaires sont conservés dans une autre branche. Je te souhaite bonne chance. Je te verrai ensuite. 75. 1005 Fusionner les changements à l'aide de la TÊTE FETCH: Supposons que je souhaite avoir toutes les modifications du dépôt distant dans mon répertoire de travail. Peut-être parce que j' aimerais travailler dessus, ou peut-être simplement parce que j'aimerais avoir toutes les mises à jour à distance et ensuite continuer à travailler sur mes propres fichiers. Maintenant, j'ai une question pour toi. Que puis-je faire maintenant pour avoir toutes ces modifications dans mon répertoire de travail ? Avec Git-Fetch. Nous avons déjà téléchargé tous les objets. Nous n'avons pas à refaire ça. Que pouvons-nous faire d'autre ? Eh bien, nous pouvons effectuer une fusion. Nous avons la branche de suivi pour nouvelle fonctionnalité qui pointe vers la validation à distance. Et nous avons également la branche locale new feature, qui pointe vers l'ancien commit. Si nous fusionnons ces deux branches, nous devrions idéalement avoir toutes les modifications dans notre répertoire de travail, n'est-ce pas ? Tout d'abord, lançons la commande git status. Il indique que vos branches sont derrière la nouvelle fonctionnalité d'origine par un commit et peuvent être avancées rapidement si bien nous a donné une suggestion que nous pouvons réellement effectuer une fusion en avance rapide. Ce qui signifie également qu'il est également possible que nous devions effectuer une fusion en trois étapes. Et nous pourrions tout aussi bien avoir des conflits, auxquels nous devons faire face. Nous avons déjà vu comment nous gérons les conflits lorsque vous essayez de fusionner quelques branches. Il en va de même ici. Maintenant, pouvez-vous essayer deviner quelle commande je dois taper ici pour avoir toutes ces nouvelles modifications dans notre répertoire de travail. Eh bien, il s'agit d'une commande git merge standard. Nous devons d'abord pousser vers une branche laquelle nous voulons fusionner, dans ce cas, nous voulons fusionner les modifications une autre branche vers la branche nouvelle fonctionnalité locale. Et c'est là que j'en suis. Permettez-moi de taper la commande git merge. Et je vais spécifier la branche de suivi, qui est la nouvelle fonctionnalité de barre oblique d'origine. Essentiellement, nous effectuons simplement une fusion rapide dans ce cas, lequel notre nouvelle branche de fonctionnalité, qui est une branche locale, pointe maintenant exactement vers le même commit que le branches de suivi à distance pointant vers. Mais supposons que vous ayez également effectué un commit dans votre dépôt local. Eh bien, dans ce cas, vous devez effectuer une fusion à trois. Cela peut créer un commit de fusion supplémentaire à moins que vous ne rebasiez et que vous n'exécutiez ensuite une fusion en avance rapide. Appuyons sur Entrée. Voici un résumé de ce qui vient de se passer. Notre branche locale de nouvelle fonctionnalité ne pointe pas vers ce nouveau commit. Le même commit que la branche de suivi pointait. Ce qui vient de se passer, c'est une fusion rapide. Il s'agit d'un nouveau fichier que nous allons voir dans notre répertoire de travail. C'est ici. Je veux aussi rapidement mentionner que l'alternative à la commande pour cela est git merge, fetch underscore head. Cela fera le même travail. Et c'est l'une des commandes où good peut utiliser le fichier d'ajout de fetch. Nous en avions parlé tout à l'heure. Exécutez cette commande. Il est dit déjà à jour car nous avions déjà fusionné les modifications. J'espère que c'est logique. Je te verrai ensuite. 76. 1006 Utiliser le code Visusal Studio pour récupérer et fusionner: Voyons comment effectuer la récupération et écrivons en gros ce que nous avons appris jusqu'à présent dans ce chapitre de Visual Studio Code. Tout d'abord, assurez-vous que le projet est ouvert. Si votre projet n'apparaît pas ici, allez dans le menu Fichier et cliquez sur Ouvrir le dossier. Choisissez votre projet. Et tu devrais être prête à partir. Passons à la section de contrôle de source pour effectuer git-fetch. Cliquez sur cette icône. Et puis vous voyez un tas d'options. Allez dans pull, push section, puis vous verrez l'option pour récupérer les modifications. Une fois que vous cliquez dessus pour la première fois, se peut que vous receviez un message vous demandant si vous souhaitez que Visual Studio Code le fasse automatiquement à chaque fois . Vous pouvez dire oui, car git-fetch est considéré comme une opération sûre. Et comme cela n'aura aucune incidence sur votre répertoire de travail, vous pouvez l'exécuter en toute sécurité sans avoir à vous soucier de quoi que ce soit. Et une fois que vous avez fait cela, vous voyez un statut ici. Dans mon cas, j'en vois un, puis une flèche vers le bas 0, puis des vêtements. Je ne suis pas sûr que tu puisses voir ça. Mais une flèche vers le bas signifierait que nous avons des commits supplémentaires dans le dépôt distant, qui peuvent être fusionnés dans un dépôt local. 0 ou pyro signifie que nous n'avons pas d'engagement supplémentaire ou dépôt local dont nous avons besoin pour télécharger notre push vers le dépôt distant. Nous allons parler de la manière dont nous pouvons appliquer nos modifications au dépôt distant lors des prochaines conférences. Une fois cela fait, disons que vous avez décidé de jouer beaucoup. Nous allons utiliser ce plugin tiers pour cela. Et ici, vous pouvez voir que la branche de nouvelle fonctionnalité d'origine pointe vers ce commit et que notre branche locale de nouvelle fonctionnalité pointe vers ce commit particulier. Devine quoi maintenant ? Je dois fusionner ces deux branches pour avoir toutes les modifications distantes dans mon répertoire de travail. Donc, dans Visual Studio Code, je dois cliquer avec le bouton droit de la souris sur la branche que je veux fusionner. Ensuite, vous voyez cette option. Fusionnez dans la branche actuelle, nos branches actuelles, la nouvelle branche de fonctionnalités comme vous pouvez le voir ici. Alors cliquons dessus. Au fait, pour expliquer les choses qui ont ramené le projet à ce qu'il était avant la fusion. Cliquez donc dessus avec le bouton droit. Branche actuelle magenta. Nous avons déjà parlé de cette invite. C'est exactement la même invite. Rien de différent. Mais nous ne voulons pas créer de nouveau commentaire. Et maintenant, si vous allez dans l'arbre de travail, vous voyez ce fichier, ce que nous attendons. 77. 1007 Mettre à jour les références locales avec Git Fetch: Supposons que je souhaite supprimer une branche du dépôt distant. Quelles en seraient les conséquences ? Allons y jeter un œil. Tout d'abord, avant de supprimer la branche, vous devez vous assurer que toutes ces modifications sont fusionnées dans une autre branche. Vous devez également discuter avec toutes les personnes qui contribuent activement à cette branche en particulier. Avant de le supprimer. Allons-y et supprimons l'une des branches. Et je vais supprimer la fonctionnalité de branche en cliquant sur cette icône. Vous pouvez également supprimer une branche distante de votre machine locale, cela explosera dans les prochaines conférences. Disons que c'est l'un des ordinateurs des développeurs qui regarde peut-être ici si je lance la commande git remote show origin, vous remarquerez que Git a montré cette fonctionnalité comme obsolète. Et il nous a également indiqué d' utiliser cette commande git remote prone pour supprimer cette branche, promouvoir le système local. Vous pouvez également exécuter la commande git fetch broom. Avec cette commande, git se connectera au dépôt distant. Dans ce cas, il s'agirait par défaut de la télécommande d'origine. Ensuite, il supprimera toutes les différences dans votre inscription locale qui ne sont plus utilisées dans le référentiel distant. Maintenant, notez que cette commande supprimera uniquement les branches de suivi, mais pas vos branches locales. Votre agence locale resterait intacte. Nous allons donc exécuter cette commande. Cela a donc supprimé la branche de suivi. Si vous souhaitez faire la même chose à partir de Visual Studio Code, cliquez simplement sur cette icône. Allez à la section tirer, pousser. Et puis vous trouverez cette option qui dit « Fetch pruneau ». Cela ferait le même travail qu'avec cette commande. Maintenant que vous avez une pizza locale à brancher toujours intacte. Et vous pourriez tout aussi bien avoir votre propre ensemble de modifications ou de validations dans feature to branch. Eh bien, vous pouvez pousser tous ces commits vers le dépôt distant. De cette façon, cette branche serait recréée. Vous pouvez également intégrer ces commentaires une autre branche. Nous allons parler de git push dans les prochaines conférences. Mais nous allons essayer de relancer cette commande. Et il ne verrait plus fonctionnalité de branche dans la section des branches distantes. Permettez-moi de revenir sur GitHub et de restaurer cette branche. Encore une fois. Exécutez la commande Maintenant. Ensuite, il indique que lorsque nous effectuerons la prochaine extraction, il créera une nouvelle branche de suivi pour la fonctionnalité à créer. Faisons ça très vite. Et vous pouvez voir que la fonctionnalité vers branche est maintenant suivie elle se trouve essentiellement dans le même état qu'au début de cette vidéo. Je te verrai ensuite. 78. 1101 Comprendre Git Pull: Parlons de git pull. Maintenant dis-le avec moi. Git pull est égal à git-fetch plus git merge ou rebased selon l'option que nous choisissons. C'est essentiellement ce qui est bon Pull. C'est peut-être la vidéo la plus courte de tout le cours. Cependant, ce n'est peut-être pas aussi simple. Nous allons parler plus en détail de la bonne traction dans les prochaines conférences. Je te verrai ensuite. 79. 1102 Git Pull en action et observant ce qu'il fait: D'accord, disons que git pull en action. Je suis actuellement une nouvelle branche de fonctionnalités. Permettez-moi d'abord de l'essayer dans la commande git pull. Et ça dit déjà à jour. Cela signifie qu'il n'y a pas de commentaires supplémentaires et dépôt distant qui ne sont pas déjà présents dans notre dépôt local. Il s'agit donc d'abord de revenir au référentiel distant et de faire un nouveau commit dans la branche feature ou la nouvelle branche feature. Je vais modifier l'un des fichiers. Peu importe que vous ajoutiez un nouveau fichier ou que vous modifiiez un fichier existant. Le but est de faire un commit. Permettez-moi donc de cliquer sur cette icône pour modifier ce fichier. Je ne suis pas sûr que tu puisses voir ça. Permettez-moi de zoomer un peu. Permettez-moi donc d'ajouter une ligne de texte, quelque chose de ce genre. Peu importe ce que tu ajoutes. Cliquez sur Commit Changes. Si vous souhaitez obtenir le message, vous pouvez le modifier et cliquer sur Commit. Nous avons donc maintenant un dépôt de commit et un dépôt distant supplémentaires, mais cela n'est pas disponible sur notre machine locale. Maintenant, avant de lancer à nouveau la commande git pull, laissez-moi faire git log et voir ce qu'elle doit afficher. Comme vous pouvez le voir, la nouvelle fonctionnalité ainsi que la nouvelle fonctionnalité d'origine, qui est la branche de suivi, pointent exactement vers le même commit. Laissez-moi effacer l'écran et exécuter la commande git pull. Comme vous pouvez le voir au départ, il a effectué l' opération git fetch et a décompressé les nouveaux objets. Ce sont donc les objets qui ont été téléchargés depuis le dépôt distant. Il existe un total de trois objets, qui incluent également des objets commit, trois objets, des objets blob, etc. Et puis il est allé de l'avant et a effectué une fusion en avant rapide dans ce cas. Comme la fusion rapide fonctionne dans ce cas, nous n'avons aucun commit dans une branche locale. pourquoi git a effectué une fusion rapide pour nous. Maintenant, si je fais git log, vous pouvez voir que la nouvelle branche locale de fonctionnalité, ainsi que la branche de suivi, pointent vers ce nouveau commit, qui est exactement le commit qui a été fait juste un instant il y a. C'est F Phi Double D, peu importe. Et c'est le même HashCode que vous voyez ici. Auparavant, avec git-fetch, notre branche locale n'était pas mise à jour. Mais avec git pull, nous avons non seulement récupéré tous les objets et références, mais nous avons également mis à jour la branche point actuellement cochée. Une chose que je dois mentionner est que toute bonne commande pull téléchargerait les objets et les références appartenant à plusieurs branches ou même à des télécommandes. Il va fonctionner beaucoup sur la branche actuellement récupérée. Donc, lorsque nous avons fait git pull, cela équivaut à git pull origin car c'est uniquement le mode qui est actuellement configuré et c' est le mode par défaut. Mais si vous le souhaitez, vous pouvez également spécifier la télécommande à partir de laquelle vous souhaitez récupérer les objets. Ensuite, effectuez la fusion sur la branche point actuellement cochée, qui dans ce cas est la nouvelle branche de fonction. Je te verrai ensuite. 80. 1103 Comprendre Git Pull avec la fusion 3way: Voyons maintenant ce qui se passerait si nous avions des commits effectués à la fois dans un dépôt distant et local. Cela permet de simuler un scénario dans lequel vous pouvez avoir effectué des validations dans votre dépôt local, ainsi que quelques commentaires faits dans le dépôt distant peuvent également provenir d'autres développeurs. Afin de simuler ce comportement, essayons d'abord de faire un commit dans notre dépôt local. Si je lance git pull, vous voyez que notre dépôt est déjà à jour. Laisse-moi vite, j'ai fait un des dossiers ici. Modifions ce fichier, par exemple. J'ai enregistré le fichier, il reste. Vous pouvez faire tout cela à partir de Visual Studio Code, mais je préfère faire depuis Git Bash. Je me sens plus comme un programmeur quand je le fais à partir de Git Bash qu' en utilisant Visual Studio Code. Alors git add apple point TXT. Bon message de validation. Et nous avons pris notre engagement. Allons dans notre dépôt distant et apportons quelques modifications au fichier input.txt. Peut-être que j'aimerais ajouter une ligne de texte de plus. Et validez ces changements. Maintenant pouvez-vous vous attendre au comportement lorsque nous avons essayé de faire git pull ? Maintenant, imaginons que nous exécutions git-fetch, puis que nous exécutions git merge. Ce que vous pensez arriver est exactement ce qui se passerait si vous exécutiez la commande git pull. En fait, nous n'avons pas besoin de spécifier le mode. Comme vous pouvez le constater, cela nous a incités à choisir le message. Peux-tu deviner de quoi il s'agit ? Eh bien, c'est le message que get nous demande d'utiliser le nouvel objet de commit de fusion qu' il va créer. Cela a essentiellement effectué une fusion à trois voies. Et get va maintenant créer également le commit de fusion. Disons que je suis satisfait de ce message. Je vais simplement clore ça. Et la commande continuerait à s' exécuter. Cette fois-ci. Si je fais git log, vous pouvez voir que la branche locale pointe vers le nouveau commit de fusion. Mais la branche de suivi, comme prévu, pointe toujours vers le commit vers lequel pointe sa branche distante correspondante. agit du commit que nous venons de télécharger depuis le dépôt distant. Maintenant, que se passe-t-il si je ne veux pas que ce commit de fusion supplémentaire soit créé par git, rebase est la solution. C'est ce dont nous allons parler dans notre prochaine vidéo. Je te verrai ensuite. 81. 1104 GIt tirer avec rebase et ses implications: Voyons comment nous pouvons utiliser rebase avec git pull. Si je lance la commande git pull, vous pouvez voir qu'elle est déjà à jour. n'y a aucun objet supplémentaire à télécharger depuis le référentiel distant. Mais laissez-moi essayer de faire un commit dans le dépôt distant. Et 1 seconde, je vais simplement éditer ce fichier et faire un commit. Comme ça. Permettez-moi également de m'engager dans notre dépôt local. Je vais modifier ce fichier à l'aide de l'éditeur VI. Vous pouvez utiliser le Bloc-notes ou Visual Studio Code. C'est à toi de décider. Pour préparer ce fichier, git commit. Essayons maintenant de faire l'option git pull rebase et voyons ce qui va se passer. Depuis que vous effectuez la fusion, obtenez le mot. Essayez maintenant d'effectuer un rebasage. Cette commande télécharge tous les objets et les commet. Essentiellement, notre branche locale serait dans le même état qu'avec cette branche dans le dépôt distant. Ensuite, get réappliquera tous les commits de limite locale un par un. Après ça. Je vais te montrer ce que je veux dire. Cela a donc téléchargé les objets et effectué un rebasage. Mais si vous exécutez la commande git log maintenant, vous remarquerez que tous ces commentaires jusqu'ici sont essentiellement les mêmes que le commerce que nous avons dans le dépôt distant. Et en plus de cela, get a réappliqué les commentaires locaux. C'est la même chose que vous avez cloné le projet à partir d'un dépôt distant. Ensuite, vous avez effectué vos validations locales une par une. Cela peut être mieux vu dans Visual Studio Code avec le plug-in Git. Nous en sommes donc là. Comme vous pouvez le voir, comment ces commentaires en bas appartiennent au dépôt distant. Vous pouvez le voir en regardant la section auto. Tous ces commentaires ont donc été faits par Centre Corp. Et en plus de cela, il a rebasé nos commits locaux sur les commits distants. Et c'est pourquoi ils les ont poursuivis. Mais si vous remarquez, nous n'avons pas le commit de fusion que nous avions précédemment. Mais c'est le but de rebase, qui est essentiellement de ne pas avoir ces commits de fusion. Rebase réécrit essentiellement vos commits et même HashCode ne serait pas le même. Par exemple, si vous regardez le dernier commit que vous avez créé en dépôt local, le HashCode actuel est phi pour être n'importe quoi. Si vous deviez jeter un œil à ce commit exact avant de rebaser, le HashCode aurait été différent. C'est la raison pour laquelle tout le rebased rend notre historique des commits plus linéaire. Il ne devrait pas être rebasé si toutes vos modifications ont déjà été publiées dans le dépôt distant. Nous allons parler de git push et de la façon dont nous pouvons pousser vos commits locaux vers le dépôt distant dans les prochaines conférences. Ensuite, vous aurez une meilleure idée de ce dont je parle. Je te verrai ensuite. 82. 1105 Traiter les conflits avec la rebase de Git Pull: Voyons ce qui se passerait s'il y avait des conflits lors de son exécution. Pour cela, permettez-moi de modifier à nouveau ce fichier. Je vais simplement ajouter une ligne de code supplémentaire, comme ça. Et validez les modifications. Nous avons modifié un fichier TXT info point. Permettez-moi de lire le même fichier même dans mon dépôt local ou sur mon ordinateur local. Permettez-moi d'ajouter une ligne de texte comme pour enregistrer le fichier, le préparer et effectuer un commit. Nouvelle modification, fichier info, peu importe. Maintenant, laissez-moi essayer git pull et nous devrions avoir un conflit. Je veux utiliser l'option rebase parce que je ne voulais pas voir le commit de fusion. Mais c'est à toi de décider. Et comme vous pouvez le voir, notre dépôt est passé en état de rebase. Si nous ne fournissions pas cette option, cela aurait été la fusion de l'état a. La façon dont nous devons résoudre les conflits d'une manière ou d'une autre. Nous avons déjà vu comment résoudre les conflits dans gets off, merge et rebasage dans nos chapitres précédents. Il en va de même ici. Vous pouvez donc décider de résoudre les conflits ou utiliser cette commande pour ignorer le commit à l'origine du conflit. C'est exactement ce que je vais faire. Mais si vous voulez modifier et résoudre les conflits, vous savez déjà comment procéder. Le rebasage a réussi. Et quand je fais git log et que je ne vois pas le commit que nous venons de faire dans notre dépôt local. C'est parce que nous avions fourni les options skip pour ignorer le commit qui provoque la fin du conflit. On ne voit pas ça apparaître. Mais si vous remarquez que les branches de suivi pointent vers le dernier commit dans le dépôt distant, j'espère que cela a du sens. Je te verrai ensuite. 83. 1106 Utilisation du Stashing et de la réinitialisation du Hard: Parlons de l' importance de la mise en réserve. Supposons que nous ayons un nouveau comité et dépôt distant. Pour ça. Permettez-moi de modifier le fichier TXT d'entrée et d'ajouter une ligne de texte. Comme ça. Commettez les modifications. Et supposons que dans mon inscription locale, je vais modifier le même fichier et ajouter une ligne de texte comme ça, enregistrer le fichier et le fermer. Maintenant, si je vais dans Git Bash et que je dois exécuter la commande git pull, remarquez que je n'ai pas mis en scène ou validé ces modifications. Je ne veux pas les engager parce que je suis toujours en train de travailler dessus. En même temps, j'aimerais récupérer toutes les modifications du dépôt distant pour mettre à jour mon répertoire de travail. Lorsque j'exécute cette commande, vous verrez que Fetch s'est bien passé, mais que la fusion n'a pas eu lieu. Il indique que vos modifications locales apportées aux fichiers suivants seront remplacées par la fusion. Dans for R dxdy, veuillez valider vos modifications et les stocker avant de les fusionner, et donc l'opération de modification a été abandonnée. Essentiellement, confondez ce qu'il faut faire avec ces modifications non validées. Une solution à cela est, et c'est quelque chose qui n'est pas recommandé. La commande que je suis sur le point d'exécuter peut en fait supprimer tout le travail que vous avez fait jusqu'à présent sur votre machine locale. Cela inclut également les modifications que nous venons introduire dans for art file. s'agit évidemment pas d'une approche recommandée. Mais laissez-moi vous montrer la commande git reset. Nous avons déjà utilisé cette commande par le passé. Et ensuite, vous allez fournir l'option difficile. Et vous devez spécifier la télécommande. Voyons ce que ça va donner. Si je tape git log, vous verrez tous les commentaires que nous avons faits localement ou qui ont disparu pour de bon. Et c'est pour cela que cette commande est très dangereuse. Mais cela avait pour but de pouvoir récupérer les modifications depuis le dépôt distant. Si vous allez ici, vous verrez que nous n'avons que ces deux fichiers. Faisons git pull pour récupérer toutes les modifications depuis le dépôt distant. Notre répertoire de travail est maintenant à jour. Fondamentalement, notre dépôt local ainsi que notre dépôt distant, ou exactement dans le même état. Mais ce n'est évidemment pas l' approche recommandée. Essayons donc de recréer le même scénario une fois de plus. Laissez-moi vous expliquer comment nous devons y faire face. Je ne veux pas valider ces modifications. Mais en même temps, j'aimerais obtenir les mises à jour depuis le dépôt distant. Permettez-moi de revenir sur GitHub et de modifier ce fichier une fois de plus. Peu importe. Essayons maintenant de faire git pull. Et évidemment, encore une fois, vous allez voir beaucoup de choses avortées. Comme ça. Quelle est donc la solution à l'heure actuelle ? La solution est la commande git stash. En gros, cette commande stocke temporairement nos modifications locales quelque part et nous pouvons les récupérer quand nous le voulons. Pour l'instant, étant donné que nos changements locaux causent des problèmes. Pour récupérer les modifications depuis le dépôt distant, laissez-moi les stocker. Comme vous pouvez le voir, enregistrer la marche dans un arbre et la date d'index, progression du travail sur la nouvelle fonctionnalité. Il pointe vers le fichier input.txt. Si vous ouvrez un fichier TXT point complet maintenant, vous ne verrez pas les modifications que je viens d'introduire. Maintenant, nous pouvons aller de l'avant et faire git rebase. Retournez dans le répertoire de travail. Vous devriez voir toutes les modifications de la télécommande. Nous pouvons maintenant ramener toutes les modifications sur lesquelles je travaillais précédemment avec la commande git stash, pop. Maintenant, évidemment, nous allons avoir le complexe peut revenir en arrière et ouvrir le fichier input.txt. Vous verrez que ce sont les changements qui viennent de l'amont. En amont comme dans le dépôt distant. Nous pouvons décider des modifications que nous voulons continuer à modifier ce fichier, comme la cellule, fermer le fichier, conserver le fichier. État de Git. Maintenant, si je décide de valider mes modifications, je peux le faire. Mais capable d'extraire les modifications du dépôt distant sans avoir à valider nos modifications existantes. 84. 1201 Tout configurer pour contribuer à Ajouter des identifiants de configuration du collaborateur et à la création de c: Voyons comment nous pouvons pousser nos modifications locales ou les validations locales vers le dépôt distant afin que tous les autres membres de l'équipe puissent réellement télécharger ces modifications et les utiliser toutes, commencer à les suivre. Maintenant, afin de mieux expliquer les choses, nettoyons les choses et faisons tout à partir de zéro comme si quelqu'un venait de rejoindre l'équipe et voulait contribuer à notre dépôt. Tout d'abord, permettez-moi de me connecter en tant que propriétaire du dépôt. Je me suis connecté en tant que Sunda. Il s'agit du compte GitHub de Saunders. Voici le propriétaire de ce dépôt public. Je vais dans les paramètres , puis je vais ajouter M. Luke en tant que collaborateur. J'attends une contribution de M. Luke pour ce dépôt. Comme vous pouvez le constater, nous venons d'ajouter M. Luke en tant que collaborateur. J'ai également supprimé toutes les branches que nous avions créées précédemment, sauf que j'ai laissé la branche principale telle quelle. Nous avons donc actuellement une succursale. Toutes les branches ont été supprimées. Juste pour que nous comprenions tout propre et clair. Passons maintenant au compte de Luke. Vous pouvez dire que c'est récit de Luke parce qu'il a le thème blanc. Voici l'e-mail que under a reçu pour accepter l'invitation à devenir collaborateur sur ce projet. C'est exactement ce que je vais faire. La prochaine chose que cette boucle doit faire est copier le lien HTTPS et de cloner le projet. Dans ce but, vous avez créé un nouveau répertoire avec le nom get. Et c'est là que nous allons faire des expériences. Permettez-moi de lancer Git Bash ici. Et clonons le git clone du projet. Ensuite, je vais coller l'URL. Cela va cloner le dépôt. Une autre chose dont nous devons nous assurer concerne les informations d'identification. Tapons la commande git config list option afin que nous puissions voir toutes les configurations. Et comme vous pouvez le voir, le nom d'utilisateur est mon nom et l'e-mail est quelque chose de différent, pas celui de Luke. Maintenant, il n'est pas obligatoire mettre à jour ces informations d'identification. Mais quelles sont les références que vous donnez ici c'est ce qui se refléterait également dans des objets concrets. Ainsi, lorsque vous effectuez des validations locales, ces informations d'identification sont enregistrées et mêmes informations d'identification sont visibles même sur le référentiel distant. Une fois que vous avez poussé tous ces commits vers le dépôt distant, il est plus logique d' avoir les informations d'identification de Luke ici, car c'est lui qui contribue au dépôt. Allons-y donc et modifions-nous ces informations d'identification. Nom d'utilisateur. Je vais donner le même nom d'utilisateur que le compte GitHub de Luke. C'est aussi changer l' e-mail en celui de Luke. Comme ça. Maintenant, si vous vérifiez les informations d'identification, vous pouvez voir que ceux qui sont mis à jour. Supposons maintenant que Luke a été chargé de travailler sur la première caractéristique. Devine ce qu'il va faire ? Eh bien, il créerait une autre branche et apporterait tous les changements liés à la fonctionnalité 1. Faisons ça très vite. Je vais le faire à partir du code Visual Studio. Si tu le souhaites. Vous pouvez également le faire depuis Git Bash. Je vais ouvrir le dossier avec VS Code. Et peut-être que je vais simplement ajouter un fichier supplémentaire. Mais avant cela, nous devons créer une branche. Comme vous pouvez le voir, nous sommes actuellement dans la branche principale. Permettez-moi de cliquer dessus et de saisir la première caractéristique. Nous n'avons pas encore cette agence. Nous n'avons pas cette branche même dans le dépôt distant. Laissez-moi choisir cette option pour créer cette branche pour nous. Visual Studio Code a créé cette branche et a également basculé vers cette branche. Permettez-moi maintenant d'ajouter un fichier. Appelons-le produit point TXT. Ligne 1, caractéristique 1, quelque chose de ce genre. Je vais utiliser le même texte que le message de validation. Laissez-nous entrer le message et valider ces modifications dans la branche locale de la fonctionnalité 1. Faisons peut-être aussi une autre ligne de commentaire pour aimer quand la copier et l'avoir comme message pour cette comète. Regardons le graphique. Comme vous pouvez le voir, nous avons la branche principale ici et la branche fonctionnalité, qui est quelques commentaires en avance sur la branche principale. Supposons que Luke ait fait tout ce qu'il devait faire pour le premier long métrage. Il a testé tous ces changements localement. Et maintenant, il est prêt à contribuer ou à pousser tous ces commits vers le dépôt distant. parlerons ensuite de la façon dont il va procéder. 85. 1202 Créer une succursale distante et pousser les changements à l'aide de Git Bash et de VSCode Poussez tous les services: Actuellement, nous avons une branche qui a été créée localement, et nous y avons même fait un tas de commentaires. Voyons maintenant comment nous pouvons pousser tous ces commits vers le dépôt distant. Mais avant de faire quoi que ce soit, c'est très important. Vous devez vous assurer de récupérer toutes les modifications du référentiel et de rebaser, quelle que soit la marque dans laquelle vous souhaitez fusionner votre fonctionnalité dans une branche. Vous devriez récupérer toutes les modifications de cette branche et reconstruire votre fonctionnalité d' une branche vers cette branche. Cela aura donc un historique linéaire des commits. Et si vous rencontrez des conflits, veuillez les résoudre afin de veuillez les résoudre afin ne pas avoir de conflits lorsque vous poussez toutes vos modifications ou que poussez toutes vos modifications ou téléchargez toutes vos modifications dans le référentiel distant. Nous avons déjà vu comment cela peut être fait dans notre chapitre précédent. Dans notre cas cependant, la branche principale et la fonctionnalité sur la branche n'ont pas été divulguées. Cela n'a pas de sens pour moi de me rebaser. Voyons maintenant comment appliquer nos modifications au dépôt distant. Voyons d'abord comment nous pouvons le faire à partir de Git Bash. Permettez-moi de vider l'écran. Voyons d'abord dans ce répertoire. Et je suis actuellement dans la branche vedette un, comme vous pouvez le voir ici. Mais cela n'a pas vraiment d'importance pour la commande que nous allons exécuter. Je vais dire git push et obtenir ceci disant que la fonctionnalité de branche actuelle n' a pas de branche en amont. En d'autres termes, cela signifie que nous n' avons pas de branche feature one dans le dépôt distant pour pousser la branche actuelle et définir la branche distante en amont. Utilisez cette commande en particulier. Permettez-moi donc de le copier et de le coller ici. Cette commande créerait donc essentiellement une branche dans le dépôt distant, poussant tous les commits que nous avons dans cette branche. Origin est la télécommande que nous utilisons. Si vous souhaitez utiliser une autre télécommande, vous pouvez spécifier le nom ici. Et cette option nous permettra de créer la branche dans le dépôt distant. Cette commande créera également la branche principale de la piste et tout le dépôt local pour branche feature one représentant la branche feature one dans le référentiel distant. Essayons d'exécuter cette commande. Git a essentiellement compressé tous les objets et les a téléchargés dans le dépôt distant. Et c'est l'URI qu'il a utilisé pour pousser tous nos commits. En plus de cela, elle a également créé une branche de suivi pour nous. Et il nous suggère également de créer ce que l'on appelle une pull request. En accédant à cette URL. Nous allons parler des pull requests dans les prochaines conférences. Mais pour l'instant, allons dans le dépôt GitHub et voyons si les choses se sont reflétées là-bas. Permettez-moi de rafraîchir cette page. Et maintenant, vous voyez deux branches. Et nous pouvons même passer à une branche comme celle-ci. Et vous voyez, pour les comètes ici, deux d'entre elles appartiennent à la branche principale. Et puis il y a quelques commentaires dans la branche feature one. Laissez-nous rapidement faire un dernier commentaire et voir comment nous pouvons appliquer nos modifications à l'aide du code Visual Studio. Permettez-moi simplement d'ajouter une ligne de code ou de texte supplémentaire. Comme ça. Je vais utiliser le même texte que le message de validation. Permettez-moi de sauvegarder ce fichier et de valider nos modifications. Nous venons donc de faire un autre commit. Cette fois, je vais utiliser Visual Studio Code pour appliquer nos modifications. Vous voyez cette option, poussez. Puisque nous n'avons qu'une seule télécommande, qui est l'origine du nom. Par défaut, cela a été poussé vers la seule télécommande disponible. Si vous aviez configuré plusieurs télécommandes, vous auriez alors la possibilité choisir la télécommande sur laquelle vous souhaitez transférer toutes ces modifications en 1 seconde. Retournons nous lever. Et si je rafraîchis la page, vous verrez également ce nouveau commit. Il peut arriver que vous souhaitiez appliquer des modifications appartenant à plusieurs branches. Dans ce cas, vous pouvez utiliser l'option pour pousser toutes les modifications appartenant à plusieurs branches. Toutefois, elle n'est pas recommandée. C'est toujours une bonne idée de gérer une succursale à la fois. Je dois également mentionner que la première fois que vous essayez de pousser des modifications, vous pourriez recevoir une invite pour vous connecter à votre compte GitHub. Dans mon cas, je n'ai pas obtenu ce marron parce que je me suis déjà connecté auparavant. Laissez-moi vous montrer ce que je veux dire. Permettez-moi d'ouvrir Credential Manager sous Windows en effectuant une recherche dans le menu Démarrer. Et si je vais sur les informations d'identification Windows, vous en verrez une pour GitHub. Et cela a enregistré les informations d'identification du compte de Luke. C'est parce que j' étais déjà connecté et que Windows est capable de stocker toutes ces informations d'identification afin que je n'aie pas à les saisir. Chaque fois que j'essayais d'interagir avec le dépôt distant. Si vous voyez un 403 pendant l'exécution de la commande, essayez de supprimer ces informations d'identification puis réessayez d'exécuter la commande. Donc, ce que vous serez invité à vous connecter une fois de plus, connectez-vous et vous devriez être prêt à partir. Permettez-moi de l'enlever. Et laisse-moi essayer de pousser les changements. Et comme vous pouvez le voir, j'ai reçu cette invite pour l'authentification. Permettez-moi d'aller sur le compte GitHub de Luke, github.com, l'appareil barre oblique de connexion. Permettez-moi de saisir ce code ici. Contrôlez C et contrôlez V, continuez. Et de l'arthrite. Nous sommes entrés dans le bus, l' appareil alimentaire a été authentifié. Et bien sûr, puisque nous n'avons rien à pousser, considérez ce message disant que tout est à jour. Mais si vous revenez ici, vous allez voir cette entrée une fois de plus. Je te verrai ensuite. 86. 1203 Comprendre la demande de traction pour augmenter une demande de traction: Ok, jusqu'à présent, nous avons créé une branche de fonctionnalité locale et avons ensuite fait un tas de validations dedans. Et nous avons même transféré toutes ces modifications au dépôt distant. Et voici tous ces changements dans le dépôt distant depuis le compte GitHub. Bien entendu, étant donné qu' il s'agit d'un dépôt public, n'importe qui peut voir tous ces changements. Maintenant, loop ne peut pas simplement essayer de faire émerger tous ces changements sur la branche principale. Certaines pratiques doivent être suivies. Et ces pratiques sont en place pour s'assurer que ce qui entre dans le courant dominant de l'évolution, qui est la branche principale, est du code propre. Donc, ce que nous devons faire ensuite avant de fusionner cette fonctionnalité que l'on change dans la branche principale, c'est de lancer une pull request. Qu'est-ce qu'une pull request ? Vous pouvez considérer la pull request comme une demande de révision. gros, vous demandez à quelqu'un, en d'autres termes, à un votre équipe, à d'autres collaborateurs ou au propriétaire du dépôt de vérifier toutes vos modifications avant de les fusionner dans le mainstream of evolution, la branche principale. Et vous vous demandez peut-être pourquoi cela s'appelle une pull request. Ce mot peut avoir du sens au fur et à mesure que nous progressons dans ce cours. Mais pour l'instant, vous pouvez le considérer comme une demande d' extraction de toutes vos modifications de fonctionnalité 1 dans la branche principale. Voyons donc comment nous pouvons lancer une pull request. Je suis actuellement connecté au compte GitHub de Luke. Je veux aller dans cette section, les pull requests. Actuellement, nous n' avons pas de quiz sur les produits. Créons-en un en cliquant sur ce bouton. Nouvelle pull request. Ici, nous allons remplir toutes les modifications que nous avons apportées dans la branche feature one. Comment allons-nous faire cela en comparant notre fonctionnalité une branche avec l'une des autres branches. Dans ce cas, nous allons comparer la branche feature one avec la branche principale. La différence entre les deux réside donc dans les modifications que nous avons introduites dans feature on branch. Ici, je choisis la branche principale comme l'une des branches. Et l'autre branche serait une branche. Vous allez donc dire liste des modifications introduites et présenter une branche car ce sont les modifications qui n'étaient pas présentes dans la branche principale. Et si vous aviez plusieurs fichiers impliqués dans toutes ces modifications, vous verriez également toutes ces modifications ici. Mais puisque tout notre génie est entré dans un seul dossier, c'est ce que vous voyez ici. Et il est indiqué d'afficher un fichier modifié. Quoi qu'il en soit, voici toute la liste des commits, tous les fichiers qui ont réellement été modifiés avec tous ces commentaires. Allons-y et créons une pull request. Nous pouvons rédiger un bref résumé de ce qu'est cette pull request. Voici la fonctionnalité 1, quelque chose de ce genre. Si vous le souhaitez, vous pouvez également laisser un commentaire. Et cliquons sur Create Pull Request. Maintenant, nous obtenons cette option qui dit « merge pull requests ». Et si je clique sur l'une de ces options, cela va en fait fusionner toutes les fonctionnalités que l'on change dans la branche principale. Toutefois, ce n'est pas une bonne pratique. Idéalement, nous voulons que quelqu'un les révise ou les modifie avant de les fusionner dans le courant dominant de l'évolution. À ce stade, Luke est en mesure de fusionner tous ces changements. Il existe un moyen de restreindre cela et nous allons en parler ensuite. 87. 1204 Comprendre les succursales protégées Appliquer la règle de protection des succursales ?: Voyons comment empêcher Luke de fusionner le code à moins qu'il n'y ait au moins une révision effectuée par quelqu'un d'autre. Pour cela, laissez-moi aller sur un compte GitHub crépuscule. Je vais aller dans la section des paramètres de ce dépôt. J'ai une section à deux succursales. Et ici, je vais ajouter ce que l' on appelle des règles de protection des branches. Lorsque j'ajoute au moins une règle de prédiction de branche pour une branche particulière, cette branche est appelée branche protégée. Toutes les branches pour lesquelles nous n'avons pas de règles de prédiction de branche ou de branches non protégées. Il suffit d'être conscient de ces terminologies. Ils vous seront utiles dans un moment. Permettez-moi donc de cliquer sur ce bouton qui indique les règles de production Add Branch. Ici, nous pouvons spécifier le modèle de branche. Dans ce cas, je vais simplement dire principal. Ainsi, toutes les branches qui correspondent à ce modèle auront toutes ces règles de production appliquées. Bien entendu, seules les règles que nous avons activées ici seraient appliquées aux branches qui correspondent à ce modèle. Nous allons maintenant parler de certaines de ces règles lors des prochaines conférences. Mais pour l'instant, je voudrais imposer une restriction selon laquelle révision de l' atlas one doit être effectuée avant de fusionner les modifications dans la branche principale. Je vais donc activer cette option qui indique qu' une pull request est requise avant la fusion. Et la description indique que lorsque nous activons cette option, validations Hall doivent être effectuées dans une branche non protégée. Dans ce cas, nous ciblons la branche principale. Je vais appliquer cette règle de protection de branche sur la branche principale. Ainsi, lorsque cette option est activée, personne ne sera en mesure de valider directement dans la branche principale. Ce qu'ils doivent faire, c'est qu'ils doivent d' abord valider tous les changements dans la branche non protégée. Par exemple, mettez en place une branche qui n'est pas protégée, puis lancez une pull request pour fusionner toutes ces modifications dans la branche principale. C'est ce que dit cette option. Si cela semble déroutant, je vous demanderais de revenir en arrière et de regarder cette vidéo une fois de plus jusqu'à ce que vous compreniez. Ensuite, nous avons cette option qui indique les approbations requises. Et ici, nous pouvons choisir le nombre d'approbations. Nous avons besoin du nombre d'approbations de révision de code nous avons besoin avant de pouvoir fusionner ces modifications dans la branche principale. Laissons le choix par défaut. Et cliquons sur Créer. Une fois de plus, nous allons parler règles de prédiction des autres branches dans les prochaines conférences. Permettez-moi de saisir rapidement le mot de passe. Et nous avons créé une règle de prédiction de branche pour la branche principale. Revenons maintenant au compte GitHub de Luke. Si je recharge la page cette fois-ci, Luke ne pourra plus fusionner ces modifications. Et regardez maintenant voir la révision requise. Désormais, par défaut, tous les collaborateurs de l'équipe ou le propriétaire du référentiel peuvent effectivement consulter les modifications. Si vous vouliez changer ce comportement, nous devons prendre l'une de ces adhésions d'entreprise GitHub afin d'obtenir tout ce contrôle fin. En ce moment. Nous n'avons aucun contrôle là-dessus. 88. 1205 Examiner et approuver les changements Travailler sur l'examen des commentaires et la publication de nouveaux changements: Passons donc à quelques points, pour passer en revue les modifications apportées par M. Luke. Cela peut également être dû un autre collaborateur de ce référentiel. Ils peuvent également le revoir. Et ce qu'ils doivent faire pour revoir toutes les modifications apportées par Luke, c'est qu'ils vont aller dans la section Pull Request. Cliquez dessus. Ensuite, il sera possible de voir cette option, ajoutez votre avis. Et ici, ils peuvent réellement passer en revue toutes les modifications. S'ils ne sont pas satisfaits de l'un de ces éléments, ils peuvent laisser un commentaire disant, veuillez mettre à jour une autre ligne, quelque chose de ce genre. Et plutôt que de choisir l'option qui est pro, je vais définir les modifications de requête, ce qui signifie que je ne suis pas vraiment satisfait du code introduit. Je souhaite apporter ces mises à jour en fonction de mon commentaire. Ensuite, je veux revoir. Nous allons donc cliquer sur Soumettre un avis. Pour le compte de Luke. Il va dire que cela change ou demande. Il sera en mesure de voir la critique. Comme ça. Voici le commentaire de cylinder. Veuillez mettre à jour une autre ligne. Donc, ce que Luke va faire , c'est apporter tous les changements en fonction du commentaire de l'évaluateur. Quelque chose de ce genre. Nous allons valider ce changement. Nous pouvons pousser tous ces changements. Ou bien, nous pouvons cliquer sur ce bouton qui indique les modifications de synchronisation. Cela va donc pousser nos changements. Et s'il y a des changements à tirer vers le haut, faites-le également. Revenons à GitHub. Et ces changements auraient dû être présents et futurs d'une seule branche. Et comme vous pouvez le voir, nous sommes en mesure de voir ce nouveau commit. Désormais, nous n'avons plus besoin de lancer une autre demande de sondage. La demande de pool existante serait remplie automatiquement. Revenons rapidement au compte de l'expéditeur. Et Nelson Lord peut voir une mise à jour indiquant qu'un nouveau commit a été effectué. Généralement, il est agréable d'envoyer un rappel par e-mail ou quelque chose comme ça. Ou il peut y avoir un outil qui enverrait automatiquement un rappel par e-mail à tous les réviseurs. Donc l'expéditeur verrait tous les changements et il examinerait tous les changements et supposerait qu'il est très satisfait des changements, qu'il va les protéger et qu'il dit quelque chose de ce genre et qu'il va approuve les modifications comme cell. Revenons au compte de Luke. Maintenant, regardez dans le bar de mars. Nous allons en parler tout de suite. 89. 1206 Explorer les options de fusion Comprendre les engagements de Squashing dans la suppression de la succursale distant de lo: Maintenant que la révision est terminée et que les modifications sont approuvées par l'un des réviseurs, Luke est prêt à fusionner toutes ces modifications de la fonctionnalité 1 sur la branche principale. Si vous prenez la licence d'organisation de GitHub, vous obtiendrez un contrôle plus précis. Les deux derniers peuvent effectivement fusionner les pull requests pour le moment avec la version gratuite des collaborateurs de votre projet qui seraient en mesure de fusionner les pull requests, y compris la personne qui soulève le pull demandes. Donc dans ce cas, Luke essaie de fusionner sa propre pull request. Dans des projets en temps réel. Il s'agit de l'un des chefs d'équipe ou une personne autorisée à effectuer ce travail. Jetons un coup d'œil à toutes les options que nous avons ici. Nous pouvons créer un commit de fusion. Et comme son nom l'indique, cela va essentiellement créer un nouveau commit de fusion dans la branche principale. Et cela pointe vers quelques commits parents. Un parent serait le dernier commit hors branche principale, l'autre parent KM, ce serait le dernier commit hors de la branche feature. Nous avons déjà parlé des validations de fusion. Je n'ai pas à le répéter une fois de plus. Et sans oublier que l'historique des commits serait conservé, ce qui signifie que vous pourriez aussi bien avoir tous les historiques des comètes spaghetti. Si vous ne voulez pas avoir d'historique de commit spaghetti et ne souhaitez pas créer de commit de fusion supplémentaire. Ensuite, vous pouvez opter la troisième option qui dit Rabais et fusion. Ainsi, les quatre commits de cette branche, qui est une branche de fonctionnalité, seront rebasés puis ajoutés à la branche de base afin que l'historique des commits dans la branche principale soit plus linéaire. Nous avons également une troisième option qui est le squash et la fusion. Et comme le dit la description, les quatre commits de cette branche seront combinés en un seul dans la branche de base. C'est aussi bien que vous faites un nouveau commit dans branche principale avec toutes les modifications combinées de la branche feature one. Cela peut être la solution idéale si vous avez un tas de validations. Et il est logique de les combiner ensemble. Dans notre cas, nous n'avons pratiquement apporté aucune modification dans chacun de nos commits, il suffit de changer une seule ligne de texte. Peut-être que cette option est la chose idéale à faire pour nous. Essentiellement, si vous avez plusieurs validations pour lesquelles vous avez apporté des modifications mineures, et si vous pensez qu'elles peuvent être combinées en un seul commit, nous pouvons opter pour cette option. Je ne sais pas si vous êtes capable de vous en souvenir, mais lorsque nous avons parlé de rebase interactif, nous avions la possibilité d'écraser certains des commits. En gros, lorsque vous effectuez un rebasage interactif, vous pouvez lister tous les commits que vous souhaitez écraser ou les combiner. Supposons que vous ayez dix validations dans votre branche de fonctionnalité. Vous pouvez en écraser quatre ou trois ou tout ce qui vous semble logique à l'aide du rebasage interactif. Si vous ne vous en souvenez pas, je vous recommande de regarder à nouveau l'interaction avec la meilleure conférence sur les mêmes. Pour l'instant, partons avec cette option, rebaser et fusionner. Dans la plupart des cas, il s'agira de merge commit ou de Rebus and merge selon vos besoins. Je dois également mentionner que puisque nous avions déjà rebasé la branche de fonctionnalité sur la dernière branche principale avant de lancer la pull request, nous avions résolu tous les conflits potentiels avant de lancer les pull requests. C'est pourquoi, à ce stade, vous ne voyez aucun conflit. Mais il peut arriver que quelqu'un d'autre de votre équipe ait introduit des modifications dans votre branche principale alors que votre pull request est toujours active, ce qui peut créer un conflit. façon dont vous gérez ces conflits Nous parlerons plus tard de la façon dont vous gérez ces conflits. Pour l'instant, allons de l'avant et rebus et fusionnons. Et en tant que devoir, vous pouvez également essayer ces deux options. Plutôt simple. Cliquons sur Rabais et fusionnons. Nous allons confirmer. La pull request a donc été fusionnée et fermée avec succès. Et nous sommes prêts à supprimer cette branche en particulier. Nous pouvons le supprimer de GitHub, ou nous pouvons également le faire de même depuis notre machine locale. Laissez-moi vous montrer ce que je veux dire. Laissez-moi ouvrir Git Bash ici. Je participe actuellement au projet. Permettez-moi maintenant de supprimer la branche distante. Et la commande pour cela est git, push origin, name of the remote. Ensuite, vous allez utiliser deux points suivis du nom de la branche que vous souhaitez supprimer sur le serveur distant. Premier élément, dans notre cas, je vais appuyer sur Entrée. Et cela devrait supprimer la fonctionnalité de la branche dans le référentiel distant. Revenons en arrière. Et comme vous pouvez le constater, nous n'avons plus que la branche principale. Et voici la liste des commits qu'il contient, qui inclut désormais également tous les commentaires qui ont été faits dans la fonctionnalité 1. Si je fais git branch, vous verrez toujours la branche locale. Permettez-moi de trouver le bon nom. Nous avons toujours la succursale locale. Allons-y et supprimez-le également. Branche Git, trait d'union D, fonctionnalité 1. Ok, pour changer de branche. Réexécutons la commande. Et la branche a été supprimée. Depuis la suppression de la fonction distante sur les branches, même la branche de suivi correspondante n' est plus disponible. Je te verrai ensuite. 90. 1207 Ce que Git tire en fait: Chaque fois que vous essayez de transférer vos modifications locales vers le dépôt distant, git essaiera de fusionner nos modifications locales avec la même branche dans le dépôt distant. Mais il ne le fera que si cela aboutit à une fusion rapide, sinon il ne parviendra pas à pousser nos modifications et à contourner cela pour le faire. Je sais que cela peut sembler déroutant et c'est pourquoi j'ai dédié cette vidéo à ce sujet. Et pour mieux expliquer les choses. En fait, je vais tout faire à partir de zéro. Permettez-moi d'accéder au compte expéditeur et créer un tout nouveau dépôt. Donnons-lui un nom aléatoire. Ça n'a pas vraiment d'importance. Nous allons le garder temporairement de toute façon. Et ajoutons également un de ces fichiers juste pour avoir un commit dans la branche principale une fois que nous aurons un commit dans la branche principale créé ce dépôt. Permettez-moi également d'ajouter la fonctionnalité Une branche est créée. Ensuite, faisons un commit et ajoutons également une branche, peut-être en éditant le fichier Lisez-moi. Ligne 1, fonction 1. Appelons-le en ligne. Ça n'a pas vraiment d'importance. Faisons le commit. Allons dans Paramètres et ajoutons M. Luke comme l'un des collaborateurs. Très bien, maintenant passons au compte de Luke. Luke vient donc de recevoir une invitation à contribuer à ce projet. Je vais voir cette invitation et l'accepter. Ensuite, il va cloner le projet sur sa machine locale pour commencer à contribuer. Dans l'un des dossiers. Je vais ouvrir Git Bash. Et faisons git cloner ce projet. Allons dans ce dossier. Et si je fais git branch, tout ce que vous voyez que nous avons une branche Rachman distante du Maine ainsi que la fonctionnalité 1, mais nous n'avons pas la branche locale hors fonctionnalité 1. Donc, pour l'obtenir, passons à une branche ou à la caisse à une branche. Donc, à présent, cette branche locale sera créée. Et nous sommes actuellement dans la branche vedette un. Faisons le reste du code de Visual Studio. Nous allons donc ouvrir ce projet avec VS Code. Et disons que je voudrais faire un commentaire dans la nouvelle fonctionnalité une branche. Nous sommes donc actuellement dans la branche vedette un. Permettez-moi peut-être cette fois d'ajouter un fichier, appelons-le un point dx, dy. Je vais dans Contrôle de source, donne un message au commit et je valide nos modifications. Imaginez maintenant qu' un autre l'équipe travaillant également sur la même branche apporté quelques modifications au dépôt distant sur la même branche pour simuler ce comportement. Revenons au compte des expéditeurs et effectuons un commit dans la branche feature 1 comme si quelqu'un avait poussé les modifications à cette branche. Permettez-moi d' ajouter un autre fichier, peut-être deux points TXT. Et validons nos changements. Maintenant, fondamentalement, les deux sont une fonctionnalité locale sur la branche et sa branche distante correspondante ou non divergée. Voyons ce qui se passerait si j' essayais de pousser nos modifications locales vers le dépôt distant. Git push, nous pouvons spécifier la branche distante et proposer une branche. Mais si vous utilisez simplement cette commande, ce sera le comportement par défaut de toute façon. Poussons donc nos changements et voyons ce qui va se passer. Comme vous pouvez le voir, nous avons une erreur qui indique que certaines références n'ont pas pu être envoyées à ce référentiel et que les mises à jour ont été rejetées parce que le contenu distant fonctionne que vous n'avez pas localement. Comme je l'ai déjà dit, lorsque nous poussons notre kit de modifications locales essaiera de fusionner ou modifier localement la même branche dans le dépôt distant. Dans ce cas, cela n'entraîne pas une fusion rapide et c'est ce qui n'a pas poussé nos modifications. Ce que nous pouvons faire ici maintenant, c'est utiliser la commande git pull. Et par défaut, il essaiera également de fusionner ces deux branches dans notre inscription locale. Alors laissez-moi essayer git pull pour récupérer les modifications. Nous pouvons également faire la même chose à partir du code Visual Studio. Si tu le souhaites. Par exemple, je peux dire git pull à partir de là ou d'ici. Essayons de voir le graphique maintenant. Et comme vous pouvez le voir, git a essayé de fusionner la branche feature one avec la branche de notre professeur local. Il s'agit donc essentiellement du commit de fusion. Maintenant, si vous essayez d'effectuer une opération push, elle devrait réussir. Ensuite, nous devrions également être en mesure de voir ce commit de fusion dans le dépôt distant. Mais si vous souhaitez vous débarrasser de ce commit de fusion, vous savez déjà quoi faire. Rebase est la solution. Essayons donc de rebaser notre branche actuelle, qui est la branche feature one au-dessus du récent changement du dépôt distant. Essentiellement, j'essaie de rebaser une branche de fonctionnalité locale avec la branche de suivi à distance, qui représente essentiellement branche de la fonctionnalité distante une. C'est donc le commit vers lequel les branches de suivi pointent. Je vais faire un clic droit dessus. Et puis je vais choisir cette option rebase, branche actuelle de ce comité. Et rebasons-nous dans le cadre de la renaissance, comme nous l'avons déjà dit dans l'une de nos précédentes conférences. Cela supprimera également tous les commits de fusion. Parce que nous sommes essentiellement en train de réécrire tout l'historique des commits. Et cela résout le problème de ne pas avoir beaucoup de commits. Nous avons donc maintenant un historique linéaire des commits. Nous sommes prêts à pousser nos changements. Cette fois-ci. Cela va entraîner une fusion rapide de la fonctionnalité locale sur branche et de la fonction distante une branche. Nous ne devrions donc pas avoir de problème ou quoi que ce soit d'autre . Mais d'une manière générale, vous devez être prudent avec l'opération de rebase. Et il existe certaines bonnes pratiques à suivre, dont nous parlerons lors des prochaines conférences. n'y a aucun problème en tant que tel à avoir beaucoup d'engagement. Vous pouvez également pousser votre commentaire de fusion si vous le souhaitez. Et en fait, c'est l'un des choix les plus populaires car rebasage peut en fait gâcher les choses. Ce dont nous parlerons encore une fois dans les prochaines conférences. Mais pour l'instant, nous sommes prêts à pousser nos changements. Et il est possible d'accéder au dépôt distant. Maintenant, passez à une branche. Je devrais voir tous ces commentaires, y compris le commit local que nous avions fait plus tôt. Je te verrai ensuite. 91. 1208 Résoudre les conflits sur GitHub de la bonne façon de forcer les changements et ses conséquences: Voyons comment nous pouvons gérer les conflits lorsque nous essayons de fusionner fonctionnalité 1 dans le courant dominant de l'évolution, la branche principale. Actuellement, je suis dans la première branche et comme vous pouvez le voir, nous avons les quatre validations de nos conférences précédentes. Ce que je vais faire maintenant, c'est lancer une pull request pour tous les changements que nous avons introduits in vitro, une pull request levée par branche . Maintenant, je suis prêt à effectuer n'importe laquelle de ces opérations. Je peux également effectuer des réparations et beaucoup parce qu' aucun nouveau commentaire n' a été fait dans la branche principale et qu'il n'y a aucun moyen que cela puisse provoquer des conflits. Mais que se passe-t-il si après avoir lancé la pull request, quelqu'un introduit de nouveaux changements dans la branche principale, ce qui peut provoquer des conflits sans modification de la fonctionnalité 1 ? Pour simuler ce comportement. Permettez-moi de revenir à la branche principale et de modifier ce fichier. Si vous vous souvenez, dans l'un des commentaires in vitro et de la branche, nous avons mis à jour le fichier ReadMe. Donc si je mets à jour ce fichier une fois de plus dans la branche principale, cela devrait nous donner un conflit. Permettez-moi donc de cliquer sur ce fichier et d' ajouter du texte comme ça, et de valider les modifications. Revenons maintenant à la pull request et voyons si nous pouvons désormais exécuter Freebase. Et maintenant, vous voyez un avertissement qui indique que la branche est complexe et que cela doit être résolu. Nous pouvons résoudre les conflits ici, mais ce n'est pas une approche recommandée. faire court, cela va un peu compliquer les choses. En gros, si vous regardez l'histoire de Chametz, cela va vous embrouiller. Il existe une meilleure façon de gérer ça. Et c'est ce que je vais vous montrer maintenant dans notre machine locale comme lui que cela ressemble à un ordinateur. Tout d'abord, nous allons apporter tous les changements dans la branche principale. Permettez-moi donc de passer à la branche principale et de récupérer un nouveau commit. Essayons maintenant de rebaser notre branche feature one sur ce nouveau commit. Il s'agit d'une procédure standard que nous avions suivie lors de l'une de nos précédentes conférences. Qu'est-ce que vous demandez à quelqu'un de revenir à la fonctionnalité 1 ? Cliquez avec le bouton droit de la souris sur ce commit et choisissez cette option qui indique de rebaser la branche actuelle sur ce comité. Cela devrait nous donner lieu à des conflits. Et comme on pouvait s'y attendre, nous avons des conflits. Cela signifie qu'il faut le rejeter. Résolvons donc ces conflits. Peut-être que cette fois j'aimerais accepter les deux modifications. Enregistrez le fichier, laissez-moi l'indiquer et cliquez sur Commit. Cela va essentiellement créer un nouveau commit avec tous les conflits de résultats. Laissez-nous entrer un message. J'aimerais le garder tel quel. Une fois que vous l'aurez fermé. Cela devrait rebaser la branche au-dessus de ce nouveau commit. Comme ça. Donc maintenant tous les commits sur la branche ou vus au-dessus de ce commit. Essayons maintenant de pousser toutes ces modifications vers le dépôt distant et voyons ce qui va se passer. Permettez-moi de vider l'écran. Nous pouvons également faire la même chose à partir de Visual Studio Code. Laissez-moi taper la commande git push et voir ce qui va se passer. 1 seconde, nous avons eu ce dicton hétéro, impossible de pousser certaines références au dépôt distant. C'est parce qu'avec rebase, l'historique des commits a été réécrit et il ne correspond pas à l'historique des commits que nous avons dans le dépôt distant. Maintenant, soyez heureux que notre branche locale feature one et sa fonctionnalité correspondante une branche dans le dépôt distant, ou les deux ont divergé. Cela ne nous permet donc pas de pousser nos changements. Alors, comment pouvons-nous maintenant appliquer nos modifications au dépôt distant ? Eh bien, nous pouvons utiliser la force d'option. Donc cette fois avec git push et quand fournir l'option force. Qu'est-ce que ça va faire maintenant ? L'indicateur force fera correspondre la branche des référentiels distants à votre branche locale. Et cela supprimera toutes les modifications en amont qui ont pu être apportées depuis la dernière puce. qui signifie également que s' il y a plusieurs personnes travaillant sur la même branche et si quelqu'un avait apporté ses modifications à la même branche, tout le travail serait perdu, ce qui est ce n' est pas toujours souhaitable. Il y a donc des cas où vous ne devriez pas utiliser l'option forcer. Nous allons parler de tout cela et des meilleures pratiques lors des prochaines conférences. Mais pour l'instant, cela va faire le travail pour nous. Et si vous revenez au dépôt distant, vous remarquerez que nous pouvons désormais effectuer rebasage et une fusion ou même deux autres options. Jetons un coup d'œil à l'historique des commits très rapidement. Pour accéder à une branche en vedette. Jetez un œil à la liste des commits. Nous avons donc tous ces commentaires sur la branche feature one empilés au-dessus des commentaires de la branche principale. Nous pouvons maintenant procéder à des remises et fusionner. Nous pouvons également dissoudre le complexe et GitHub, mais cela va faire des choses étranges comme Robeson, la branche principale sur laquelle se trouve une branche pour faire avancer les choses. Et cela peut créer beaucoup de confusion. Mais c'est souvent la pratique suivie pour résoudre le conflit. Maintenant, cela n'a aucun sens d'avoir la branche autour de vous. Je peux donc le supprimer. J'espère que c'est logique. Je te verrai ensuite. 92. 1209 Stratégie de partage et de conqr: Voyons comment nous pouvons gérer les conséquences négatives de l'utilisation de l'option de la force. Lorsque vous utilisez la commande push. J'ai mentionné que lorsque vous utilisez l'option force, l'historique des commits sur le serveur distant sera écrasé de force par votre propre historique local. Il y a maintenant quelques conséquences à cela. Premièrement, il se peut que plusieurs développeurs travaillent sur la même branche et que nous risquions de perdre tous les commits qu' ils ont effectués après votre dernier sondage. Et deuxièmement, plus important encore, lorsque vous faites Rebus, puis que vous forcez, poussez vos modifications, cela peut créer un gâchis parce que tous les autres membres de l'équipe peuvent avoir téléchargé le projet et j'ai peut-être vérifié dans cette agence. Essentiellement, lorsque vous rebasez et mettez en pause le push vos modifications lisent non , vos modifications lisent non seulement l'historique des commits, mais également leurs codes de hachage. Et tous les membres de l'équipe qui ont pu télécharger le projet et Chet point cette branche peuvent avoir un ensemble d'historique commun différent de celui qui existe dans le dépôt distant. Cela va créer beaucoup de désordre. Afin d'éviter cela, nous avons une stratégie appelée «  diviser pour régner ». Laissez-moi vous expliquer ce que je veux dire. Supposons qu'il s'agisse de la branche principale et que c' est la branche de fonctionnalité dans le dépôt distant. Supposons maintenant que quelques développeurs soient prêts à contribuer à cette branche. Au lieu de contribuer tous les deux à cette branche. Nous allons maintenant avoir quelques sous-branches chacune appartenant à un développeur individuel. Ces deux dollars contribueraient à leur propre ensemble de changements dans leurs propres sous-branches. Et comme ils se déplacent sur leur propre branche, les modifications effectuées sur une branche n' auront aucun impact sur l'autre branche. Par exemple, l'un des développeurs peut vouloir rebaser et forcer la validation toutes ces modifications dans sa propre branche. Et cela n'aura aucun impact sur l'autre branche appartenant au développeur. Et une fois que l'un des développeurs a terminé tout ce qu'il a à faire, il peut fusionner toutes les modifications sur la branche de la fonctionnalité. Et puis l'autre paire de dollars rebaserait leur branche sur la première branche, puis fusionnerait également leurs modifications. Et s'il y a des changements que l'un ou l'autre dollar plus a pu manquer, ils peuvent créer une autre succursale et apporter tous ces changements. Et puis, bien sûr, fusionner ces modifications dans la branche feature one. C'est ce qu'on appelle la stratégie diviser pour mieux régner Et cela peut empêcher les effets secondaires qui peuvent survenir lorsque vous forcez vos modifications. Cependant, il peut arriver que cette approche ne soit pas réalisable. Dans ce cas, nous avons une alternative à, et c'est ce dont nous allons parler ensuite. Mais peut-être que tu peux prendre ça comme une mission. Essayez de créer quelques sous-branches partir de la branche feature one, et essayez de suivre l'approche diviser pour mieux régner. 93. 1210 Résoudre les conflits en fusionnant la branche principale pour la branche de fonctionnalité: Voyons comment nous pouvons gérer les conflits en fusionnant les branches sans avoir à utiliser l'option forcer, ou en suivant l'approche diviser pour mieux régner. Pour cela, essayons d'abord de créer un autre conflit. Puisque nous avons déjà supprimé la branche feature one, créons une nouvelle branche pour introduire de nouveaux conflits. Appelons cela une nouvelle fonctionnalité. Peu importe. Je vais créer cette branche. Laissez-moi modifier l'un de ces fichiers. Supposons que je souhaite modifier un fichier TXT à un point. Et je vais simplement ajouter le nom de la branche comme cell. Commettez les modifications. Permettez-moi de revenir à la branche principale. Et essayons de modifier le même fichier une fois de plus, afin d'avoir un conflit. Disons simplement main et validons les modifications. Passons maintenant aux pull requests et essayons de générer une nouvelle pull request. Nous comparons donc la branche principale avec la nouvelle branche de fonctionnalité. Et voici les changements. Permettez-moi de créer la pull request. Comme vous pouvez le voir, nous recevons un message indiquant que cette branche est complexe et doit être résolue. Nous avons également la possibilité de résoudre les conflits. Cela nous permettrait de résoudre les conflits en fusionnant la branche principale dans la branche fonctionnalité. Cela peut vous surprendre, mais cela fonctionne réellement. Laissez-moi vous montrer ce que je veux dire. Permettez-moi de cliquer sur Résoudre les conflits. C'est comme si nous étions dans un état de fusion où les conflits doivent être résolus. Et nous pouvons résoudre les conflits comme nous les avions dissous notre machine locale lorsque nous essayons de fusionner des branches. Donc, essentiellement dans ce cas, GitHub essaie de fusionner branche principale avec la nouvelle branche de fonctionnalité. Et cela ramènerait essentiellement tous les changements de branche principale ou tous les commentaires de branche principale sur la branche feature. J'aime conserver les deux modifications. Et je vais cliquer sur ce bouton qui indique Mark. En conséquence. Nous allons arriver à la fusion. Cela va créer un commit de fusion, et cela va pointer vers quelques commits parents. Le dernier commentaire de la branche principale et le dernier commit de la nouvelle branche de fonctionnalité. C'est assez similaire à ce que nous avons fait notre machine locale lorsque nous essayons de résoudre les conflits. Alors que la marge. Vous pouvez voir ici que nous venons fusionner main dans la nouvelle branche feature. Et cela a résolu le problème. Pour revenir au dépôt, les commits dans la branche principale resteraient ainsi. Laisse-moi te montrer. Mais alors que si vous allez dans la nouvelle branche de fonctionnalité, elle contient tous les commits dans les commentaires qui ont été faits et nouvelle branche de fonctionnalité et également le commit de fusion. Si tu y vas, tu verras qu'il a deux parents. L'un des parents est le dernier commit de la branche principale, et l'autre est le nouveau commentaire que nous venons de faire dans la branche feature. Cet instantané de commit de fusion aurait donc des modifications introduites dans ces deux branches. C'est pourquoi nous pouvons voir tous les commits appartenant aux deux branches. Je ne suis pas sûr que cela vous embrouille, mais c'est en fait assez simple. Si vous ne comprenez pas cela, alors c'est parfaitement normal. Nous avons déjà discuté de plusieurs moyens de résoudre les conflits. Au cours des deux dernières conférences. Vous pouvez opter pour cette approche ou vous pouvez également suivre cette approche. Vous pouvez également faire de même dans votre dépôt local. Il suffit de consulter le projet et d'essayer fusionner la branche principale de votre branche feature one, résoudre les conflits afin d' avoir un historique de validation similaire sur votre machine locale. Ensuite, vous allez pousser tous ces commits vers le dépôt distant avec la commande push standard. Revenons à la pull request. Aujourd'hui, nous n' avons plus de conflits. Cette branche n'est pas en conflit avec la branche de base. Et nous sommes prêts à procéder à une fusion. Vous ne pouvez cependant pas effectuer de rebase. Vous ne pouvez pas effectuer de rebase car, comme vous le savez déjà, rebase va réécrire l'historique des commits et même supprimer les commits de fusion. Dans ce cas, cela n' a aucun sens de le faire. Cela semble déroutant. Ensuite, n'oubliez pas qu'il ne peut pas effectuer de rebase. Dans ce cas. Si vous essayez d'effectuer un rebasage, cela indique que cette branche ne peut pas être rebasée en raison de sa complexité. Le message n'est pas très clair, mais j'espère que vous avez compris. Mais nous pouvons fusionner les modifications et les valider. Nous pouvons maintenant nous débarrasser de la nouvelle branche de fonctionnalité. Et c'est la solution alternative pour résoudre le problème complexe. Je te verrai ensuite. 94. 1301 Qu'est-ce que la Forking et pourquoi la Forking: Parlons de for king dans GitHub et de sa signification. Imaginons que nous ayons un projet open source avec le nom open app dans le référentiel GitHub. Et disons que c'est la propriété de M. Sunda. Maintenant, quand je dis qu'il s'agit d'un projet open source, vous pouvez vous attendre à ce que des centaines, voire des milliers de développeurs à travers le monde soient prêts à contribuer à ce projet. Imaginez maintenant la quantité de travail qui a été effectuée pour gérer les collaborateurs. Si cylindre quoi gérer des centaines ou des milliers de collaborateurs, cela devient un travail à part entière. Par exemple, chaque fois que quelqu'un souhaite contribuer, qu'il s'agisse d'une petite contribution ou d'une contribution importante, il doit toujours l'ajouter en tant que collaborateur. Deuxièmement, si divers utilisateurs utilisent la version gratuite de GitHub, alors pratiquement tous les collaborateurs, nous aurons le privilège de fusionner leur code sur la branche principale. Maintenant, imaginez un dollar pour débutant par personne qui commence tout juste à programmer. Fournissez du code et du module ces modifications sur la branche principale sans effectuer de tests adéquats. Évidemment, cela va créer beaucoup de désordre. Nous avons donc besoin d'une solution à ce problème. Eh bien, la solution est bifurquée. Alors, qu'est-ce que le « fork » exactement ? Imaginez que M. Luke souhaite contribuer à ce projet et qu'il n'est pas ajouté comme collaborateur sur ce projet. Donc, ce que Luke va faire c'est d'un simple clic sur un bouton, est allé remplir ce dépôt sur son propre compte GitHub. Vous pouvez considérer le travail comme un clone. Mais au lieu de le cloner sur la machine locale, cela se produira sur la salve GitHub sur le compte de Luke. Dans ce cas, Luke et renommez ce projet avec le nom de son choix, ou il peut également conserver le même nom. Ça n'a pas vraiment d'importance. En tant que convention de dénomination standard. Le référentiel par défaut est appelé origine et le référentiel d'origine est désigné en amont. Vous pouvez bien entendu les appeler avec le nom de votre choix. Mais ce sont les conventions de nommage typiques nous suivons en tant que développeurs. Donc, chaque fois que je dis origine, je fais référence au dépôt bifurqué. Chaque fois que je dis amont, je fais référence au dépôt d'origine d' où nous en avons quatre. Maintenant regardez, nous allons créer un dépôt bifurqué de bureau clone, même dans sa machine locale. Il introduira ensuite toutes les modifications qu'il doit introduire et il va pousser toutes ces modifications sur le dépôt bifurqué. Pendant ce temps, s'il y a de nouvelles mises à jour sur le dépôt d'origine, regardez et tirez réellement toutes ces modifications sur son dépôt local et poussez toutes ces modifications ou nouveaux commits dans son dépôt bifurqué. De cette façon, le dépôt par défaut restera à jour, mais les modifications nouvellement introduites dans le dépôt d'origine seront apportées après que Luca aura fini avec les modifications qu'il souhaite introduire. Et bien sûr, après des tests adéquats il va lancer une pull request, demandant à certains d'accepter tous ces changements et de les fusionner dans la branche principale du dépôt d'origine. Ce vaisseau n'a donc pas besoin d'un accès en écriture pour commencer à contribuer. Cette approche qui consiste à contribuer à un projet en bifurquant le dépôt est non seulement bénéfique pour le propriétaire du dépôt, mais aussi pour le dollar plus un pour contribuer au projet. Voici quelques-uns des avantages pour les développeurs d'utiliser le fork. Au lieu de contribuer directement au dépôt d'origine. La marche permet à quiconque de contribuer à un projet sans avoir le bon accès. Parce qu'ils peuvent simplement créer un fork d'un projet, introduire toutes les modifications, les tester, puis lancer une pull request. Ils peuvent librement expérimenter les modifications sans affecter le projet d'origine. Dans certains cas, il peut y avoir plusieurs personnes qui souhaitent collectivement contribuer à un projet particulier. Dans ce cas, il est toujours préférable de forker le dépôt d'origine, supprimer toutes les modifications, de faire des tests d'intégration. Et une fois qu'ils ont terminé, ils peuvent lancer une pull request, demandant le dépôt initial au propriétaire pour qu'il récupère toutes les modifications et les fusionne sur la branche principale. La marche vous permet d' utiliser le projet de quelqu' un d'autre comme point de départ pour votre propre idée. De nombreux logiciels ou applications commerciaux ont été initiés à l'origine d'un projet open source. Ils travaillent simplement sur tous les projets open source existants , introduisent des modifications en plus de cela et le vendent à leurs clients avec la licence commerciale. Enfin, vous n'avez pas à attendre le bon accès. Imaginez que vous écrivez un e-mail au propriétaire postérieur pour lui demander l'axe droit, puis que vous attendez une réponse indéfiniment. Eh bien, avec le fork, vous pouvez directement contribuer au projet et faire la course aux pull requests sans avoir à avoir le droit d'accès au dépôt d'origine. Nous allons voir toute cette inaction et bien d'autres encore dans les prochaines conférences. Je te verrai ensuite. 95. 1302 Créer un dépôt public et le cloner dans notre machine locale: Voyons comment nous pouvons créer un dépôt pour commencer à contribuer. Imaginez maintenant que c'est l'ordinateur de Luke et qu'il est prêt à contribuer à l'un des projets open source disponibles en ligne. Laissez-moi accéder au compte GitHub de Luke. Et c'est ici. Et supposons que c'est le projet auquel Luke est prêt à contribuer. Ce projet est en fait la propriété de Mr. Cylinder and Look, n'a pas le droit d' accès à ce projet ou il n'est pas ajouté comme l'un des collaborateurs de ce projet. Cette fois, comme loop ne peut pas contribuer directement à ce projet, ce qui va faire est de créer un fork de ce projet. Donc, ici, vous voyez une option qui dit ****, vous pouvez ajouter le clic ici. Je vais cliquer sur le menu déroulant. Et vous voyez une option qui indique Create a New Fork. Hey, la façon dont vous serez redirigé vers cette page où il vous sera demandé de donner un nom à votre dépôt. Vous pouvez conserver le même nom que celui du dépôt d'origine ou le renommer autrement. Par exemple, peut-être que l'apparence, l'application ou autre n'a pas d'importance. Vous pouvez également fournir une description et cliquer sur ce bouton qui dit créer un fork. Nous avons donc créé un clone du projet original sur le compte GitHub de Luke. Et Luke peut maintenant faire tout ce qu'il ferait autrement sur son propre dépôt public. Et le fait qu'il s'agit en fait d'un clone ou d'une version bifurquée d'un autre dépôt. Vous allez voir tout l'historique des commits dans les branches. Tout est tel quel, sauf pour un dépôt bifurqué. Vous allez voir cette icône signifiant qu'il s'agit d'un dépôt bifurqué. Et aussi ce texte qui dit bifurqué du flic de 1996 slash my public cap, qui est le dépositaire original. Solute, peut maintenant commencer à contribuer à ce projet. Il peut même ajouter des collaborateurs supplémentaires. Si Luke a une équipe de développeurs qui voudraient peut-être contribuer à ce projet. Vous pouvez ajouter des règles de protection des collaborateurs ou des branches. Tout ce que l'on peut faire avec un dépôt public. Vous pouvez faire de même avec le dépôt bifurqué. Sauf que vous allez voir une différence par rapport à l' original déposé ici. Cette référence sera utile ultérieurement et nous en ultérieurement et nous parlerons dans les prochaines conférences. Pour l'instant. Essayons de cloner ce projet. Copions l'URL HTTPS. Inside looks computer va simplement cloner son propre dépôt. Git clonez et collez l'URL. Permettez-moi d'aller dans ce répertoire cd. Et laissez-moi taper la commande git remote hyphen v signifie verbose. Comme vous pouvez le voir, il a déjà ajouté une télécommande avec le nom origin, et elle pointe vers le dépôt bifurqué. Donc, quand je dis origine, je fais référence au dépôt bifurqué. Et en bas de la ligne serait également nécessaire d'ajouter une autre télécommande, qui est distante en amont. Et cela indique que le dépôt d'origine continuera à partir du suivant. 96. 1303 Contribuer aux changements nécessaires: Quels sont les changements que Luke souhaite apporter à ce projet ? Il va apporter toutes ces modifications localement, les tester, puis pousser toutes ces modifications dans son propre dépôt bifurqué afin simuler ce comportement qui a fait un tas de validations. Et bien entendu, comme bonne pratique, nous allons créer une nouvelle branche. Et c'est là que nous allons prendre nos engagements. C'est ce que j'ai prêché tout au long de ce cours. Nous ne voudrions jamais faire du commerce statiquement sur la branche principale, mais nous allons plutôt créer une nouvelle succursale et apporter une contribution vide. Ouvrons donc cela avec le code Visual Studio très rapidement et créons une nouvelle branche. Appelons ça la fonction dix. Peut-être. Créez une nouvelle branche. Et je vais simplement ajouter quelques fichiers. TXT à un point, par exemple, allez dans Contrôle de source, créez un TXT à un point. Commettez les modifications. Et laisse-moi m'engager encore une fois. Peut-être deux points dx, dy, peu importe. Je voulais juste m'assurer que nous voyons quelques commentaires. Et cette branche de fonctionnalité contient le mot « introduisant nos modifications ». Nous avons une branche et nous y avons fait quelques commentaires. Vous pouvez le voir dans ce graphique ici, comme vous pouvez le voir, la fonctionnalité une branche, quelques commentaires à venir. La branche principale. Et si, pendant que je travaille encore sur cette fonctionnalité, nous avions un tas de nouvelles mises à jour sur le dépôt amont ou le dépôt d'origine. Comment allons-nous obtenir toutes ces mises à jour notre machine locale ainsi que sur notre dépôt bifurqué ? C'est ce dont nous allons parler ensuite. 97. 1304 Synchroniser le repo fourré avec celui original et mettre à jour local: Voyons comment nous pouvons maintenir notre dépôt local ainsi que le dépôt bifurqué synchronisés avec le dépôt d'origine. Afin de simuler le comportement où nous avons de nouvelles mises à jour dans le dépôt initial aujourd'hui. Permettez-moi d' aller sur le compte de l'expéditeur. Qui est le propriétaire de ce dépôt. Et laissez-moi faire un commit dans la branche principale, peut-être en ajoutant simplement un fichier. Donnons-lui un nom aléatoire. Quelque chose de ce genre. TXT point pomme. Désolé pour les noms drôles. Je voulais juste que les choses restent simples. Créons ce fichier. Nous avons donc de nouvelles modifications dans la branche d'origine. Il existe maintenant plusieurs façons de synchroniser notre dépôt bifurqué notre dépôt bifurqué avec le dépôt d'origine. Celui dont je vais parler maintenant est l' approche la plus simple de toutes. Passons maintenant au compte GitHub de Luke. Rafraîchissons la page. C'est donc le dépôt bifurqué. Ici, vous voyez un message qui dit que cette branche est un commit derrière le flic principal, qui est le dépôt d'origine. Et ici, vous voyez également une option pour évier fourchette. Si vous cliquez dessus. Vous verrez l'option de mise à jour de la branche et notez que nous sommes actuellement dans la branche principale. Donc, essentiellement, la branche principale du dépôt bifurqué est comparée à la branche principale du dépôt d'origine. Et c'est ainsi que GitHub nous indique que nous sommes en fait un commit derrière la branche principale du dépôt d'origine. Lorsque vous cliquez sur Sync Fork, vous verrez l'option pour mettre à jour la branche, cliquez dessus. Cela récupérerait et fusionnerait nos modifications. Comme vous pouvez le voir, nous avons ce nouveau dossier ici. Maintenant, quand il a récupéré et fusionné, c'est comme une opération de pool. Et cela se traduira par une fusion en avant rapide. Et il n'y a aucun moyen que nous puissions avoir des conflits ici parce que nous suivons les bonnes pratiques qui consistent à ne pas apporter nos contributions dans la branche principale. Nous avons créé une branche de fonctionnalité et c'est là que nous apportons toutes les modifications ne touchaient pas la branche principale. Donc, lorsque nous pensons aux deux référentiels, il n'y a aucun moyen de voir des conflits au cas où vous ne suivriez pas les bonnes pratiques et si ne suivriez pas les bonnes pratiques vous faites des commentaires dans votre branche principale, il se peut aussi bien que vous soyez témoin de conflits et que vous deviez ensuite faire face à ces conflits. Une fois que vous l'avez dans le dépôt distant, il vous suffit de récupérer ces modifications même dans votre dépôt local. Faisons ça très vite. Comme vous pouvez le voir, nous avons reçu les mises à jour du dépôt par défaut. 98. 1305 Synchroniser le repo fourré avec un original de repo local: Examinons un autre moyen de maintenir le dépôt bifurqué et le dépôt local à jour par rapport au dépôt d'origine. Pour cela, faisons rapidement un dernier commentaire. Dans le dépôt d'origine, qui se trouve sur la fenêtre du bus. Juste pour simuler le comportement des nouvelles mises à jour dans la branche principale. Je vais ajouter un nouveau fichier, quelque chose comme ça. Encore une fois, désolée pour les noms drôles. Venez avec le nouveau dossier. Cette fois, ce que nous allons faire c'est récupérer toutes ces modifications dans un dépôt local, puis les pousser vers notre dépôt bifurqué. Voyons comment nous pouvons y parvenir. Nous allons le faire depuis Git Bash. Vous pouvez également faire de même à partir du code Visual Studio si vous le souhaitez. Tout d'abord, nous devons intégrer les modifications par rapport au dépôt d'origine. Comment allons-nous faire cela ? Si je dis git pull, cela tirerait en fait de la télécommande d'origine, qui est le dépôt bifurqué. Mais nous voulons le retirer du dépôt d'origine. Comment allons-nous faire cela ? Tout d'abord, nous devons ajouter cette télécommande. Si je dis git remote hyphen v, vous voyez que nous avons origin demote et pointe vers le dépôt bifurqué. Ajoutons maintenant un autre remote, git, remote add. Et je vais le nommer en amont. Comme je l'ai déjà dit. Nous allons appeler le dépôt d'origine en amont. Et ici, nous allons fournir l'URL du dépôt d'origine. Permettez-moi donc de le copier ici. Je peux également utiliser ce lien si je le souhaite. Cette commande vient d'ajouter le dépôt amont. Si je lance à nouveau cette commande, vous verrez que nous avons maintenant quelques remarques. Essayons maintenant de récupérer les modifications depuis le dépôt amont. Git pull puis main en amont. Nous voulons donc maintenir notre agence principale à jour. Cela a entraîné tous les changements. Il s'agit du fichier que nous venons de créer. Vous pouvez également le voir dans le code de Visual Studio. Cependant, ces modifications ne sont pas encore disponibles dans notre dépôt bifurqué ou sur le serveur d'origine. Devinez ce que nous devons faire ensuite. Push Git. Et cela devrait pousser ces nouveaux commits vers le dépôt bifurqué. Si vous allez sur le compte de Luke maintenant et que vous rechargez la page, vous verrez ces mises à jour. 99. 1306 Pousser nos changements au repo fourché: Supposons que Luke ait terminé toutes les modifications de la fonction dix. Et maintenant, il est prêt à proposer toutes ces modifications à l'expéditeur, qui est le propriétaire du dépôt d'origine ou du dépôt amont. Mais avant même d' envisager cela, Luke doit s'assurer qu' il a toutes les mises à jour, toutes les dernières mises à jour du dépôt amont, et s'assurer que son dépôt bifurqué ainsi que le dépôt local, sont à jour avec lui. Nous avons déjà vu comment cela peut être fait lors des deux dernières conférences. La deuxième chose dont la boucle doit s' assurer est de lire ceci en tant que branche de fonctionnalité au-dessus de la branche principale. Alors faisons-le très rapidement. Je vais passer à la branche en dix. Je vais faire un clic droit sur le dernier commit de la branche principale. Et puis je vais choisir cette option qui dit de rebaser la branche actuelle sur ce point. Grâce à cela, nous éliminons les éventuels conflits qui pourraient survenir. Si vous êtes confronté à un conflit quelconque, vous saviez déjà comment y faire face. Une fois que vous avez terminé, vous allez envoyer toutes ces modifications au dépôt distant, au dépôt bifurqué ou à l'origine. Nous allons donc pousser tous ces changements. Nous recevons un message indiquant que la fonction de branche Dan n'a pas de branche distante. Vous souhaitez publier cette branche ? Je dis, OK, je veux choisir le mode acide d'origine. C'est ce que je souhaite publier ou vers lequel je souhaite appliquer nos modifications . C'est un succès. Il faut aller sur le compte de Luke et voir si les choses se sont reflétées. Et bien sûr, vous voyez maintenant Permettez-moi de recharger la page. Vous voyez maintenant cette nouvelle succursale. Ensuite, nous allons voir comment nous pouvons lancer une pull request pour proposer nos modifications au maître-cylindre. Je te verrai ensuite. 100. 1307 Augmenter la demande de traction et fusionner les modifications du dépôt amont: Voyons comment Luke peut proposer ces changements à la reddition en lançant une pull request. Il existe plusieurs manières de le faire. Vous voyez déjà ici une option permettant de comparer et d'augmenter la pull request. Vous pouvez soit cliquer ici, soit choisir la branche de fonctionnalité dans la liste. Cliquez ensuite sur le menu déroulant sous Contribuer, et vous verrez la même option pour ouvrir une pull request. Vous pouvez également accéder à la section Pull Requests et créer une nouvelle pull request. Quelle que soit la méthode que vous suivez, vous allez voir l' écran où nous devons comparer les branches pour voir la différence entre les deux. Ici, nous allons comparer la branche principale du dépôt amont avec la branche feature du dépôt bifurqué. Le référentiel ici fait référence au dépôt en amont. Et ici, nous avons choisi la branche principale. Le dépôt principal ici pointe vers le dépôt bifurqué. Et ici, nous devons choisir la branche de fonctionnalité. Cela va donc afficher un résumé de toutes les modifications que nous venons d'introduire dans la branche des fonctionnalités. Nous pouvons maintenant simplement créer la pull request. Le processus est assez similaire au processus de pull request dont nous avons parlé plus tôt. Ainsi, une fois que la pull request est déclenchée, ils peuvent réellement examiner les modifications. Il peut accepter ou refuser ou vous demander de travailler sur un tas de commentaires, etc. Passons maintenant au tableau de bord de cinders. Rechargez le dépôt principal. Voici la pull request. Cliquons dessus. Nous avons déjà parlé de diverses choses que nous pouvons faire ici. Par exemple, je peux simplement dire « rabais et fusion ». Mais avant cela, puisque nous avons une règle de prédiction de branche, pour faire au moins un examen, passons rapidement en revue les modifications et disons que je suis satisfait de toutes les modifications. Je vais approuver et soumettre l'évaluation. Maintenant, je peux commencer et choisir l'une de ces options. J'aimerais peut-être opter pour Merge. Confirmez la fusion. Et maintenant, toutes les modifications liées à ces fonctionnalités sont fusionnées dans la branche principale. Donc vous voyez tous ces fichiers ici, un point TXT et deux points TXT. Et nous sommes dans la branche principale. Tout au long de ce processus, Luke n'a jamais été ajouté en tant que collaborateur dans le dépôt d'origine ou dans le dépôt amont. Pourtant, il a pu contribuer à ce projet. J'espère que c'est logique. Je te verrai ensuite. 101. 1308 Explorer le projet public existant: Dans cette vidéo, nous allons explorer l'un des projets existants disponibles sur GitHub et voir si nous pouvons le comprendre en fonction de ce que vous avez appris dans ce chapitre. Si vous avez un projet en tête que vous connaissez déjà, vous pouvez le rechercher ici. Est-ce que vous pouvez aller explorer, explorer certains des projets publics. Vous pouvez également consulter des projets basés sur un sujet particulier. Vous allez voir ici une liste de sujets classés par ordre alphabétique. Voici une liste de sujets populaires. Cliquons sur peut-être réagir. Ouvrons au hasard tous les projets ici. Un point x est. Je vais simplement choisir quelque chose au hasard. Peut-être ce cadre emblématique. La première chose que vous remarquerez une fois que vous visiterez la page du projet est le fichier Lisez-moi. fichier Lisez-moi constituerait généralement des informations sur le logiciel, comment vous pouvez l' installer au cas où si vous souhaitez commencer en tant que contributeur pour ce projet, quelles sont toutes les étapes impliquées dans cela ? Pour commencer en tant que contributeur, vous trouverez des projets qui sont des plantes et de nombreuses informations de ce type dans le fichier Lisez-moi. C'est donc probablement le point de départ. Si vous souhaitez vous lancer dans un projet en particulier. Une fois que vous avez parcouru le fichier Lisez-moi, vous pouvez commencer à utiliser la contribution. Mais explorons la section Pull Request ici. Comme vous pouvez le voir actuellement, il y a environ 33 demandes d'acteurs médiocres qui n'ont pas encore été fusionnées, sont examinées. En gros, vous allez voir quelques types de demandes. Le premier est celui nous avons parlé lors de nos précédentes conférences. Le second est quelque chose dont nous n'avons pas encore parlé. Cela s'appelle Draft Pull Requests. Vous pouvez dire qu'une pull request particulière est un brouillon pour demande. En regardant cette icône, si elle est grisée, c'est qu' il s'agit d'un brouillon de pull requests. Vous vous demandez peut-être ce qu' est un brouillon pour les demandes. Nous allons en parler lors des prochaines conférences. Mais en gros, si vous avez des modifications qui ne sont que des modifications proposées pour discuter ou pour recueillir des commentaires, mais qui ne sont pas vraiment destinées à être fusionnées. Ensuite, vous pouvez créer un brouillon pour les demandes. Lancez simplement cette discussion. Tout le monde peut réellement jeter un œil aux modifications de votre code et y ajouter des commentaires. Et sur cette base, vous déciderez si vous voulez procéder ou non. Vous remarquerez également ces étiquettes à droite du titre de chaque pull requests. Encore une fois, c'est quelque chose que nous aborderons dans les prochaines conférences. Mais les étiquettes vous permettent essentiellement de classer les demandes de sondage. En d'autres termes, cela vous aiderait à catégoriser les mauvaises demandes. Par exemple, si je clique sur cette étiquette, vous verrez toutes les pull requests correspondant à cette étiquette en particulier. En tant que propriétaire du dépôt, si je souhaite jeter un œil à la liste des pull requests qui correspondent à une étiquette particulière. Je peux le faire. Vous voyez peut-être un tas d'autres choses dont nous n'avons pas encore parlé. Nous les explorerons peut-être lors de prochaines conférences. Mais je suppose que vous avez atteint un stade où vous pouvez apprendre des choses par vous-même. En fait, l'objectif de ce cours est de vous permettre de vous démarquer. Je ne peux vraiment pas enseigner tout ce qui existe. Mon travail consiste à vous mettre à l' aise avec la technologie. Et je pense que nous avons atteint ce stade. C'est maintenant à vous d'explorer, d' aller au-delà et de faire quelque chose pour développer davantage ces compétences. L'une des meilleures façons d'y parvenir est contribuer réellement à l'un de ces projets. Par exemple, si vous apprenez React ou Python ou quoi que ce soit d'autre, jetez simplement un coup d'œil aux nombreux projets qui sont ici liés à ce sujet particulier et commencez à y contribuer. Chaque projet doit comporter des instructions sur la façon de démarrer en tant que contributeur. Vous pouvez passer par là et commencer à contribuer. Ce sont donc toutes les pull requests soulevées par des personnes comme vous et moi. Et vous pouvez voir que ce projet a été bifurqué plus de 13 000 fois. Au moment de cet enregistrement. Jetons un coup d'œil à la liste des problèmes. Il y a donc environ 554 problèmes actuellement. Si vous souhaitez signaler un bogue ou suggérer une nouvelle fonctionnalité, vous pouvez également le faire en cliquant sur nouveau problème. Vous pouvez ajouter le rapport, un bogue ou demander une fonctionnalité. Vous pouvez consulter la documentation, etc. Cette mise en page est en fait personnalisée pour ce projet. Vous pouvez voir une mise en page légèrement différente en fonction du projet que vous visualisez. Par exemple, supposons que j'ai utilisé leur logiciel et que j'ai trouvé un bogue, puis que je voulais signaler ce bogue. Je peux donc certainement cliquer dessus. Et ils ont conçu un format pour signaler le bogue. Tout d'abord, ils voulaient s' assurer que je lisais les directives de contribution. Une fois que je l'ai fait, je peux cliquer sur cette case à cocher, leur code de conduite, etc. Washington, quel bug est en train de décider ? Quel est le comportement actuel, quel est le comportement attendu ? Des étapes claires à reproduire et un tas d'autres informations pour aider quelqu'un qui souhaite corriger ce bogue à obtenir toutes les informations dont il a besoin pour corriger le bogue. Revenons aux problèmes. Vous pouvez donc jeter un œil à ces questions. Si vous pensez pouvoir corriger l'un de ces problèmes, vous savez déjà quoi faire. Il suffit de forker le projet, de cloner le projet, votre machine locale, de corriger le bogue, de pousser ces modifications vers le dépôt bifurqué cloner le projet, votre machine locale, , puis de lever les pull requests. Comme je l'ai déjà dit, prenez cela comme une tâche et contribuez à un projet étrange, sont des projets précieux sur GitHub. Une fois que vous aurez fusionné ou approuvé vos pull requests par les propriétaires de code, cela vous donnera beaucoup de satisfaction et vous donnera un sentiment d'accomplissement. Une fois que tu verras ça se produire. L'ensemble du processus peut prendre un certain temps . Mais je vous recommande vivement de le faire. Et de cette façon, tu mets tout en place. Ce que vous avez appris dans ce cours jusqu'à présent. Dans la suite du cours, nous allons parler toutes les pièces manquantes de ces technologies. Mais comme je l'ai déjà dit, je pense que nous avons atteint un stade où vous êtes seul et vous avez appris tous les sujets essentiels de Git et GitHub. Je vous souhaite bonne chance, mais nous n'avons pas encore terminé le cours. Nous avons également beaucoup d'autres sujets à discuter. Alors oui, prenez-le comme une tâche et contribuez à des projets précieux pendant une journée de congé. Je te verrai ensuite. 102. 1401 Stratégie de branchement: Parlons de la stratégie de création de branches. Nous avons le master ou la branche principale. Et d'une manière générale, tout ce qui entre dans la branche principale ou la branche principale doit être prêt pour la production. En d'autres termes, vous devez supposer que l'eau pénètre dans la branche principale ou la branche principale est quelque chose que votre client va commencer à utiliser. En fait, vous pourriez tout aussi bien avoir mis en place une sorte d'automatisation dans laquelle il choisira constamment le code dans la branche principale ou principale, créera un artefact et le déploiera sur l'inscription en production afin que vos clients désormais recevoir toutes ces nouvelles mises à jour ou fonctionnalités. Par exemple, imaginez que vous développez un système d'exploitation tel que Windows. Au moment de livrer quelque chose sur la branche principale ou principale, vos clients peuvent voir apparaître une fenêtre contextuelle indiquant qu' un nouveau Service Pack est disponible à installer. Ils installeront ensuite ce Service Pack pour obtenir toutes les dernières fonctionnalités ou corrections de bogues. Le fait qu'il s'agisse d'un code prêt pour la production signifie que vous devez faire attention à ce qui se passe à l'intérieur la branche master ou de la branche principale. Ce qui se trouve à l'intérieur de la branche principale ou principale doit être absolument testé. Code de qualité garantie que vous ne pouvez vraiment pas risquer d' avoir des bugs. Donc évidemment pour cette raison, il ne peut pas rendre la branche master ou la branche principale disponible pour que les développeurs puissent apporter leur code. Si vous le faites, chaque fois que quelqu'un fusionne le code dans la branche principale pour chaque fonctionnalité, vos clients recevront également ces mises à jour, qui ne sont bien sûr pas testées. De toute évidence, ce n'est pas une bonne pratique. Nous allons donc avoir une autre branche appelée branche de développement. Et ce sera la branche la plus active à laquelle tous les développeurs contribueront. En fait, au moment où nous créerons un dépôt GitHub, nous allons faire de la branche de développement la branche par défaut, de sorte que chaque fois que quelqu'un clone le code sur sa machine locale, nous verrons branche de développement en tant que branche par défaut. En fait, nous n' allons laisser personne contribuer à la branche principale ou à la branche principale. Au lieu de cela, nous n'ouvririons que la branche de développement ou la contribution. Seul un groupe particulier de personnes aura les autorisations sur la branche principale ou principale pour fusionner le code testé pour la qualité. Et même en développement, chaque fois que quelqu'un fournit un code, une pull request est déclenchée. Nous pourrions aussi bien avoir une sorte d'automatisation ici pour vérifier la qualité du code. Par exemple, vérifier s'il existe des failles de sécurité, essayer d'effectuer une analyse, rechercher des erreurs de programmation, etc. pour vous assurer que le code est toujours conforme aux normes de qualité de l'organisation chaque fois que quelqu'un contribue à cette branche. Imaginez maintenant qu' il existe un tas de fonctionnalités fournies sur la branche de développement. Et c'est à ce moment-là nous avons réalisé que nous pouvions réellement libérer tout ce foetus à l'utilisateur final. Nous pouvons maintenant fusionner toutes ces modifications avec toutes les dernières fonctionnalités de la branche master. De même, vos clients commenceront à utiliser. Mais il nous reste encore une étape à franchir. Nous allons avoir une autre branche appelée la branche release. Et c'est pour cela que nous allons fusionner tous les derniers développements de la branche de développement. La branche release se situe entre la branche principale principale et la branche de développement. C'est un peu comme une inscription de pré-production où nous pouvons effectuer des tests d'automatisation pour nous assurer que toutes les fonctionnalités fonctionnent comme prévu. Une fois que le test est terminé, tout est appelé l'assuré. Nous allons ensuite fusionner toutes les modifications de branche Release vers la branche master actuelle. Et le code deviendrait désormais la version officielle du logiciel que les clients utiliseront. Eh bien, je suis sûr que tout cela peut sembler déroutant. Permettez-moi donc de prendre un exemple en temps réel et de vous présenter à nouveau ce diagramme. Je comprends donc mieux et nous le ferons ensuite. 103. 1402 Stratégie de branchement avec scénario en temps réel: Bien, comprenons tout cela avec un exemple rapide en temps réel. Imaginons donc que nous ayons un groupe de développeurs qui ont contribué leur code, tout un tas de fonctionnalités à la branche de développement. Ou il se peut que votre projet ait été bifurqué par un tas de personnes. Et ils ont soulevé des pull requests qui ont finalement été fusionnés dans la branche de développement. Mais en fin de compte, nous avons un tas de fonctionnalités dans une branche de développement. Et c'est à ce moment-là nous avons réalisé que nous pouvions réellement le livrer au client sous la forme d'une nouvelle version. Maintenant, nous pouvons simplement fusionner tous ces sons de modifications dans la branche release. Mais avant cela, nous allons créer une branche supplémentaire, la version un point ou pas du tout, supposant qu'il s'agit la toute première version du logiciel que nous publions. Le type de format que nous suivons pour aggraver le logiciel est ce que l'on appelle le versionnement sémantique. Nous allons en parler lors des prochaines conférences. Mais pour l'instant c'est la version. Et nous allons nommer notre branche avec ce numéro de version. Vous savez, le but de créer cette branche en un rien de temps. Donc, une fois que nous avons créé une branche appelée portion one point o o à partir de la branche de développement. Nous allons ensuite fusionner toutes ces modifications sur la branche release. Et c'est là que se déroulent tous les tests et toutes les autres choses que vous voulez faire, vous pouvez le faire ici avant de fusionner ces modifications dans la branche master, qui devrait être code prêt pour la production. Il finit donc par se retrouver dans la branche master ou la branche principale également. L'avantage de cette stratégie est que pendant que vous êtes occupé à publier le logiciel et le tester minutieusement, avant de le mettre en production, Rome et d'autres développeurs peuvent continuer à travailler sur cette tâche et diluer les fonctionnalités de la branche développement. Imaginons maintenant que le client ait signalé un bogue. Peut-être qu'un logiciel permettrait au client signaler un bogue au moment où il l'a défini. Supposons donc que le client de la vision trouvé le bug, il l'a signalé. Et vous vous rendez compte qu'il s'agit en fait un bogue très grave qui doit être corrigé en priorité. Vous devez donc créer une branche à partir de cette branche de version. Et vous allez incrémenter la valeur d'une unité. Encore une fois, cela s'appelle le versionnement sémantique. Nous allons en parler. Mais vous allez essentiellement créer une branche à partir de la version précédente. Et c'est là que vous allez corriger le bogue. Une fois que vous aurez corrigé le bogue, vous allez tester toutes les modifications. Ensuite, vous allez fusionner tous ces changements dans la branche de développement ainsi que dans la branche release et éventuellement sur la branche master ou la branche principale également. Donc, le client aura le correctif pour le rapport de bogue que je vais réellement démontrer tout cela sur GitHub très bientôt afin que vous ayez une meilleure idée ce qui se passe exactement ici. Je te verrai ensuite. 104. 1403 Versioning sémantique expliqué: Parlons de la gestion sémantique des versions. versionnement sémantique est une pratique standard suivie pour adorer une version logicielle particulière, une bibliothèque ou une API. Et voici le format du versionnement sémantique. La première partie est la version majeure. La deuxième partie est la version mineure et la troisième s' appelle un patch. La façon dont fonctionne le versionnement sémantique dans K, software. Le logiciel est légèrement différent de la façon dont il fonctionne dans le cas d'une API. Parlons d'abord d'un logiciel, un éditeur vidéo ou d'un système d'exploitation, etc. Ainsi, chaque fois que vous avez des changements importants y a une énorme quantité de fonctionnalités. Ou peut-être avez-vous supprimé certaines des fonctionnalités existantes qui sont considérablement modifiées, fonctionnalités existantes, alors vous pouvez envisager d'incrémenter la version majeure. Lorsque vous faites cela, vous allez réinitialiser les valeurs de mineur et de patch à 0. Ou si vous ne disposez que de quelques fonctionnalités et qu'elles ne sont pas très importantes, vous pouvez envisager d' incrémenter le numéro de version mineure. Et si vous avez des corrections de bogues ou correctifs logiciels en plus de cette version, vous pouvez envisager d' incrémenter la version du correctif au fur et à mesure que vous introduirez de nouveaux correctifs, vous continuerez à incrémenter le numéro de patch comme ça. Disons maintenant que vous avez travaillé sur quelques fonctionnalités supplémentaires et qu'il ne s' agit que de modifications mineures. Vous pouvez à nouveau incrémenter le numéro de version mineure, mais vous devez ensuite réinitialiser la valeur du correctif à 0. C'est ainsi que fonctionne le versionnement sémantique. Et comme je l'ai déjà mentionné, la façon dont cela fonctionne dans le cas d'une API est légèrement différente d' une API chaque fois que vous incrémentez la valeur de la version majeure signifierait que vous avez introduit des modifications importantes qui ne seraient plus rétrocompatibles. Par exemple, vous avez peut-être supprimé certaines fonctionnalités ou modifié de manière significative certaines fonctionnalités existantes. Cela signifie que tous les projets que nous utilisons version précédente de votre bibliothèque devraient envisager de modifier leur code avant de pouvoir utiliser la dernière version de votre bibliothèque. C'est ce que cela signifie lorsque vous incrémentez la version majeure. Cependant, l'incrémentation de la version mineure signifierait que les nouvelles fonctionnalités ont été ajoutées et que personne n'a besoin de modifier le code pour le rendre compatible avec votre bibliothèque. Les patchs sont similaires au patch dont nous avons parlé plus tôt. Si nous l'incrémentons, cela signifie que vous avez fourni un correctif de bogue ou un correctif de type hotfix. C'est ainsi que fonctionne le versionnement sémantique. Je te verrai ensuite. 105. 1404 Comprendre les balises de git: Parlons des tags et obtenons. Etag est simplement une différence qui pointe vers un point précis de la bonne histoire. En d'autres termes, l'attaque ne ferait que pointer vers un commit spécifique. Cela peut ressembler à une branche. Même la branche pointe vers un commit spécifique, et même la balise pointe vers un combat spécifique. Mais la différence entre les deux est que la branche est mise à jour chaque fois que nous effectuons un nouveau commit dans la branche. Et la branche indiquerait ce dernier commit, tandis que tag resterait constant. Si nous créons une balise pointant vers un commit particulier, elle restera comme ça pour toujours, sauf si nous faisons quelque chose explicitement avec cette balise. Quel est l'avantage de créer un tag ? Pourquoi voulons-nous créer une référence à un commit particulier et la maintenir constante ? Allons y jeter un œil. Ceci est tiré de notre exemple précédent, 1 seconde, supposons que nous avons lancé un nouveau logiciel et nous avons finalement des modifications dans la branche master. C'est à ce moment-là que nous allons créer une étiquette, en lui donnant le numéro de version du logiciel qui porte son nom. Puisque nous supposons qu' il s'agit d'une toute première version de notre logiciel, nous allons l'aggraver avec un point ou d'une toute première version de notre logiciel, nous allons l'aggraver avec un point ou un point. Et cette balise pointe vers ce commit en particulier, la branche master ou la branche principale. Supposons maintenant que nous avons fourni un correctif de type hotfix. Et encore une fois, nous avons livré ce correctif dans la branche master. Nous allons créer une autre étiquette, lui donnant un numéro de mouvement. Comme il s'agit d'une correction de bogue ou d'un correctif de type hotfix, nous avons simplement incrémenté le numéro de correctif d'une unité. Donc, essentiellement, nous suivons le versionnement sémantique ici et cette balise pointe ou avons la référence du commit dans la branche master avec ce correctif. Mais quel est l'intérêt d' avoir toutes ces étiquettes ? Eh bien, un autre cas d'utilisation est, disons que je voulais créer un artefact basé sur une version spécifique. Je peux peut-être lancer une commande disant que je veux créer un artefact pour la version un point o point o. Devinez quoi ? Je peux exécuter la commande en spécifiant cette balise. Et l'outil créerait l'artefact pour moi, qui pourra ensuite être déployé sur l'inscription en production, etc. Ou peut-être pourrais-je le mettre dans les notes de version pour que les clients puissent le télécharger et l'utiliser. Nous ne pouvons pas utiliser branch dans ce cas, car la branche serait mise à jour de temps en temps. Au moment où nous effectuons un nouveau commit dans la branche, balises seraient utiles dans une telle situation. Ensuite, nous allons examiner tout cela en action afin que vous ayez une en action afin que vous ayez image complète de ce qui se passe exactement et de la façon dont cela va fonctionner. Je te verrai ensuite. 106. 1405 Flux de travail de Braching en action: Bon, voyons maintenant tout en action et j'espère que vous êtes prêt pour ça. Commençons par créer un nouveau dépôt. Appelons-le peut-être super audio. Peut-être que nous sommes en train de créer un outil de montage audio. Et peut-être aimerais-je également ajouter le fichier Lisez-moi. Si vous le souhaitez, vous pouvez aller dans les paramètres et changer le nom de branche par défaut de main par quelque chose d'autre si vous le souhaitez. Peut-être que nous pouvons changer ça en maître. Ce n'est pas obligatoire. Mais je le fais quand même. Je vais créer le dépôt. Comme vous pouvez le voir, nous avons la branche master. Et ce sera la clé de production, qui signifie que tout ce qui se trouve dans la branche principale sera inclus dans l'inscription à la production. Ensuite, créons les deux autres branches. L'une sera la branche de pré-production, et nous saisirons le nom comme release. Et une autre branche est dédiée au développement. Appelons-le « développer ». Cette branche aurait la dernière version du dernier code de tous les contributeurs qui collaborent avec nous. Passons maintenant aux paramètres et définissons la branche de développement comme branche par défaut. Juste pour que si quelqu'un clone le projet, il voit la branche de développement comme une branche par défaut où il peut contribuer. Nous allons donc changer cette branche de master à develop et cliquer sur Mettre à jour. Maintenant, si je reviens en arrière, vous allez voir le rameau d'olivier déjà choisi parce que ce sera la branche par défaut maintenant. Maintenant, afin de simuler le comportement, d'avoir un tas de fonctionnalités en place dans la branche de développement. Je vais simplement ajouter quelques fichiers. Mais vous devez supposer que nous avons peut-être apporté modifications liées aux fonctionnalités et contribué à cette branche. Il se peut que quelqu'un d'autre pour le projet soulève des pull requests sur cette branche en particulier. Donc, peu importe qui gère ce projet, on s'attend que la course tire des demandes sur la branche dollar. Ils n'ont aucune sorte d'autorisation ou nous n' attendons pas que quelqu'un fasse des contributions à la branche release, hard à la branche principale ou à la branche master. Alors allons-y et créons quelques fichiers. Créez un nouveau fichier, appelons-le avec un point TXT. Pour simplifier les choses, nous allons créer un autre fichier. Créez une nouvelle fonction de fichier pour pointer TXT par exemple, et validez le code. Nous avons donc un tas de commits ici. Le premier était le fichier Lisez-moi, et les deux autres concernent les fonctionnalités. Quelle est la prochaine chose à faire ? Peux-tu deviner ? En supposant que nous souhaitions publier notre logiciel ou la première version de notre logiciel pour l'utilisateur final. Eh bien, nous allons d'abord créer une autre branche. Et nous allons donner à cette branche un nom de version sémantique. Comme il s'agit d'une très fausse version du logiciel que nous lançons, nous allons le nommer comme un point ou un point o. Nous allons donc créer cette branche à partir de la branche de développement. Pendant ce temps, d'autres développeurs peuvent continuer à contribuer à la branche dollar. Mais ce que nous allons faire ensuite est de fusionner tous ces changements dans la branche release de cette branche particulière que nous venons de créer. Devinez ce que nous devons faire ensuite. Façon de lancer des pull requests. Actuellement, la branche release ne dispose pas de cette fonctionnalité qui entraîne des changements quand les obtenir ici. Je vais aller dans Pull Requests, créer une nouvelle pull request. Ici, je vais choisir la branche release et je veux la comparer avec la branche version, appelons-la. Voici donc toutes les fonctionnalités qui conduisent à des changements. Et je vais créer la pull request. En supposant que nous ayons effectué toutes les formalités de révision, numérisation du tableau et tout, allons de l'avant et fusionnons toutes ces modifications. Nous ne voulons pas supprimer cette branche pour l'instant , car elle sera utile ultérieurement. Donc, si vous retournez dans le dépôt et que vous accédez à la branche release, vous aurez désormais toutes les modifications liées aux fonctionnalités. Nous sommes donc en train d'exécuter des tests automatisés et en supposant que tout fonctionne comme prévu, nous avons maintenant décidé de pousser tous ces changements dans notre module, ces changements sur la branche master afin que nos clients vont commencer à utiliser notre logiciel. Une fois de plus, nous allons lancer une autre Pull Request. Nouvelle pull request. Ici, je vais choisir la branche master. Et ici je vais choisir la branche release. Et nous allons créer la pull request. Fusionnons également toutes ces modifications dans la branche master. Peut-être avec trois bits et fusionner. Nous pouvons également utiliser Squash commit pour combiner tous les commits en un seul commit. Mais je pense que c'est bon pour nous. Nous avons donc officiellement mis notre logiciel à la disposition de l'utilisateur final. Donc, si je clique sur Maître, vous verrez la fonctionnalité mener à des modifications ici. Idéalement, nous sommes censés créer un tag ici même. Mais nous allons parler des tags dans les prochaines conférences. Je te verrai ensuite. 107. 1406 flux de travail à chaud en action: Ok, continuons. Supposons maintenant que votre client a signalé un bogue et que vous vous rendez compte qu'il s'agit en fait d'un bogue critique qui doit être corrigé en priorité. n'avez donc pas l'intention d'avoir un correctif de type hotfix. Quelle est donc la première chose que nous devons faire ? Eh bien, nous avons déjà une agence à portée de main. Celui que nous avions précédemment créé avec le nom de version. C'est là que cela s'avère utile. Nous pouvons créer une autre branche à partir de cette branche pour corriger le bogue. Ensuite, nous allons fusionner tous ces changements dans la branche de développement ainsi que dans la version et éventuellement sur la branche master également. Ainsi, les clients recevraient une mise à jour avec le correctif. J'ai donc choisi cette branche de version particulière. Créons maintenant une autre branche pour corriger le bogue et obtenir la version que nous devons donner ici. Puisque vous marchez sur le correctif, vous avez incrémenté la valeur de la version du correctif d'une unité. Cette fois, le nom de la succursale sera 101. Je vais créer cette branche. Encore une fois pour simuler le comportement de correction d'un bogue. Permettez-moi simplement de créer un bogue de fichier, point fixe dxdy, peu importe. Et je vais valider ce changement. Nous devons maintenant fusionner ces modifications dans la branche de développement. Nous pouvons soit le faire à partir d'ici. Nous pouvons aller chercher la section transversale et créer une nouvelle pull request. Choisissez la branche que nous venons de créer et nous allons la comparer à la branche de développement. Nous avons donc réglé ce problème ici. Créez une classe de produits et laissez-nous sortir. Allez-y et fusionnez le correctif de bogue dans la branche de développement. Et bien sûr, si vous retournez dans la branche de développement, vous verrez le correctif de bogue. Nous allons également suivre des étapes similaires pour la publication. Nous sommes allés lancer une pull request. Nous allons choisir la version ici. Et la branche de correction de bogue a effacé les pull requests. Et cela va de l'avant et fusionne ces changements. Maintenant, après de nombreux tests, les choses humaines fonctionnent très bien. Nous allons continuer et fusionner les modifications de la branche Release vers la branche master. Comme vous pouvez le voir, nous avons maintenant le correctif dans la branche release. Créons une pull request très rapidement. Nous allons comparer la branche release. Je suis désolée. Nous allons comparer la branche master et la branche release et fusionner toutes ces modifications dans la branche master. Pour revenir en arrière et passer à la branche master, vous devriez pouvoir voir le correctif et c'est ainsi que vous fournissez un correctif. Ensuite, nous allons parler de la façon dont nous pouvons créer des balises. En fait, nous n'avions pas créé le tag dans la version précédente de notre logiciel. Mais nous pouvons également créer des balises pour les validations déjà effectuées. Comment nous y parviendrons, il y a quelque chose dont nous allons parler ensuite. Je te verrai ensuite. 108. 1407 Créer des étiquettes Annotées vs légères Poussez les étiquettes vers la distance: Voyons comment nous pouvons créer des balises. Nous pouvons ajouter les balises create sur GitHub, ou nous pouvons également le faire à partir de la ligne de commande depuis notre Git local. Nous allons voir les deux voies. Voyons d'abord comment nous pouvons le faire localement à partir de Git Bash. D'ailleurs, afin de gagner du temps, j'ai déjà ajouté M. Luke parmi les collaborateurs de ce projet. Voici le compte de Luke. La première chose que Luke va faire est qu'il va réellement cloner ce projet sur sa machine locale. Supposons que c' est l'ordinateur de Luke. Je vais lancer Git Bash ici. Et clonons rapidement le projet. Clone Git. Je vais coller l'URI. Passons donc à l'intérieur de ce projet. Videz l'écran. Créons maintenant des balises. Nous pouvons ajouter la création d'un tag léger ou d'un tag annoté. Il existe donc deux types de balises que nous pouvons créer. Quand il s'agit d'une balise légère, il suffit d'un nom ou d'un identifiant et nommé à un commit particulier. Alors qu'en ce qui concerne la balise annotée, en plus d'un nom et d'un point pour accommoder. Il contiendra également certaines métadonnées, comme le nom du tagger, adresse e-mail, la date, etc. Si vous souhaitez stocker toutes les métadonnées avec le tag, nous ferions mieux de créer un tag annoté et non un tank léger. Et dans la plupart des cas, il est toujours pertinent de créer une étiquette annotée ou un char léger. Pour des raisons évidentes. Nous saurons qui l'a créé quand il l'aura créé. Et nous connaîtrions même l'adresse e-mail de la personne qui a créé ce tank. Voyons d'abord comment créer une balise annotée. En gros, nous n'avons pas créé tag pour la première version de notre application. Alors laissez-nous d'abord laquelle maîtriser la branche. Si je fais git branch, iPhone, non. Vous voyez que toutes ces branches sont des branches de suivi à distance, mais nous n'avons pas de branche locale pour la branche master. Donc, pour cela, faisons git checkout ou passons à la branche master. Examinons maintenant la liste des commits qui se trouvent dans la branche master. C'est donc là que nous devrions idéalement créer une balise qui représente la toute première version de notre application. C'est donc juste avant le correctif que nous avions donné. Alors, comment allons-nous créer un tag pour l'un des commentaires précédents ? Allons y jeter un œil. Donc, la commande pour créer la balise est git tag, tiret une balise à quatre annotations. Et nous allons spécifier un identifiant unique ou un nom pour cette balise. Et selon la pratique standard, nous voulons donner la version sémantique de notre version. Ce sera donc la toute première version de notre application. Et nous allons maintenant spécifier le HashCode de la torche. Nous voulons que ce tag pointe vers. C'est comme si nous avions remonté le temps et créé un tag. Lors de cet engagement particulier. Je vais coller ce code de hachage. En plus de cela, nous allons également fournir un message significatif décrivant le sujet de ce tag. Une description à ce sujet semblait avoir tout gâché. Retapons la commande. Balise Git. Tiret a. Voir one.org.au spécifié le trait d'union du HashCode m. Description de la somme. Si vous ne fournissez pas le message avec l'option tiret m, vous verrez un éditeur de texte par défaut s' ouvrir pour vous permettre de saisir un message. Si vous fournissez cette option, note, etc., sera ouvert. Cela devrait donc créer un tag pour nous. Si vous exécutez la commande git tag, vous allez voir la liste de toutes les balises disponibles. Donc, si quelqu'un devait cloner le projet, il verrait également toutes ces balises. Maintenant allons-y et créons une étiquette légère. Et la commande pour cela est assez simple. Obtenez une étiquette et un identifiant ou un nom pour cette étiquette. Cette fois, je vais dire « un point, un point ». Parce que par défaut, lorsque vous essayez de créer une balise, elle pointe vers le même commit que celui vers lequel pointe la tête. Donc, actuellement, cela pointait vers la dernière branche master commit off. Et donc cette balise, qui est une balise légère, parce que nous n'avons pas fourni l'option de césure, va également pointer vers la branche master commit off desk, qui inclut le correctif de bogue. Et si vous vous souvenez, selon la gestion sémantique des versions, nous avions incrémenté la valeur de la version du correctif d' une unité. Appuyons sur Entrée. Et nous venons de créer un nouveau tag. L'une est une balise annotée, et l'autre est une balise légère, qui ne possède aucun type de métadonnées. Comment publier toutes ces balises dans le dépôt distant ? Eh bien, nous allons simplement utiliser la commande push standard. Mais nous devons spécifier explicitement que nous voulons également pousser des balises. Par défaut, la commande push ne pousse pas les balises. Je vais donc lui faire savoir explicitement. Nous allons donc dire que git push origin est la source distante où nous voulons également appliquer toutes ces taxes. Nous pouvons spécifier la balise que nous voulons pousser en spécifiant son nom, identifiant, comme c'est le cas. Nous pouvons également dire tags pour pousser toutes les balises vers le dépôt distant. Comme Luke a déjà l'autorisation pour ce dépôt, nous avons pu placer toutes ces balises sur ce dépôt. Et vous pouvez les voir ici. Si vous cliquez sur ces balises, vous verrez que nous avons ces deux chars qui continueront ensuite. 109. 1408 Comprendre comment les étiquettes sont stockées État de tête détaché avec des étiquettes: Auparavant, nous avions créé quelques balises. L'un est une étiquette annotée, l'autre est un char léger. Voyons comment ils sont réellement stockés dans. Si vous allez dans le dossier refs, vous verrez maintenant ce dossier avec les balises de nom. Et c'est là que vous allez voir ces deux balises. Mais ils annotent que la balise est en fait stockée en tant qu'objet. Alors que le char léger ressemble à une branche, ce n'est pas un objet. Ouvrons donc Washington 101. Et il s'agit d' un commentaire précis. Essayons d'imprimer cet objet avec ce hashCode. Fichier Git cat. Tout d'abord, examinons le type de cet objet. Comme vous pouvez le voir, il pointe vers l'objet comète. Si vous imprimez cet objet, vous allez voir les détails de ce commit. Mais maintenant ouvrons le fichier, qui était une balise annotée, et voyons vers quoi il pointe. Permettez-moi de copier ce code de hachage, revenir à Git Bash et d'essayer d'imprimer le type de l'objet. Cette fois, ce sera de type tag. Et si vous regardez le contenu de cet objet de balise, vous verrez le commit vers lequel il pointe. Et il contient également quelques métadonnées. Comme l'identifiant de la balise, personne qui l'a créée et une description de la balise également. Nous pouvons également afficher l'état du dépôt au niveau d'une balise particulière à l'aide de la commande git checkout. Permettez-moi donc de faire git tag pour jeter un œil à la liste des balises disponibles. Et je vais utiliser la commande git checkout, en spécifiant le nom de la balise. J'aimerais peut-être obtenir mon dépôt à cette date. Et comme vous pouvez le voir, nous sommes dans un état de tête détaché. Nous en avons déjà parlé dans l' un de nos précédents chapitres. Mais si vous revenez au répertoire de travail, vous ne verrez pas ce correctif de type hotfix. Parce qu'au moment de la création de cette balise, nous n'avons pas cette solution. J'espère que c'est logique. Je te verrai ensuite. 110. 1409 publie et crée des étiquettes sur GitHub: Très bien, parlons des versions. Selon ce que GitHub a à dire sur les lasers. Voici ce qui est écrit. Vous pouvez créer un logiciel release to packet avec les notes de version et les liens vers des fichiers binaires que d' autres personnes peuvent utiliser. cet appel, vous allez fournir la documentation technique sur votre version. Vous devriez donc répertorier toutes les modifications qui font partie de la nouvelle version. Les étapes d'installation, les binaires sont des exécutables, etc. Vous devez inclure toutes ces informations dans les notes de version pour aider vos clients ou les utilisateurs finaux à tout comprendre sur la nouvelle version qu'ils ont besoin de savoir. Alors allons-y et essayons de créer une nouvelle version sur GitHub. Au fait, votre organisation utilise peut-être un autre outil pour documenter la publication. Si vous ne disposez pas d'un tel outil, nous pouvons utiliser GitHub pour le même. Nous pouvons associer un tag pour une version en particulier. Nous pouvons choisir l'un des modèles existants par exemple. Ou nous pouvons créer un nouveau tag. C'est ainsi que vous allez créer un nouveau tag sur GitHub. Par exemple, vous pouvez peut-être dire « nous un point 0 point deux », ou quoi que ce soit d'autre. Pour le moment, nous n' avons pas de nouveaux changements. Cela n'a aucun sens pour nous d'augmenter la version de notre logiciel. Au lieu de cela, nous allons simplement utiliser l'une des balises existantes. Comme ça. Nous allons lui donner un nom. Relâchez V, un point ou un point, par exemple. Ici. Votre vélo met un certain temps à documenter tout ce qui concerne la libération. Peut-être pourriez-vous énumérer tous les problèmes qui ont été résolus, toutes les nouvelles fonctionnalités qui ont été introduites. S'il existe des fonctionnalités obsolètes, vous devriez également les répertorier. Peut-être quelques étapes d'installation, téléchargeable, exécutable, etc. Vous mettrez tout ce que vous voulez que votre utilisateur final voie et comprenne à propos de la version. Et une fois que vous avez terminé, vous pouvez publier la version. Et c'est comme ça que ça a l'air. De toute évidence, nous ne l'avons pas suffisamment renseigné pour vraiment voir quelque chose de significatif. Mais c'est publié pour vous. Les clients peuvent consulter toute la description de la version. Et Guitar Bass a automatiquement téléchargé le code source. Est-ce que quelqu'un pourrait télécharger s'il le voulait ? C'est donc à peu près tout. Je te verrai ensuite. 111. 1501 Retirer les approbations de la demande de tirette sur les échelles: D'accord, parlons de cette règle de prédiction de branche qui dit de rejeter la queue, approbations de pull request, de nouveaux commits sont poussés. Cela signifie que chaque fois que quelqu' un lance une pull request et suppose également que même la révision est terminée, mais que cette pull request, maintenant avant de fusionner ces modifications une autre branche, a conduit à une équipe dollar par kilomètre ou des changements dans la branche que nous voulons fusionner. Maintenant, si nous permettons que les changements soient revus une fois de plus, ne sont pas sa paroisse. Cette option signifie que si nous l'activons, cela signifie que nous voulons rendre obligatoire le processus de révision, une fois de plus, examinant toutes les dernières modifications avant qu'elles ne puissent être fusionnées dans une autre succursale. Désactivez cette option, puis notez les abus nécessaires pour fusionner les modifications. Si vous avez compris ce que je viens dire, c'est très bien. Vous pouvez passer la vidéo suivante. Sinon, accrochez-vous. Je vais vous montrer la même chose. Donc, pour le moment, c'est désactivé. Permettez-moi de revenir au dépositaire et de lancer rapidement une pull request pour cela. Permettez-moi de créer une autre branche avec un nom aléatoire est df. Et nous allons aussi avoir un commit. Peut-être en ajoutant un nouveau fichier. Donnons-lui un nom, quelque chose de ce genre, et validons les modifications. Lançons une pull request. Nous allons comparer la branche principale avec la branche que nous venons de créer. Créez une pull request. Créez une pull request. Cela a donc créé les pull requests. Nous avons besoin d'au moins une évaluation approuvée avant de fusionner ces modifications. Désormais, la même personne qui a réellement lancé une pull request ne peut pas revoir son propre code. Pour ça. J'ai déjà ajouté M. Luke comme l'un des collaborateurs de ce projet. Faites-moi savoir, allez sur le compte de Luke et acceptez rapidement les modifications. Voici donc la pull request du compte Luke. Et je vais ajouter mon avis Je vais passer en revue ces modifications, en approuvant tout. Maintenant, si vous revenez en arrière pour additionner ces secondes, vous verrez que les modifications ont été approuvées et que je peux continuer et fusionner la pull request. Mais en attendant, avant de fusionner les modifications, laissez-moi essayer de créer un autre commit dans la nouvelle branche que nous venons de créer. Je vais revenir à la base de code et à cette branche. Et laissez-moi ajouter un autre fichier avec un autre nom aléatoire, comme ça et valider les modifications. Si nous revenons aux pull requests, vous allez maintenant voir ces nouvelles modifications également. heure actuelle, vous pouvez constater qu'aucun avis supplémentaire n' est nécessaire pour fusionner les pull requests. C'est parce que cette option est désactivée. Permettez-moi d'activer cette option. Enregistrer les modifications. Laissez-moi entrer rapidement le mot de passe. Et maintenant, si je devais apporter un autre changement et m' engager dans cette branche, laissez-moi le faire très rapidement. Quelque chose de ce genre. Validez les modifications. Si je reviens aux pull requests, cette fois-ci, vous verrez que nous avons besoin d'au moins une révision une fois de plus avant de pouvoir fusionner ces modifications. Eh bien, puisque Sunday est le propriétaire de ce dépôt, est capable de voir cette option pour fusionner réellement sans attendre que les commentaires soient satisfaits ou sans que la visualisation soit effectuée. Mais idéalement, les revers ne pourront pas voir cette option. Mais j'espère que vous avez compris l'intérêt de cette règle de protection des branches. Je te verrai ensuite. 112. 1502 Configurer les propriétaires de codes avec les motifs: Parlons de cette règle de protection des branches qui indiquerait qu'il est nécessaire d'examiner par les propriétaires de code. Fondamentalement, github nous permet de créer un fichier spécial avec les propriétaires de code de nom, dans lequel nous pouvons spécifier qui possède quoi en fonction des modèles de fichiers. C'est un peu similaire aux modèles que nous spécifions dans un fichier point gitignore. Mais nous précisons également à qui appartiennent les fichiers correspondant à ces modèles. Et en activant cette option, nous serons automatiquement invités à être revus. Chaque fois que quelqu'un lance une pull request qui modifie le code dont il est propriétaire. Je sais que cela semble déroutant. C'est pourquoi je vais rapidement faire la démonstration du même luminophore. Passons à notre référentiel. Et je suis dans la branche principale ici, je vais créer un nouveau fichier. Je vais nommer le fichier en tant que code ou infirmière. Il doit s'agir exactement du même nom, en majuscules. Et dans ce fichier, je vais spécifier l'un des propriétaires avec un motif. Par exemple, je pourrais dire que star point js et tous les fichiers avec extension point js seraient la propriété de disons, regardez, nous l'avons déjà considéré comme l'un des collaborateurs pour résoudre ce projet. Ainsi, quel que soit l'endroit où vous allez ajouter des propriétaires, ils doivent disposer d' autorisations d'écriture sur ce projet. Permettez-moi donc de copier rapidement l'adresse e-mail de Luke et de la coller ici. Vous pouvez également ajouter le nom d'utilisateur de Luke. Quoi qu' il en soit, Luke va maintenant être le propriétaire de tous ces fichiers. Permettez-moi de revenir sur ce dossier. Maintenant laissez-moi essayer d'effacer les pull requests avec le fichier ab.js 1. Ensuite, permettez-moi de créer rapidement une branche aléatoire. Et permettez-moi d' ajouter rapidement un nouveau fichier. Scripts point js. Convertissez le fichier. Nous allons maintenant lancer la pull request. Et au moment où je le ferai, vous verrez attendre l'examen du propriétaire du code de Luke's under Corp. Maintenant, si vous allez sur le compte de Luke, si je clique sur la pull request, c'est le compte de Luke. Regardez va dire ce message disant qu'il a besoin de revoir une pull request. Donc, puisque Luke est le propriétaire de tous les fichiers point js et que de tous les fichiers point js et quelqu'un a lancé une pull request sur la même branche où Luke a été ajouté en tant que propriétaire de ces fichiers, get a automatiquement demandé Luke pour passer en revue les modifications ou la pull request. Alors regardez, vous pouvez maintenant faire quelque chose avec cette critique. Disons qu'il a approuvé les modifications. Et maintenant, nous pouvons poursuivre et fusionner tous les changements. Cette option est déjà activée. Je l'avais déjà activé et j'ai enregistré les modifications. Et par conséquent, cela a pris effet. Si nous désactivons cette option, Luke n'aurait pas reçu la demande d'évaluation. Revenons au référentiel. En général, nous conservons le fichier des propriétaires de code dans la branche de base ou la branche par défaut. Puisque ce fichier est actuellement placé dans la branche principale, manager ou quelqu'un lance une pull request demandant de fusionner les modifications apportées à cette branche. C'est alors que ce code sur une spirale entrerait en vigueur. Il est donc préférable de conserver ce fichier dans une branche où les développeurs contribueraient leur code. Fin. À propos, il existe d'autres modèles que nous pouvons utiliser pour lesquels vous pouvez vous en remettre à la documentation officielle, sont également fournis des notes vous donnant certains des exemples de modèles ainsi que certains description. Je vais garder cela sous forme de notes que vous pouvez télécharger et prendre votre temps pour essayer de comprendre cela. C'est en fait assez simple. Les motifs sont assez similaires aux modèles que nous incluons dans le fichier point gitignore. Sauf que nous allons également spécifier que les propriétaires ont deux cornes de fichiers correspondant à ces modèles. Vous pouvez également spécifier des équipes. L'équipe serait donc propriétaire d'un ensemble particulier de fichiers. Comme dans ce cas. Si vous souscrivez un débat sur les adhésions GitHub pour votre organisation, vous pouvez également ajouter des deems. J'espère que c'est logique. Je te verrai ensuite. 113. Résolution de conversation avant de fusionner: Parlons de cette règle de prédiction de branche qui dit que la résolution de conversation est requise avant la fusion. Et au fait, nous allons ignorer de parler cette option car cela a quelque chose à voir avec des outils externes. Et en gros, si vous souhaitez effectuer de nombreux types de vérifications avant de fusionner le code dans une autre branche, vous devez activer cette option. Et parler de Ceci est définitivement en dehors du cadre de ce cours particulier car cela a quelque chose à voir avec des outils externes. Mais d'une manière générale, si vous souhaitez effectuer n'importe quel type de vérification, comme une analyse de vulnérabilité , vérifiez la présence d' erreurs de programmation dans le code. Nous effectuons une intégration continue ou déployons peut-être le code sur un serveur de génération, obtenons l'état de la construction, etc. Si vous voulez travailler pour de nombreuses choses de ce type, chaque fois que quelqu' un lance une pull request, vous pouvez les configurer ici. Et cela dépend entièrement normes de votre organisation et nous devons suivre en conséquence. Peut-être aborderons-nous tout cela dans d'autres cours DevOps, mais nous allons l' ignorer pour le moment. Revenons à cette option qui dit qu'il est nécessaire de résoudre la criminalisation avant de fusionner. Permettez-moi d'activer cette option. Démontrez ce que cela signifie exactement. Donc, en gros, les hommes au mot de passe très rapidement. Cette option est donc activée. Permettez-moi de passer aux pull requests que nous avions soulevées tout à l'heure. Et comme vous pouvez le voir, nous pouvons actuellement effectuer la fusion car leur vue est déjà faite. Mais disons que M. Luke a un commentaire à ajouter dans le code. Passons donc au compte de Luke. Permettez-moi d'ouvrir le fichier de cette pull request. Et disons que nous avons un tas de lignes de code ici. Et Luke fait un commentaire. Peut-être quelque chose comme ça. Permettez-moi de l'agrandir un peu. Je veux donc ajouter cette commande, et nous allons cliquer sur l' un de ces boutons. Permettez-moi simplement d'ajouter un seul commentaire. Et depuis que nous avions activé option de règle de protection des branches, si je reviens maintenant à la demande d'extraction du compte de l' expéditeur, laissez-moi recharger la page. Vous allez voir que la fusion est à nouveau bloquée car il y a des conversations non résolues. Supposons que l'expéditeur a répondu à ce commentaire et qu'il va mentionner la même réponse pour regarder. Oui, je l'ai vérifié. Quelque chose de ce genre. C'est encore une fois, revenez sur le compte de Luke. Il est allé voir la réponse ici. Et une fois que vous serez satisfait de la réponse, Luke résoudra la conversation. Ça l'est. L'expéditeur peut alors fusionner la pull request. Si cette option n'est pas activée, la dissolution de la conversation n'est pas nécessaire pour fusionner le code. Je te verrai ensuite. 114. 1504 Explorer toutes les autres règles de protection des branches: Parlons ici de toutes les règles de protection des succursales restantes . Elles sont assez faciles à comprendre et déjà simples. Nous pouvons donc intégrer tout cela uniquement dans cette vidéo. Quitter cette règle de prédiction de branche indiquerait que les combats signés sont obligatoires. Cela nécessite en fait que vous compreniez quels sont les commits attribués, comment nous pouvons générer des clés privées et publiques pour la signature, le cryptage, le déchiffrement, etc. Donc, cela déserte à un chapitre à part entière. Nous allons donc en parler dans le prochain chapitre. Mais terminons ce chapitre sur la règle de prédiction de branche après avoir rapidement abordé toutes les autres options que nous avons ici. Nous avons donc cette option qui indique l'historique linéaire requis. Et comme son nom l'indique, cela ne nous permet pas d' avoir des commits de fusion. Si vous avez un commit de fusion, nous n'aurons plus d'historique linéaire des commits. Disons donc que j'ai activé cette option. Laissez-moi l'enregistrer très rapidement. Si vous revenez aux pull requests, laissez-moi cliquer ici. Ce sont les pull requests que nous avions soulevées tout à l'heure. Maintenant, si je choisis cette option pour créer un commit de fusion, vous verrez ce message disant que la branche Merge nécessite un historique linéaire. C'est parce que nous avions activé cette option. Mais nous sommes toujours en mesure de voir cette option pour fusionner les pull request. C'est parce que je le fais en moins de seconde, qui est le propriétaire du référentiel ? Permettez-moi de modifier cette règle de prédiction de branche. Nous avons encore une autre option pour ne pas laisser cela se produire. Voilà donc. Si nous activons cette option qui dit ne pas autoriser le contournement, ce sont les deux paramètres. Et la description indique que les paramètres Elbow s'appliqueront aux administrateurs et aux rôles personnalisés avec l'autorisation de protection des branches de contournement. Cela signifie que jusqu'à présent toutes les règles de production de branche ne sont pas réellement appliquées aux administrateurs, ne sont pas réellement appliquées aux administrateurs ou aux propriétaires du référentiel. En activant cette option, les administrateurs sont propriétaires du référentiel ne peuvent pas réellement contourner les règles de production des branches. Permettez-moi d'activer cette option et d'enregistrer les modifications. Maintenant, si je reviens à la pull request, Sender étant l'administrateur du référentiel, ne serait plus en mesure de choisir cette option. C'est devenu grisé. Je ne peux pas non plus cliquer dessus. Si vous prenez la licence d'organisation de GitHub, vous devriez être en mesure de créer une équipe d'individus. Certains d'entre eux sont Edmond, d' autres sont des mainteneurs. Ils peuvent avoir des rôles différents. Et en activant cette option, les règles de prédiction de branche appliquées depuis un an pour les administrateurs sont la maintenance du référentiel. Entre ces deux options, nous avons cette option qui indique que les déploiements nécessaires doivent réussir avant la fusion. Eh bien, vous pouvez utiliser cette règle pour assurer que les modifications sont correctement déployées sans aucun problème pour cette mise en scène ou les tests et Romans avant que les modifications ne puissent être fusionnées dans la branche par défaut. Cela dépend maintenant des outils que vous utilisez dans votre organisation . Actuellement, nous n'avons pas de déploiement ni de configuration romaine. pouvons donc vraiment pas le démontrer. C'est peut-être le sujet d'un autre cours. Nous allons donc ignorer cela. Et il nous reste quelques options de règles de prédiction de branche. Et ces options s'appliquent à tout le monde, y compris aux administrateurs. Bonjour, les poussées de force signifient que nous voulons charger les poussées de force sur les branches protégées. Et nous pouvons même choisir qui peut le faire. Voulons-nous autoriser tout le monde avec un axe de poussée, comme les collaborateurs par exemple ? Ou voulons-nous choisir spécifiquement qui nous voulons pousser une force faible ? Par exemple, Luke est déjà ajouté comme l'un des collaborateurs. Je peux le choisir, par exemple, si je le voulais. Et enfin, nous avons un chargement de suppressions. Ainsi, en activant cette option, nous permettons aux utilisateurs de Bush Axis de supprimer les branches qui correspondent à ce modèle. Dans ce cas, nous disons que toutes ces règles de prédiction de branche sont applicables à la branche principale. Ainsi, en activant cette option, nous autorisons les personnes disposant d'un accès Push à supprimer cette branche en particulier dans ce cas. Il s'agit donc de règles de protection des succursales. Une fois de plus, nous allons faire exploser cette option. Dans le chapitre suivant. Je te verrai ensuite. 115. 1601 Imiter les engagements et la nécessité de les faire and: Permettez-moi maintenant de vous montrer quelque chose de vraiment intéressant. Je suis sûr que vous seriez surpris de voir cela se produire. Pour les besoins de cet exemple, je vais utiliser l'un des référentiels existants que nous avons utilisés tout au long de ce cours. Au cas où vous perdriez la main sur ce référentiel. Considérez cela comme un dépôt aléatoire contenant un tas de fichiers. Actuellement, ce projet compte deux collaborateurs. Nous avons l'expéditeur qui est le propriétaire du dépôt, et Luke, qui est l'un des collaborateurs de ce projet. Pour les besoins de cet exemple également, j'ai désactivé les règles de production des branches pour la branche principale. C'est pourquoi vous voyez ce message indiquant que votre branche principale n'est pas protégée. J'ai maintenant une question pour vous. Est-il possible que M. Luke fasse un commentaire au nom de Cylinder sans avoir obtenu son consentement ? Eh bien, jetons un coup d'œil. Imaginez que c'est l'ordinateur de M. Luke. Et pour vous faire gagner du temps, j'ai déjà cloné le projet. Laissez-moi ouvrir Git Bash ici. Permettez-moi de lancer la commande git config lest pour voir les configurations actuelles. Et comme vous pouvez le voir, le nom d'utilisateur et l'adresse e-mail sont désactivés. Le nom d'utilisateur de M. Luke est Luke's in the Corp et l'adresse e-mail est semble adresse e-mail. Je vais essayer de les remplacer par Saunders. Je vais dire le nom d'utilisateur global git config. Je vais donner le même nom d'utilisateur GitHub dose, comme ça. De même, nous allons également modifier l'adresse e-mail et la mettre à jour avec certaines de ces adresses e-mail. Je peux facilement l'obtenir dans ce nom et cette adresse e-mail. Mais dans la commande git log. Et jetez un coup d' œil à certains commentaires de M. Cylinder. Maintenant, si je fais git config list, vous allez voir que le nom d'utilisateur et l'adresse e-mail ou non, mis à jour avec des cylindres sont un nom et son adresse e-mail. Permettez-moi maintenant de engager et de voir ce qui va se passer. Permettez-moi de créer rapidement un fichier avec un nom aléatoire. Et je vais rester comme ce fichier très rapidement, git ajouter le nom du fichier. Et enfin git commit avec un message. Appelons ça un mauvais commit. Et je vais également transférer ces modifications dans le dépôt GitHub. Maintenant, allons sur GitHub et voyons comment les choses se sont reflétées là-bas. Je suis actuellement dans la succursale principale. Permettez-moi de recharger la page et de passer à la validation. Et comme vous pouvez le voir, nous sommes en mesure de voir l'engagement qui vient d'être pris par M. Luke. Mais si vous remarquez ce qui est montré ici, cela dit que cet engagement a été pris par M. Sunda et cela indique le profil de Cinder. Il est intéressant de noter que certains n'ont aucune idée que ce commentaire a été fait. Pour quelqu'un qui regarde l'historique des commits. Ils vont penser que ce comité est en fait fait fait par sunder toute la journée, n' est-ce pas lui qui a réellement fait ce commentaire. Cela se produit parce que Good suppose que ce qu'ils les utilisent ? Une adresse e-mail définie dans les configurations est la même personne qui effectue réellement le commit. Cependant, ce n'est peut-être pas le cas. Et je viens de vous le montrer. Cela ne doit pas nécessairement être fait par les collaborateurs existants du projet. Une personne au hasard pour le projet, et soulève la pull request avec un tas de commits imitant que ces commentaires ont été faits par un autre utilisateur, ce qui n'est évidemment pas ce à quoi nous nous attendions. Nous avons donc besoin d'une sorte de processus de vérification qui vérifie si l'auteur du commit est la même personne qui a réellement créé le comité. Et c'est là que les validations vérifiées entreront en ligne de compte. Et c'est de cela que nous allons parler ensuite. 116. 1602 Comprendre les signatures numériques: Avant de comprendre ce que notre signe engage, essayons de comprendre ce qu' est exactement une nature déformée. Pas dans le contexte de Git et GitHub. Mais en général. Supposons que nous ayons Bob et Alice. Bob veut envoyer un fichier à Alice. S'il envoie le fichier tel quel à Alice, il peut arriver que quelqu'un interfère dans le réseau, manipule le fichier avant qu'il n'atteigne Alice. Et Alice n'a aucun moyen de vérifier si le fichier a été manipulé ou si Bob est bien l'expéditeur. gardant ça à l'esprit, Bob va faire quelque chose à ce sujet. Ce qu'il va faire, c'est qu'il va utiliser une sorte d' outil pour créer ce que l' on appelle une clé publique. Et une clé privée. clé privée, comme son nom l'indique, n' est pas censée être partagée avec qui que ce soit d'autre. Ce sera avec Bob. Et il va le conserver en toute sécurité quelque part dans son système de fichiers local. D'autre part, la clé publique peut être partagée avec n'importe qui d'autre. Toute personne souhaitant recevoir le message ou le fichier de Bob peut en fait avoir une copie de la clé publique. Dans ce cas, Bob partagera la clé publique avec Alice. Alice donne serait utile dans un moment. Cette fois, avant que Bob n' envoie le fichier à Alice, va utiliser sa clé privée pour signer numériquement le document. Mais quelle est la distance que cette nature ? Eh bien, la signature numérique est essentiellement un hachage des données cryptées, mais la clé privée du signataire. Nous avons déjà parlé du hash dans l'une des conférences précédentes. Pour résumer, valeur de hachage est une valeur numérique d' une longueur fixe qui identifie une donnée de manière unique. Ou dans ce cas ce fichier. Si vous utilisez les mêmes données ou le fichier comme entrée dans la fonction de hachage, il fera exactement la même valeur de hachage unique quel que soit le nombre de fois que vous le faites. Mais si vous modifiez légèrement les données ou le contenu du fichier, la fonction de hachage renverra une valeur de hachage complètement différente. Donc, essentiellement, la valeur de hachage identifie de manière unique une donnée ou un fichier donné. Quand je parle d'un fichier de données ou d'un message, ils ont tous la même signification. Bob envoyait alors le fichier à Alice via le réseau. Maintenant, Alice doit vérifier si le message a été manipulé hors de l' expéditeur est réellement bombardé. J'aimerais que tu fasses ça. Eh bien, elle va utiliser la clé publique de Bob pour déchiffrer la signature numérique afin d'en extraire la valeur de hachage. Quand je dis qu'elle va faire ça, ce n'est pas exactement elle qui fera ça. Elle va utiliser une sorte d'outil qui le fera. Elle utiliserait alors une sorte d'outil pour connaître la valeur de hachage du fichier envoyé également. Ces deux valeurs de hachage sont exactement les mêmes, alors nous pouvons être sûrs que les données n'ont pas été manipulées. Et si elle est incapable de déchiffrer la signature numérique, cela signifie que quelqu'un d'autre a envoyé le fichier en utilisant sa clé privée et non la clé privée de Bob. Si la signature numérique est signée avec la clé privée de quelqu'un d'autre, Alice ne sera pas en mesure de déchiffrer la nature discursive à l'aide de la clé publique de Bob. Ainsi, elle peut être sûre que le fichier n'a pas été manipulé et qu' il provient bien de Bob. Si vous avez compris cela, comprendre la signature vérifiée ne devrait pas être un gros problème. Nous parlerons ensuite des signatures vérifiées. 117. 1603 Comprendre les engagements signés: Parlons maintenant des validations vérifiées. Le concept de commentaires vérifiés n'est pas différent du concept de signature numérique dont nous avons parlé plus tôt, sauf à la place de Bob Dylan pour remplacer Alice. Nous allons avoir GitHub. Et à la place de ce fichier, nous allons avoir la virgule. Supposons que Luke veuille assigner un commit distal et le pousser vers le dépôt GitHub. Sur GitHub, nous voulons vérifier si ce commit provient bien de Mr. Loop. Donc dans un premier temps, Luke va générer des clés publiques et privées, va télécharger sa clé publique sur son compte GitHub. Et il va utiliser la clé privée pour signer les commentaires. Encore une fois, ce n'est pas exactement Luke qui ferait tout ça. Tout serait pris en charge par get, en exécutant simplement une simple commande. Lorsqu'il exécute cette commande, git va essentiellement assigner le commit distal. Et une fois après, la boucle pousse le commit GitHub sur le site GitHub. Github vérifiera s'il provient de Luke en utilisant sa clé publique. Examinons en détail les étapes impliquées dans l'ensemble de ce processus. Donc, initialement une clé locale, de genre, publique et privée utilisant un outil, il téléchargerait ensuite la clé publique sur son compte GitHub afin que GitHub puisse l'utiliser pour vérifier les commits. Local distal assigne le commit à l'aide de sa clé privée. En exécutant simplement une commande. Luke transmettra ensuite les modifications à GitHub. Github vérifiera le commit en utilisant la clé publique de Luke. Si GitHub ne peut pas déchiffrer les Comanches et qu'il regarde la clé publique. Cela signifie que le comédien vient de M. Luke. Quelqu'un d'autre a peut-être fait en sorte que le commit ne soit pas sa clé privée. Nous allons voir toute cette inaction par la suite. 118. 1604 Créer des clés publiques et privées à l'aide de GPG: Voyons comment créer des clés publiques et privées. Supposons maintenant qu'il s'agit de l'ordinateur de M. Luke, et qu'il prévoit maintenant de créer des clés publiques et privées pour lui-même afin qu'elles puissent être utilisées ultérieurement pour la vérification. Pour créer ces clés, nous allons utiliser un outil appelé GPG, signifie GNU Privacy Guard. Et c'est quelque chose que vous n' avez pas à installer séparément. Si vous avez déjà installé Git sur votre ordinateur et que vous êtes déjà livré avec l'outil GPG. Et vous n'avez pas besoin de l'installer séparément. Si vous n'utilisez pas Git Bash, vous devriez être en mesure de trouver des instructions sur la façon d' installer GPG pour votre système d' exploitation avec une recherche rapide sur Google vous devriez être en mesure de trouver des instructions sur la façon . Cependant, dans ce cas, nous allons utiliser Git Bash pour la même chose. Et assurez-vous également de ne pas exécuter ces commandes dans le dossier du référentiel. Pour cela, j'ai créé un nouveau dossier sur mon bureau et c' est là que je vais exécuter les commandes. Alors tout d'abord, assurons-nous que GPG est bien installé en exécutant la commande GPG dash dash version. Et cela devrait afficher une sortie comme celle-ci. Exécutons maintenant la commande pour créer les clés publiques et privées de M. Luke. La commande pour cela est GPG, Dash, Dash , Dash, Generate Key. Cela va nous poser quelques questions. Voyons ce que nous pouvons y répondre. Ici, nous devons choisir l'algorithme que nous voulons utiliser pour générer les clés. Gpt prend en charge tous ces algorithmes répertoriés ici. L'algorithme par défaut est l'algorithme RSA, et c'est l'algorithme que je recommande d'utiliser. Je vais donc simplement appuyer sur Entrée pour choisir l'option par défaut, qui dans ce cas est l'algorithme RSA. Ensuite, on nous a demandé de saisir la taille de la clé. La taille de clé maximale que nous pouvons entrer est de 4 096 bits. Et c'est la configuration minimale requise pour GitHub. Nous allons donc dire 4 096. Appuyez sur Entrée. Ici, il nous demande de saisir la durée de validité du dossier. Je veux qu'il soit valable pour toujours. Je vais laisser l'option par défaut, qui est 0. Donc k n'expirerait jamais. Et nous devrions pouvoir utiliser ces clés pour toujours jusqu'à ce que nous les supprimions ou que nous en fassions quelque chose. Appuyons sur Entrée pour utiliser l'option par défaut. Maintenant, il nous demande de nous conformer si nous avons vraiment l'intention de ne pas expirer la clé du tout, je taperais y, disons simplement oui, appuyez sur Entrée. Il nous demande maintenant de saisir le nom d'utilisateur. Ici. Je vais fournir le nom d'utilisateur du compte GitHub de M. Luke. Je l'ai déjà sous la main. Je vais simplement le copier-coller ici. Et bien sûr, dans votre cas, vous devez saisir votre nom d'utilisateur GitHub. Dans la prochaine invite, je vais fournir l' adresse e-mail de Luke. Dans votre cas, vous souhaitez fournir l' adresse e-mail que vous avez utilisée pour vous inscrire à GitHub. Quels sont donc essentiellement le nom et l'adresse e-mail que vous souhaitez utiliser pour effectuer vos validations ? Il devrait les fournir ici. Nous pouvons également fournir un commentaire, mais je n'aime pas fournir quoi que ce soit. Je viens donc d'appuyer sur Entrée. Il nous demande maintenant de vérifier le nom d'utilisateur que nous venons de saisir. Vérifiez donc à nouveau et assurez-vous qu'il est correct. Une fois votre chemise retirée, entrez simplement le caractère o pour dire L K. Les clés sont générées. Il se peut que vous receviez une invite vous demandant de saisir la phrase de passe. Il s'agit simplement d'une sécurité supplémentaire pour protéger votre clé privée. Si quelqu'un venait à voler votre clé privée, il devrait être en mesure de connaître cette phrase secrète pour pouvoir utiliser votre clé privée. Il s'agit simplement d'une mesure de sécurité supplémentaire. Vous pouvez simplement appuyer sur OK sans rien saisir. Ainsi, vous n' avez aucune phrase secrète. Cependant, il est évidemment recommandé de fournir une phrase secrète. Dans mon cas, j' entre simplement pour le cactus, ce qui n'est pas si sûr. Si vous voulez qu'il soit plus sécurisé, donnez une phrase de passe très forte avec combinaison de caractères, de chiffres, de symboles, etc. Et je suppose que ce ne sera quatre caractères. Ça va ? Vous recevez un autre message vous avertissant que le mot de passe n' est pas très sécurisé, car il est très facile à deviner. Mais j'aimerais quand même utiliser celui-ci. J'ai donc choisi cette option qui dit de prendre celui-ci quand même. Il me demande de saisir à nouveau la phrase de passe. que je vais faire et cliquer sur OK. Maintenant, pendant que la touche est générée, il est recommandé d'effectuer certaines activités sur votre ordinateur, comme déplacer la souris, saisir quelque chose sur le clavier, etc. Et c'est ce qui est recommandé ici. Cela dit, nous devons générer beaucoup d'octets aléatoires. C'est une bonne idée d'effectuer d' autres actions comme taper sur le clavier, déplacer la souris, utiliser ça, ceci, etc. Pour que la touche générée soit plus aléatoire. Les deux clés ont donc été générées. Vous pouvez vérifier s'ils ont été générés en exécutant la commande GPG avec l'option list case. Je vais donc dire GPG Dash, Dash, list, Dash Keys. Cela a donc montré la clé publique. Et si vous dites list dash, secret case, cela affichera les détails de la clé privée. Ce n'est pas le cas en l'espèce. Ce ne sont que des détails sur les clés. Cela vous sera utile dans un instant. Je te verrai ensuite. 119. Exportation de la clé publique et mise à jour de la clé GPG sur GitHub: Maintenant que nous avons créé des clés publiques et privées, essayons maintenant d'exporter la clé publique afin de pouvoir mettre sur le compte GitHub de Luke. Et la commande pour cela, c'est que vous allez configurer GPG. Hyphenate signifie armure. Cette option consiste à exporter la clé au ascii ou mode plutôt qu'au format binaire. Ensuite, nous allons dire tiret, tiret, exporter pour exporter la clé. Ensuite, nous allons spécifier l'ID de clé. Maintenant, quel est l'ID de clé de nos précédentes commandes ? Si vous remarquez, lorsque nous avons vérifié la création de la clé publique et de la clé privée, il a également imprimé l'ID de la clé. Et si vous remarquez, l'idée clé des clés publiques et privées est exactement la même. C'est parce que la clé privée n' a pas d'idées de clé distinctes telles que. Ainsi, GPG affiche simplement ID de la clé publique sur laquelle la clé privée est payée. Je vais simplement copier cet identifiant. Alternativement, vous pouvez également utiliser UID pour User ID, et nous pouvons également utiliser le même. Mais il est généralement recommandé d'utiliser l' ID de clé au lieu de l'UID. Pour faire court, cela peut provoquer des conflits si vous avez un KeyStore. Utilisons cela pour exporter la clé publique. Nous pouvons copier le texte du bloc de clé publique begin PGP. Jusqu'à ce point où nous voyons le texte et le bloc de clé publique PGP. Je vais simplement le copier. Vous pouvez également exécuter la même commande. Et en utilisant l'accolade angulaire, nous pouvons réellement exporter la clé publique dans leur fichier. Clé de point publique, par exemple, où le public que vous souhaitez exporter. Si vous le souhaitez, vous pouvez également exporter la clé privée. Pour le moment. Nous n'avons pas à faire ça. Mais je montre simplement comment nous pouvons y parvenir. Donc, au lieu de dire simplement exporter, nous allons dire exporter la clé secrète Dash. Et cela exporterait également la clé privée. Et lorsque vous faites cela, vous recevrez une invite vous demandant de saisir la phrase de passe. Dans mon cas, c'est juste pour la phrase secrète des caractères. Quelle est la phrase secrète que vous avez créée ? C'était prévu ici. Une fois que j'ai cliqué sur OK, la clé privée est sauvegardée dans ce fichier. Voyons donc si nous pouvons y aller. Si j'ouvre ce répertoire, vous allez voir ces deux fichiers créés. Ouvrons le fichier de clé de point public avec Notepad Plus, Plus. Et vous allez voir le même texte que celui que vous avez vu sur Git Bash. Je vais simplement copier ceci. Et je vais maintenant accéder au compte GitHub de Luke. Il s'agit d'un compte GitHub. Je vais cliquer sur cette icône. Et si vous faites défiler un peu vers le bas, vous verrez Settings (Paramètres). Cliquez dessus. Et dans le menu de gauche, cliquez sur, cliquez sur les clés SSH et GPG. Et ici, vous voyez l'option. Pour donner une nouvelle clé GPG. Dans la section clé, vous allez coller le mortier qui vient de copier la clé publique, titre Ignacio optionnel, et de cliquer sur Ajouter une clé GPG. Ensuite, nous allons voir comment signer les commits. Je te verrai ensuite. 120. 1606 Mettre en place une configuration globale vérifiant les engagements signés sur GitHub: Voyons comment nous pouvons créer un commit assigné et le faire vérifier sur GitHub. J'ai déjà l'esprit public CAP cloné ici. Laissez-moi les ouvrir, obtenir bash sur le répertoire racine du projet. Permettez-moi d'abord de lancer la commande git config list. Et comme vous pouvez le voir, ils utilisent le nom et email sont mis à jour à celui de Cinders, ce qui n'est pas idéal. Voyons ce qui va se passer une fois que nous aurons assigné à commit. Permettez-moi donc de créer un fichier aléatoire, quelque chose de ce genre. Laissez-moi le mettre en scène. Et au fait, je ne fais pas ça sur la branche principale. Je viens de choisir une branche quelque peu aléatoire. Dans ce cas, le nom de la branche est QQQ, qui sera créé aléatoirement lors d'une de nos précédentes conférences. Permettez-moi de ne pas essayer de m' assigner à commit. La commande pour cela est git commit. Tiret en majuscules, oui. Assurez-vous qu'il s' agit bien d'une majuscule. Oui. Sinon, celui-ci marche. Si vous voulez signer la balise, elle doit être en minuscules. Oui. Donc tiret majuscule oui. Et tiret md pour envoyer un message à ce commit. Appelons ça mon commit ou peu importe. validation a donc échoué. Et le message dit qu' il n'y a pas de clé secrète. Pour M. Sunda. L'ID utilisateur de la clé que nous avons créée est celui de Luke. Mais les bons conflits ont souvent des références. Les deux ne correspondaient pas à Enter. Nous ne sommes pas en mesure de faire signe de validation dans ce cas. Allons donc rapidement de l'avant et changeons les configurations. Le nom d'utilisateur sera GitHub, nom d'utilisateur de Luke. De même, nous allons mettre à jour les mélodrames avec ceux de looks like so. Essayons maintenant de faire un commit assigné. est la première fois que tu le fais. Il vous sera demandé de saisir la phrase de passe. C'est exactement ce que je vais entrer. Frapper. OK ? Et notre engagement à réussir. Essayons maintenant d'appliquer ces modifications à GitHub. Nous sommes donc en mesure de pousser ce commit qui a été envoyé sur GitHub et de voir ce qui s'est reflété là-bas. Je suis donc actuellement dans mon référentiel public d'applications et je suis dans cette branche, QQQ. Permettez-moi de recharger la page. Et comme vous pouvez le constater, nous sommes en mesure de voir le commentaire qui vient d'être fait. Et cette fois, c'est avec un badge vérifié. Github est donc capable de récupérer la clé publique de M. Luke, l'auteur de The commit, pour vérifier si le comité est bien fait par M. Luke. C'est ainsi que se déroule le processus de vérification. Si je retirais la clé publique de M. Luke, le badge vérifié n'y serait plus. Vous pourriez dire « Lève-toi » en disant que la vérification a échoué. Et d'ailleurs, si vous ne voulez pas faire tiret S chaque fois que vous voulez signer un commit, nous pouvons en fait introduire un bon conflit pour cela. Vous allez donc dire git config global climate point JPG sign. Et nous allons faire en sorte que cela soit vrai. Ainsi, chaque fois que vous souhaitez valider la signature, vous n'avez pas à fournir explicitement l'option tiret S. Si vous définissez ce drapeau. De plus, si vous avez plusieurs clés privées, pour éviter toute ambiguïté, vous devez également leur indiquer quelle clé privée K12 utilise pour signer les commits. Le conflit pour cela est la clé de signature de l'utilisateur. Et vous allez fournir l'identifiant unique de la clé, GPG. Clés. Vous pouvez fournir cet identifiant. Comme ça. Disons qu'il y a une personne qui a des intentions négatives. Il a créé une clé privée en utilisant les informations d'identification de Luke et suppose qu'il a même poussé la validation vers le référentiel sur le site GitHub. Github ne sera pas en mesure de vérifier ce commit à l'aide de la clé publique du compte de Luke. Et de cette façon, levez-vous serait en mesure vérifier que le comité ne vient pas réellement de M. Luke. J'espère que c'est logique. Je te verrai ensuite. 121. 1607 Engages signés Signer des engagements à partir du code VS: D'accord, ne parlons pas de cette règle de prédiction de branche que nous avions omise tout à l'heure. Il dit que les validations signées sont requises. Vous devriez déjà être en mesure de comprendre cela. Si vous activez cette option, signifie que nous voulons uniquement autoriser les comètes de signe dans les branches correspondantes. Aussi simple que cela puisse être dit, cette vidéo va être très tournée. Permettez-moi également d'ajouter une dernière chose. Voyons comment nous pouvons avoir signé des commits à partir de Visual Studio Code. Pour cela, laissez-moi ouvrir ce projet en utilisant Visual Studio Code. Donc, le paramètre pour cela est que vous devez aller dans le menu Fichier, Préférences, Paramètres et rechercher. Laissez-moi le refaire. Paramètres et recherche de GPG. Vous devez activer cette option qui indique Activer la signature des validations. Fermez les paramètres. Faisons rapidement une modification dans l'un des fichiers afin de pouvoir valider quelque chose. On m'a mis du texte au hasard, sauvegardez le fichier. Et laissez-moi valider les modifications. Signez à partir du code VS, quelque chose de ce genre. Et laissez-moi m'engager. Vous serez peut-être invité à saisir la phrase de passe. Saisissez-le et cliquez sur. OK. Comme je l'ai déjà fait auparavant, je n'ai pas reçu cette invite une fois de plus. Mais si vous allez sur GitHub maintenant et que vous rechargez la page, bien sûr, nous devons pousser ces modifications pour pouvoir les voir sur GitHub. Alors faisons-le rapidement. Rechargeons la page. Et comme vous pouvez le voir, nous sommes en mesure de voir ce commit et il est également vérifié. J'espère que c'est logique. Je te verrai ensuite.