Apprendre Git et Github à partir de zéro 2026 [Méthode facile]

1. Introduction à la masterclass Git: Bienvenue dans le cours d'informatique ultime. Dans ce cours, nous allons apprendre à partir de zéro avec des concepts plus avancés. Nous commençons par qu'est-ce que c'est ? Pourquoi toutes les entreprises l'adorent, comment fonctionne réellement Git, configurez Git dans notre système. Les bases de Git, comme la mise en scène des fichiers, le commit ou l'ignorance de certains fichiers. Ensuite, nous avons une section complète pour parcourir l'historique des validations. En cela, nous pouvons comparer deux validations, revenir à leur spécificité , ajouter des textes. Ensuite, nous avons une section consacrée aux branches et à la fusion, qui est le sujet le plus important du kit Nous verrons également tester les modifications, les différents types de fusion, la résolution de conflits tels que Pro, les types de réinitialisation, la technique de sélection des cerises. Ensuite, nous aurons une section sur le travail en équipe dans laquelle je vous montrerai pratiquement comment les membres de l'équipe travaillent ensemble en l'utilisant En cela, nous avons le clonage, le rembourrage, le pull, le push. Certaines fonctionnalités supplémentaires de github, telles que les versions, les problèmes, les jalons, contribuent également à un projet open source Ensuite, nous verrons comment organiser l'historique de notre projet pour qu'il soit plus professionnel, modifier les validations existantes, les diviser et les écraser bien plus encore Dans ce cours, nous allons donc apprendre Git dans les deux sens. Nous verrons d'abord l'approche de la ligne de commande, puis je vous montrerai comment nous pouvons faire de même en utilisant des outils GI tels que Gitub desktop, code Visa Studio et Git Gracon Mais comme vous le savez peut-être, les outils GI ont peu de fonctionnalités limitées. C'est pourquoi l'apprentissage commandes Git est très important pour nous. Si vous ne connaissez rien à Git, si les concepts de Git ne vous conviennent pas ou si vous souhaitez maîtriser Kit et Github, alors ce cours est fait pour vous Maintenant, vous pouvez vous demander : qui suis-je ? Je suis ingénieur logiciel et j'enseigne également la programmation dans un langage facile à expliquer à l'aide de ma chaîne YouTube, Dieu vous bénisse, et de mes cours en ligne. Dans ce cours, je vais également vous présenter quelques projets sur lesquels vous pourrez vous entraîner commandes du kit. Comme vous pouvez me suivre , car lorsque vous écrivez vous-même des commandes Git et que vous les expérimentez, vous comprendrez correctement les commandes du kit. commettant une erreur, apprenez de vos erreurs et faites-le jusqu'à ce que vous maîtrisiez cette compétence Après avoir terminé ce cours, vous comprendrez bien comment fonctionne le kit et vous l'utiliserez en toute confiance, sans vous y perdre et en utilisant les meilleures techniques Je sais que vous avez hâte de l'apprendre, ainsi que Github, alors vous pouvez vous lancer et vous lancer dans ce cours 2. Qu'est-ce que Git & Github ?: Donc, avant de commencer à apprendre Git, voyons ce qu'est Git Git est le système de contrôle de version le plus populaire. Vous vous demandez peut-être ce que j'entends par système de contrôle de version. Le système de contrôle de version nous aide à enregistrer les différentes versions de notre projet. Permettez-moi de vous expliquer à l'aide d'un exemple concret. Imaginez que vous travaillez sur une application de commerce électronique. Maintenant, après un certain temps, vous avez vraiment foiré votre code et vous ne pouvez pas identifier les erreurs ni les résoudre. Tu décides de repartir de zéro. Maintenant, quelle est la solution pour que cette situation ne se reproduise plus ? Une solution consiste à dupliquer votre projet et à lui donner un nom comme la version 1.0. Et stockez-le quelque part en tant que sauvegarde. Donc, si à l'avenir, vous vous trompez à nouveau, vous pouvez revenir à ce code de la version 1.0 Désormais, à mesure que vous introduisez de nouvelles fonctionnalités, vous continuez à effectuer des sauvegardes et créer des versions de votre application. Mais la sauvegarde manuelle entraîne de nombreux problèmes, tels que des problèmes de stockage. De plus, cela crée beaucoup de confusion, comme dans la version 1.0, fonctionnalités que nous avons ajoutées ou supprimées. Par ailleurs, imaginez qu' un autre membre de l'équipe travaille sur le même projet, que vous deviez faire en sorte que vous ne puissiez pas suivre vos sauvegardes et les modifications apportées à ces projets. Cela crée beaucoup de confusion et de stress pour l'équipe. À ce moment-là, il apparaît sur la photo. Le kit nous aide à stocker les différentes versions de nos projets de manière très systématique et sans nécessiter de stockage supplémentaire. Supposons que vous travailliez sur un fichier SML à points d'index, vous souhaitiez sauvegarder son code actuel Vous dites à Git d'enregistrer ce code de fichier dans l'historique. G Prenez un instantané de votre code et stockez-le simplement dans son espace de stockage. Maintenant, au fur et à mesure que votre application grandit, vous prenez plusieurs captures d'écran et vous les stockez dans le stockage Git. Lorsque vous souhaitez voir une version particulière, Git vous montre l'historique de votre projet et vous pouvez facilement restaurer ce code. Maintenant, vous pouvez dire que nous savons que Git suit l'historique de nos projets C'est pourquoi nous n'avons pas à nous soucier des sauvegardes manuelles, mais de la manière dont il résout les problèmes en équipe. C'est un autre problème. Permettez-moi de vous expliquer cela rapidement. Ici, vous et les membres de votre équipe travaillez individuellement sur le même projet, et vous utilisez tous les deux le kit pour suivre l'historique de votre projet. Maintenant, lorsque vous avez terminé votre seule tâche, vous pouvez prendre un instantané de votre code dans Kit et télécharger ce projet sur le service Cloud, ce qui nous permet de télécharger les projets du kit. À présent, le membre de votre équipe obtient votre projet ou dossier Git depuis ce service Cloud et commence à travailler dessus. Une fois qu'il a terminé avec le blog, il peut prendre un instantané et mettre à jour les modifications sur le service Cloud Et pouvez-vous deviner quel service Cloud est le plus utilisé par les développeurs ? C'est vrai, c'est Github. Git et Github sont différents. Git est un système de contrôle de version, Github est utilisé pour héberger des projets Git sur le cloud et Github fournit également plus En utilisant Git et GitHub, nous pouvons facilement travailler en équipe sans nous renvoyer de courrier électronique à l' avance. Ne t'inquiète pas. Nous le comprendrons très profondément dans la prochaine section. En fait, nous avons une section entière où je vous montre pratiquement comment les développeurs travaillent les uns avec les autres. Pour couronner le tout, il s'agit du système de contrôle de version le plus populaire. Avec Git, nous pouvons suivre l'historique de nos projets de manière très efficace. Nous n'avons donc pas à nous soucier de sauvegarde et de la restauration manuelles. Git nous permet également de savoir quand des modifications particulières sont effectuées avec la date et l'heure et également qui a effectué ces modifications. De plus, Git facilite la collaboration avec les membres de l'équipe et présente de nombreux autres avantages que nous verrons dans ce cours. C'est pourquoi presque toutes les entreprises veulent des développeurs qui connaissent très bien Git, et c'est pourquoi chaque développeur doit apprendre Git et Github Dans ce cours, nous allons apprendre Git de manière très approfondie. Je suis très enthousiaste à ce sujet et j'espère que vous l'êtes aussi. Rendez-vous dans la prochaine leçon. 3. Différentes façons d'utiliser Git: Maintenant, laissez-moi vous montrer les différentes manières d'utiliser Git en tant que développeur. La première méthode consiste donc à l'utiliser en ligne de commande, ce qui signifie que vous ouvrez votre terminal et que vous commencez à écrire des commandes pour accéder à Git. C'est l'un des moyens les plus simples et faciles d'utiliser Gate, et de nombreux développeurs préfèrent la ligne de commande. Maintenant, si vous n'aimez pas utiliser l'approche par ligne de commande, vous pouvez utiliser nos éditeurs de code pour accéder à la porte. Par exemple, dans le code VS, nous obtenons par défaut le panneau de contrôle des sources. À l'aide de ce panneau, nous pouvons effectuer les opérations de base de git. Maintenant, vous vous demandez peut-être : pourquoi ne voulons-nous pas utiliser davantage de fonctionnalités de git ? Ne t'inquiète pas pour ça. Nous avons une extension de code VS appelée Gitans, qui est l'extension Git la plus populaire et la plus utilisée Vous pouvez constater que cette extension est téléchargée par près de 30 millions d'utilisateurs. Vous pouvez également utiliser cette extension. Maintenant, une autre façon de l'utiliser consiste à utiliser une interface utilisateur graphique ou une interface graphique. GI signifie que nous pouvons utiliser une application spécialement conçue pour utiliser Git. De nos jours, l'application Git la plus utilisée et la plus simple est Github desktop L'application de bureau Gitub a rendu le kit si simple pour les débutants de Gate , mais sa structure est super simple et facile à comprendre, mais elle ne possède pas toutes ses fonctionnalités Si vous souhaitez utiliser un autre outil GI, qui possède plus de fonctionnalités que Github desktop, vous pouvez utiliser Gate gracon C'est également un outil populaire pour Git, mais son interface utilisateur est un peu plus complexe que l'application de bureau Github Mais à la fin de ce cours, vous aimerez certainement Gate gracon Je vous expliquerai pourquoi dans les prochaines sections. Maintenant, vous vous demandez peut-être quelle est la meilleure façon de l'utiliser ? Et la réponse est l'approche par ligne de commande, et 70 % des développeurs aiment utiliser l'approche par ligne de commande. La première raison est que tous les outils GI, qu'il s'agisse de Github desktop ou de Kraken, soumis à certaines limitations, ce qui signifie que pour certaines tâches, vous devez absolument utiliser la ligne de commande En utilisant la ligne de commande, vous pouvez effectuer toutes les tâches liées à Git. Une autre raison est que les outils informatiques ne sont pas toujours à votre disposition. Par exemple, il arrive que le serveur n' autorise pas l'utilisation des outils d'interface graphique pour Git pour une raison quelconque. À ce moment-là, si vous ne connaissez pas les commandes Git, vous serez coincé dans cette situation. La plupart du temps, de nombreux développeurs aiment utiliser à la fois les outils GI et la ligne de commande, et je suis également l'un d'entre eux. C'est ce que je vais vous apprendre dans ce cours. Nous apprendrons d'abord l'approche par ligne de commande, puis nous verrons également ces concepts à l'aide d'outils d'interface graphique. Vous apprendrez les deux méthodes et vous devrez ensuite choisir le bon outil pour la tâche que vous effectuez. Permettez-moi de vous raconter un incident dans mon entreprise où j'ai travaillé en tant qu'ingénieur logiciel. Il y avait un gars qui effectuait toutes les tâches du kit en utilisant la ligne de commande, même les tâches complexes. Il trouve qu'il a l'air cool d' utiliser la ligne de commande pour chaque tâche. Mais nous savons tous que nous pouvons effectuer cette tâche beaucoup plus facilement à l'aide des outils informatiques. Alors ne deviens pas comme ce type. Tu dois penser intelligemment. De cette façon, je peux terminer cette tâche plus rapidement et sans me tromper. Nous passerons le plus clair de notre temps à utiliser la ligne de commande car elle est plus rapide. Mais si je pense que l'utilisation de l' outil I est plus bénéfique, alors je vais vous montrer la méthode de l'outil GI. De plus, de nombreux développeurs débutants ont très peur d' utiliser la ligne de commande, ou je peux dire de se souvenir des commandes de marche, mais ne vous inquiétez pas, je vais tout vous apprendre étape par étape et de manière plus simple que vous ne le pensez Vous aurez la confiance nécessaire pour utiliser Git comme un professionnel. Dans la leçon suivante, nous verrons comment installer Git dans notre système. 4. Configurer Git dans notre système: Installons donc Git dans notre système. Mais avant cela, vérifions si Git est déjà disponible dans notre système ou non. Et pour cela, nous utilisons un terminal. Donc, si vous êtes un utilisateur de Windows, appuyez sur la touche Windows et tapez CMD. Et si vous êtes Mcuser, appuyez sur Commande plus espace et tapez terminal J'utilise Windows, voici donc à quoi ressemble mon terminal ou mon CMD Il se peut que votre terminal ait une apparence différente. Ça n'a pas d'importance. Donc, tout d'abord, nous tapons ici la version git pour savoir quelle personne Git est installée sur notre système. Vous voyez ici que Git n'est pas reconnu comme une commande interne ou externe. Si vous recevez le même message, qu' il n'est pas installé sur votre système, et si vous obtenez une version, vous devez vous assurer que cette version n'est pas trop ancienne, par exemple deux ou plus ancienne que deux. Assurez-vous de mettre à jour votre gaiterson avec cela, vous pouvez facilement suivre . Pour installer ou mettre à jour Git, nous ouvrons notre navigateur et recherchons ici Git download Ouvrez ce site Web de publication. Sympa. La dernière version de Git est donc 2.44 0.0. Si vous regardez ce cours à l'avenir, il se peut que vous obteniez une version différente, mais ne vous inquiétez pas, vous pouvez toujours suivre ce cours. Croyez-moi, vous n' avez aucune erreur. À partir de là, vous pouvez voir votre système d'exploitation, ou nous pouvons simplement cliquer sur ce bouton. Cliquez ici pour le télécharger et le voir commencer à télécharger g. Lovely. Maintenant, ouvrons cette configuration. Tout d'abord, il demandera une autorisation. Alors autorisez-le, cliquez sur Suivant. Ici, vous pouvez sélectionner le chemin d'installation, alors cliquez sur Suivant, Suivant, et à partir de là, nous pouvons sélectionner notre éditeur de code par défaut. Je vais utiliser le code Visual Studio ou VSCode car près de 90 % des développeurs utilisent VSCode et cliquent sur Suivant Ensuite, puis cliquez sur Suivant. Ensuite, cliquez sur Suivant. Cliquez sur Suivant jusqu'à ce que vous obteniez Installer et que l'installation démarre. Terminé et cliquez sur Terminer. Ouvrez maintenant le menu Démarrer et recherchez Git Bash, qui est l'interface de ligne de commande pour fournir l' interface du terminal pour le système Windows Pour le reste de ce cours, nous utiliserons la CLI de base Git pour écrire des commandes Git. Si vous êtes Mguser, vous devez utiliser votre terminal car sa base est uniquement pour Windows Ici, nous écrivons la version Git dash dash et C, ici nous obtenons notre version Git 2.42 0.0. Nous avons installé Git avec succès dans notre système. 5. Configurer les détails utilisateur pour git: Maintenant, pour commencer à utiliser Git, nous devons tout d'abord définir certains paramètres de configuration tels que le nom d'utilisateur, l' EID, l'éditeur de code par défaut, que nous avons déjà définis lors de l'installation de Git, nous avons déjà définis lors de l'installation ainsi que la configuration de fin de ligne Ne t'inquiète pas. Elles sont très simples. Nous pouvons maintenant définir ces paramètres de configuration à trois niveaux, niveau du système, qui s'applique à tous les utilisateurs de cet ordinateur. deuxième niveau est le niveau global, qui concerne tous les référentiels de l'utilisateur actuel, et le troisième niveau est le niveau local, qui concerne le référentiel actuel. N'aie pas peur, fais comme moi. Ouvrez le terminal ou ITBashf, nous l' écrivons dans la configuration pour le niveau global, et nous ajoutons le nom du point utilisateur Ici, nous ajoutons des codes doubles et je saisis ici mon nom. Permettez-moi de zoomer un peu en utilisant Control et plus, ou nous pouvons utiliser Control et le défilement de la souris. Bien. Maintenant, appuyez sur Entrée. Ici, nous utilisons des codes doubles car nous avons un espace dans notre valeur. Vous devez également écrire votre nom correct ici. Quel que soit le nom que vous écrivez ici, vous pouvez le voir dans l'historique du dépôt. Ajoutons maintenant le courrier électronique de la même manière. Appuyez sur la flèche vers le haut pour renvoyer la commande précédente, et ici, à la place du nom du point d'utilisateur, nous écrivons l'e-mail de l'utilisateur point. Et ici, nous n'avons pas de place dans notre valeur. Nous pouvons supprimer ces doubles codes et j'écris simplement ici mon email. Définissons maintenant notre éditeur de code par défaut. Comme je vous l'ai dit, dans ce cours, nous allons utiliser le code VS. Si vous n'avez pas de code VS, vous pouvez le télécharger sur code.visualstudio.com Revenons maintenant à notre Git Pash et nous écrivons Git config dash global co dot Editor Ici, nous ajoutons également du code double, qui est du code Visual Studio, attendez. Maintenant, vous vous demandez peut-être pourquoi nous ajoutons ici attendre ? Ce poids indiquera à notre terminal d'attendre que nous fermions la fenêtre du code VS. Ici, stockez tous nos paramètres de configuration dans le fichier texte et pour afficher ou modifier cette pile, nous écrivons config Global E. Appuyez sur Enter. Vous voyez, ici, nous obtenons le fichier de configuration via le code. À partir de là, nous pouvons modifier les valeurs configurées et si nous revenons à notre page Git nous pouvons voir qu'il attend que notre éditeur ferme le fichier. C'est parce que nous avons ajouté ici wait Fermons ce fichier de configuration Git et sortons de celui-ci. Maintenant, nous avons presque terminé nos paramètres de configuration. Nous devons juste faire une configuration pour les fins de ligne. C'est un paramètre très important que beaucoup de développeurs oublient. Ce paramètre est très utile lorsque vous travaillez sur plusieurs plateformes. Par exemple, vous utilisez Windows comme système d'exploitation et un autre de vos collègues utilise le système d'exploitation Mac. Lorsque vous ajoutez un fichier texte à Git pour Windows, ce fichier utilise R N, qui sont des caractères spéciaux utilisés dans TextFile pour gérer la mise en page et la structure des lignes du document Mais sous macOS ou Linux, fichiers texte n'utilisent que N. Donc, si nous ne gérons pas les propriétés de fin de ligne, nous rencontrons des problèmes étranges dans Git Maintenant, pour résoudre ce problème, nous avons un paramètre de configuration appelé AutoCRLF qui est Carriage Return et Line Feed Ainsi, dans notre exemple, si nous ajoutons notre code dans le dépôt Git, G supprime tous les retours de chariot et les remplace par le fil de ligne. Maintenant, lorsque nous voulons à nouveau obtenir le même code, Git met à jour à nouveau notre code avec Carriage Return et Line Feed à la fois. Ici, nous devons définir cette propriété CRLF sur Tru, ce qui convertit automatiquement ce code Désormais, lorsqu'un utilisateur Mac ou Windows ajoute le code dans le même référentiel, il n'est plus nécessaire de le mettre à jour car il figure déjà dans le flux de ligne Ici, pour Mac et Linux, les utilisateurs doivent définir cette propriété AutoCRLF sur l'entrée, qui est le type d'origine Ne t'inquiète pas pour ça. Vous n' avez pas besoin de comprendre cela si profondément. Faites comme moi et vous êtes prêt à partir car la configuration de la configuration est un processus unique. Dans notre Git Bach, nous écrivons Git config Global. Mettez AtoSRF sur True. Si vous êtes un utilisateur Mac ou Linux, alors ici à la place de True, vous devez ajouter une entrée et appuyer sur Entrée. Ici, notre configuration est terminée. Nous pouvons maintenant commencer à apprendre Git. 6. Comment rendre Git Bash attrayant: Actuellement, notre gdbash ressemble à ceci. Donnons à notre Gitbash un look cool. C'est amusant. Si vous utilisez un simple terminal sous Windows, où je suggère d'ouvrir gtbash, cliquez avec le bouton droit sur Gitbsh et ici en bas, nous avons des options Ici, nous pouvons sélectionner les couleurs ou le thème. Ici, nous avons de nombreux thèmes. Ce sont donc des thèmes très décents. Personnellement, j'aime bien le thème de Dracula. Tu vois, ça a l'air sympa. Après cela, nous pouvons changer la transparence et le curseur et nous pouvons sélectionner le curseur clignotant Passons maintenant au texto. Ici, nous pouvons sélectionner les polices. Vous pouvez essayer de modifier ces polices. Je suis content de la police actuelle, donc je peux la vendre. De plus, je lisse les polices jusqu'à ce qu'elles soient complètes applique et j'enregistre les paramètres et je vois notre Git Pash ressembler à ceci Si vous souhaitez essayer un autre thème ou d'autres polices, vous pouvez également le faire. Je suis content des réglages. Commençons maintenant à apprendre Git. 7. Section 02 Bases de Git: Bienvenue dans la deuxième section du cours Ultimate Kit. Dans cette section, nous allons apprendre concepts fondamentaux du kit, que chaque utilisateur de kit devrait connaître. Nous commençons donc par comprendre le flux de travail du kit. Vous apprendrez comment fonctionne réellement Git, comment initialiser ses référentiels, enregistrer l'historique du code, effectuer la mise en scène, valider, qui sont des concepts vraiment importants car de nombreux développeurs ne savent pas comment cela fonctionne, et ils sont alors très confus Alors regardez cette section complète, même si vous connaissez les bases du kit, car beaucoup de développeurs comprennent vraiment mal ces concepts et restent coincés avec le kit Alors regardez chaque leçon de cette section. Plongeons-nous dans le vif du sujet. 8. Initialiser le projet Git: Donc, pour commencer à travailler avec Git, nous devons tout d'abord ajouter Git dans notre projet ou dossier. Si nous n'ajoutons pas Git à notre projet, comment Git devrait-il savoir quel dossier il doit suivre ? Je suis ici dans le dossier du projet et je crée un nouveau dossier, disons Task Track. C'est le premier nom de projet que j'ai créé dans mon cours Ultimate React JS. De plus, ne vous inquiétez pas à ce sujet. Nous n'allons pas créer de projet spécifique. Ici, notre objectif principal est de maîtriser Git. Nous devons maintenant ouvrir ce chemin de dossier dans notre terminal ou dans Git Bash. Si vous utilisez Windows, cliquez ici avec le bouton droit de la souris et vous aurez la possibilité d'ouvrir Git Bash ici voyez, nous ouvrons notre dossier dans le Git Bash, et si vous êtes Mcuser , cliquez avec le bouton droit sur votre dossier et vous aurez l'option d'ouvrir un nouveau terminal dans le Initialisons maintenant Git dans notre dossier. Ici, il suffit d'y écrire Git et d'appuyer sur Entrée. Vous voyez ici que nous recevons un message initialisé dans un dépôt Git vide avec le chemin de notre dossier Nous pouvons également voir ici que nous obtenons master, ce qui signifie simplement que notre dossier est prêt pour cela. Maintenant, si dans notre répertoire de suivi des tâches, répertoire signifie dossier, nous obtenons un autre répertoire appelé .it Si vous n'obtenez pas ce dossier ici, accédez à l'option d'affichage et cochez ici les fichiers cachés. Par défaut, ce répertoire est masqué car nous n'avons pas besoin de le toucher. Mais laissez-moi vous montrer ce qu' il y a dans ce dossier ? En gros, le dossier Git stocke des informations sur l'historique de notre projet. voyez, nous avons ici un tas de dossiers tels que des crochets, informations, des objets, des références et d'autres fichiers. Si vous l'utilisez, vous n'avez pas à vous soucier de tous ces fichiers. Ces fichiers sont des détails d'implémentation le concernant, manière dont il stocke les informations. Ne t'inquiète pas pour ça. Ce ne sont pas nos affaires. Notre objectif est d'utiliser Git et nous simplifier la vie. C'est pourquoi, par défaut, répertoire point Git est masqué. Si vous faites quelque chose dans ce répertoire ou si vous supprimez tout ce répertoire informatique, vous perdrez l'historique de votre projet. Dans mon entreprise, un de mes amis a supprimé ce dossier git de son projet , puis il a essayé d'utiliser toutes les commandes, mais elles ne fonctionnent pas car le dossier .it n'est pas disponible Laisse-moi te montrer ça. Ici, dans notre Git Bash, nous obtenons master entre parenthèses, ce qui signifie que Git suit ce dossier Maintenant, pour supprimer le répertoire Git, nous pouvons écrire RM pour supprimer R pour récursivement F pour force, et écrire point Git Appuyez sur Entrée. C, Git est supprimé de ce répertoire. C'est pourquoi le dossier .it est important. Réinitialisons maintenant Git dans notre projet et pour cela, quelle commande nous utilisons correctement, nous y utilisons Git Vous voyez, encore une fois, nous faisons de notre dossier un dépôt Git. dépôt Git signifie essentiellement que Git suit l'historique de ce projet. est aussi simple que ça. Dans la leçon suivante, nous allons comprendre en profondeur le fonctionnement de Git. 9. Comment fonctionne vraiment git ?: Nous initialisons donc ici notre dépôt Git. Voyons maintenant quelles sont les étapes quotidiennes assez courantes que les développeurs en font. Nous allons comprendre cela à l'aide d'un exemple concret. Imaginez que vous écrivez un livre de contes comme Harry Potter. Maintenant, vous ne voulez pas écrire directement quoi que ce soit dans votre livre de contes, vous travaillez ou vous écrivez dans un autre fichier Supposons maintenant que vous écriviez le premier chapitre, que vous vérifiiez d' abord s'il est correct ou non. Si ce n'est pas correct, vous modifiez ou mettez à jour ce fichier, et s'il est correct, alors seulement vous prendrez une capture d'écran de ce fichier et l'ajouterez dans votre livre de contes C'est également le flux de travail de Git. Laisse-moi t'expliquer. Ici, dans notre dépôt Git, qui est notre livre de contes par exemple Maintenant, nous ne voulons pas ajouter directement notre code car tout ce que nous ajoutons dans notre dépôt Git, git le stockera dans l'historique. Nous commençons à travailler localement, qui est notre dossier de suivi des tâches. Supposons maintenant que nous créions un fichier dans ce dossier et que nous devions l' enregistrer sous forme d'historique en tant que fichier d'écriture. À ce moment-là, n'oubliez pas que nous vérifions que tout va bien ou non avant de sauvegarder notre histoire. Ici, nous faisons de même. Nous vérifions, est-ce que ça va ou pas ? Voulons-nous ajouter ou supprimer quelque chose ? Cette zone de vérification est appelée zone intermédiaire. Vous vous demandez peut-être pourquoi nous avons besoin de cette zone de transit. Sans cette zone intermédiaire, quoi que nous fassions dans notre code local, tout le code sera stocké directement dans notre référentiel et nous n'aurons aucune chance de voir ce que nous modifierons ou supprimerons par rapport au code précédent. C'est pourquoi une zone de transit est nécessaire. Maintenant que nous avons ajouté notre code dans la zone de préparation, si nous sommes satisfaits, nous allons prendre capture d'écran de notre code et stocker dans notre dépôt Git. Maintenant, vous vous demandez peut-être comment pouvons-nous ajouter notre code local à la zone de transit ? Ou comment pouvons-nous ajouter notre code de zone de transit à l'historique de git ? La réponse est très simple en utilisant les commandes Git. Supposons que nous ajoutions ici un autre fichier appelé index point gs. Nous voulons ajouter ce fichier dans la zone de préparation. Ici, nous écrivons command, Git add, et ici nous écrivons notre index de nom de fichier point js. Ici, nous pouvons également ajouter plusieurs noms de fichiers. En utilisant cette commande, nous ajoutons notre code dans la zone de transit. Une chose que je tiens à préciser, c'est que la zone de transit n'est pas un dossier. La zone de transit n'est qu' une mémoire temporaire que Git nous fournit. De nombreux développeurs appellent « zone de staging » un index. Ici, nous vérifions que notre code est correct ou non. S'il n'est pas correct, nous pouvons le mettre à jour ou le corriger car nous ne voulons pas stocker le code contenant des erreurs dans l'historique. Maintenant, si nous sommes prêts à enregistrer ce fichier dans notre historique, nous prenons un instantané de la zone de transit et le stockons dans l'historique de Git. En utilisant Git GamTTH est l'abréviation Ici, nous écrivons notre message que nous voulons enregistrer avec cet instantané. À l'avenir, nous saurons ce que nous ajouterons à ce Kummet. Commit signifie enregistrer un instantané dans l'historique de Git. Par exemple, à l'avenir, si nous corrigeons des bogues ou ajoutons de nouvelles fonctionnalités, nous créerons un message de validation pour chaque Camt ajouté, qui indique clairement ce que nous avons fait dans ce kat Ainsi, nous pouvons facilement consulter l'historique de notre code. Assurez-vous que chaque fois que vous commettez quoi que ce soit, ajoutez un message significatif. Chaque validation que nous effectuons est enregistrée avec un identifiant, une date et une heure uniques , le nom de l'auteur, un e-mail et notre message de validation. À partir de ces informations, nous pouvons voir quelles modifications ont été effectuées par qui et quand. Supposons maintenant que nous ajoutions ici un autre fichier appelé data point TXT. Dites-moi ce que nous devons faire pour enregistrer ce nouveau fichier dans l'historique. C'est vrai. Tout d'abord, nous ajoutons notre code à la zone de mise en scène avec Git add data point TXT. Ensuite, nous pouvons prendre un instantané de cette zone de transit actuelle et le stocker dans le référentiel Git en utilisant Git Commit, ajoutant le point de données TxDFle dans le projet Ici, je tiens à préciser une chose : après avoir validé le code de la zone de transit vers le référentiel git, notre zone de transition ne deviendra pas vide. Cela restera le même que celui que nous nous engageons à respecter. Si, à l'avenir, nous ajoutons ou supprimons un élément dans notre code local, puis que nous l'ajoutons dans notre zone de transit, seules les mises à jour de fichiers que nous avons modifiées seront prises en compte. Pour récapituler rapidement le tri du code dans notre historique Git, nous ajoutons d' abord notre code la zone de transit, puis, si nous sommes satisfaits de notre code actuel, ce si nous sommes satisfaits de notre code actuel qu'alors que nous le validerons dans notre dépôt Git et le dépôt Git stockera toutes les commandes avec leurs détails est aussi simple que ça. Ne vous inquiétez pas si vous êtes confus ou si vous avez beaucoup de questions, vous obtiendrez toutes les réponses au fur et à mesure que nous avancerons dans ce cours, et je parie que vous maîtriserez Git comme P. Dans cette section, nous travaillerons pratiquement avec ce flux de travail Git. 10. Exercice : flux de travail Git: Dans la leçon précédente, vous avez appris le flux de travail de base. Maintenant, je veux que vous dessiniez la figure approximative ou le flux de travail approximatif de la démarche avec les deux commandes Terminez le petit exercice, mais la condition est que vous ne puissiez pas regarder la leçon précédente. Essayez de vous en souvenir , puis dessinez-le sur le papier ou n'importe où. Si vous dessinez sur du papier, vous pouvez prendre une photo et la télécharger dans la section Q&R Je vais essayer de vérifier et de répondre à votre demande. Après avoir terminé cet exercice, vous pouvez consulter la leçon précédente et vous assurer que votre flux de travail est correct ou non. C'est un petit jeu. Ne vous inquiétez pas de perdre ou de gagner. 11. Ajouter des fichiers à la zone de scène: Maintenant, laissez-moi vous montrer comment ajouter des fichiers dans la zone de couture. Mais avant tout, nous devons ajouter un fichier dans notre code local. J'ouvre le dossier Task track dans le code VS, et tout d'abord, ici, je crée un nouveau fichier appelé chapter one point TXT. Et ici nous écrivons Bonjour. Je crée ici un fichier XD, mais vous pouvez créer n'importe quel fichier. Enregistrez ce fichier. Nous voulons maintenant ajouter cette pile à la zone de transit. Dans notre base Git, permettez-moi de vérifier l'état actuel. Si vous souhaitez effacer les commandes précédentes, nous pouvons écrire ici clear. Cela effacera toutes nos commandes précédentes. Vérifions le statut avec le statut de Git. Vous voyez, nous arrivons à Branch, Master, pas encore de commits. Et nous obtenons un fichier non suivi, qui est le chapitre 1 point TXT Et il nous donne également des suggestions avec Command Git add, nom de fichier. Nous pouvons donc écrire ici, ajouter Git, et ici nous pouvons écrire le chapitre à un point TXT. Si nous voulons ajouter d'autres fichiers, nous pouvons les modifier ici avec un espace, chapitre à deux points TXT, etc. Nous pouvons également utiliser ici le point étoilé TXT, ce qui signifie ajouter tous les fichiers avec l'extension TXT. Nous pouvons également utiliser ici Git add period, ce qui signifie ajouter tous les fichiers. Habituellement, de nombreux développeurs utilisent cette méthode, nous pouvons donc utiliser n'importe laquelle de ces commandes. Ici, j'utilise Git add chapter one point TXT. Maintenant, nous ne voyons rien, mais comment vérifier que ce fichier est bien ajouté ou non dans la zone de transit ? Peux-tu me dire que nous l'utilisons simplement ? Nous pouvons utiliser Git status. Vous voyez ici que nous recevons les modifications de message à devenir et c'est tout. Nous ajoutons notre fichier dans la zone de mise en scène. Supposons maintenant que nous modifiions quelque chose dans notre fichier. Ici, j'ajoute le monde dans la deuxième ligne. Et enregistrez ce fichier. Maintenant, vérifions à nouveau le statut, alors obtenons-le et appuyez sur Entrée. Vous voyez maintenant ici que nous recevons un message de modification. Actuellement, dans notre zone de transit, nous avons notre code d'édition précédent, qui est le fichier du chapitre 1 avec uniquement un message de bonjour. Maintenant que nous modifions quelque chose dans notre code local, nous devons à nouveau ajouter ces modifications à notre zone de transit, car pour valider notre code dans l'historique de Git, nous devons transmettre notre code depuis la zone de transit. Ici, nous pouvons à nouveau écrire Git add Chapter one point TXT. Si nous vérifions à nouveau notre statut, nous ne recevrons aucune modification en attente. C'est ainsi que nous ajoutons notre code dans la zone de transit. De plus, je tiens à vous dire que si vous aimez créer des nœuds, vous pouvez commencer à créer vos nœuds pour les commandes de porte. J'ajouterai également mes nœuds, mais vous pouvez également utiliser vos propres nœuds. 12. Créons votre premier fichier: Actuellement, nos fichiers se trouvent dans la zone de transit. Inscrivons maintenant notre fichier dans l'historique informatique. Donc, dans Git Bash, nous l' écrivons commit. Ici, nous pouvons écrire pour le message, et en double code, nous ajoutons notre message de validation. Disons le Commit initial. Maintenant, nous écrivons ici une courte description de notre manteau. Mais parfois, nous voulons ajouter d'autres lignes de description. Par exemple, nous corrigeons le burg, puis nous pouvons ajouter dans la description quel était ce burg, mais nous ne pouvons pas l'expliquer en une seule ligne. Pour ajouter plusieurs lignes de description, nous tapons ici only get coat. Et appuyez sur Entrée. Cela ouvrira un éditeur de code par défaut que nous avons ajouté dans notre configuration. Tu t'en souviens ? Génial. Maintenant, dans la première ligne, nous devons saisir notre brève description et pour une description longue, nous devons l'écrire dans la nouvelle ligne. Pour ce commit, nous ajoutons un message court comme le commit initial pour une longue description, que nous pouvons écrire, terminer le premier chapitre. Apportez quelques modifications à l'histoire. J'écris juste un message aléatoire pour la démo. Ne t'inquiète pas Je ne vais pas créer de livre de contes ici. Maintenant, vous vous demandez peut-être : qu' en est-il de ces lignes ? Ces lignes sont communes pour expliquer cette partie de la description, ne vous inquiétez pas pour cela. Maintenant, sauvegardons ce fichier et fermons-le à partir d'ici. Maintenant, si nous revenons à notre tableau de bord, voyons ici que nous avons un fichier modifié et deux insertions. Félicitations. Nous avons effectué notre première omission avec succès Pour vérifier cela, nous pouvons écrire statistiques du kit et voir ici que nous n'avons rien à valider. L'arbre de travail est propre, ce qui signifie simplement que notre code de zone de travail , notre code de zone intermédiaire et l'instantané du référentiel Git sont tous identiques. C'est ainsi que nous validons notre code dans git. Vous pouvez voir que c'est très simple et facile. 13. Quand vous devez vous engager: Maintenant, de nombreux développeurs commettent une erreur en utilisant git. S'ils modifient quelque chose dans la zone de travail, ils l'indiquent immédiatement dans la zone de transit, ce qui est une bonne chose, mais ils valident également toutes ces petites modifications dans le dépôt git, ce qui est faux. De plus, certains développeurs apportent directement de gros changements au dépôt git, ce qui est également faux, car nous ne voulons pas coder pendant cinq jours , puis valider le code entier. Ce n'est pas le meilleur moyen. Vous vous demandez peut-être quelle est la meilleure pratique pour le manteau ? Tout d'abord, je tiens à vous dire de ne pas vous engager pour chaque changement. Cela ne sert à rien car, comme nous le savons, quels que soient nos engagements, ils seront conservés dans l'histoire. Si vous obtenez de petits changements, il Si vous obtenez de petits changements, alors très difficile de trouver ce que vous attendez de deviendra alors très difficile de trouver ce que vous attendez de l'histoire. La taille de la Camt ne doit pas être trop petite ou trop grande. Engagez-vous toujours lorsque vous pensez atteint un certain état que vous souhaitez enregistrer. Imaginez que valider du code est comme certains points de contrôle que vous souhaitez définir En cas de problème avec votre implémentation actuelle, vous pouvez revenir au point de contrôle précédent et redémarrer votre implémentation Vous souvenez-vous du concept de jeu vidéo pour les points de contrôle ? Au fur et à mesure que vous terminez quelque chose de difficile, vous obtenez le point de contrôle qui garantira votre jeu Pense comme ça. Une autre chose est que chaque commit doit représenter un ensemble de chaînes logiquement distinct Ne mélangez pas les choses. Par exemple, vous êtes en train de résoudre un bogue et vous avez également trouvé des améliorations de style, vous n'avez donc pas à valider les deux modifications en un seul commit. Vous pouvez effectuer deux validations distinctes, l'une pour corriger le bogue XYZ et l'autre pour améliorer le style des cartes Autre bonne pratique pour les comités : vous devez rédiger un message de validation significatif, vous devez rédiger un message de validation significatif car avec Commit message, vous trouverez votre point de contrôle dans l'historique Voici donc mes cassettes pour manteau. Mais au final, vous êtes le meilleur juge de votre situation. N'y pensez pas, vous ne ferez aucune erreur. commettrons tous des erreurs, mais nous pouvons en tirer des leçons, n'est-ce pas ? Essaie de te souvenir de ces cassettes. Cela vous aidera dans votre voyage d'entrée. 14. Exercice pour l'engagement: Il est maintenant temps de faire peu d'exercice pour contrôler ce que nous avons appris dans les leçons précédentes. Je veux que vous créiez un nouveau fichier appelé chapter two point TXT et que vous écriviez quelque chose dans ce fichier. Après avoir ajouté du texte, vous devez valider ce fichier dans le dépôt pour enfants. Je sais que c'est assez facile et que vous pouvez terminer cet exercice, vous lancer et voir la solution. J'espère donc que vous aurez terminé cet exercice ou que vous essayerez au moins de le résoudre. Voyons maintenant la solution. Je crée ici un nouveau fichier au chapitre à deux points TXT. Et ici, j'ajoute simplement que Learning Git est une expérience amusante. Si vous savez comment fonctionne Git, êtes-vous d' accord ? Fais-moi savoir. Enregistrez ce fichier, et nous revenons ici à notre Git Bash, d'abord, quel statut Vous voyez ici que nous obtenons un fichier non suivi qui est le TXT du chapitre deux points Nous devons d'abord mettre en place ces changements, puis nous pourrons les valider. Nous écrivons donc Git add Chapter two point TXT. Ici, si vous ne voulez pas écrire un nom de fichier complet, en écrivant le demi-nom, vous pouvez appuyer sur la touche Tab, et les noms de fichiers non suivis ou modifiés seront renvoyés C'est un petit truc. Ensuite, il suffit de valider Git, terminer le chapitre deux et d'appuyer sur Entrée. Voyez ici que nous faisons un autre commit, afin que vous puissiez voir à quel point il est simple et facile de valider du code. 15. Comment éviter la zone de préparation: Maintenant, la question courante que se posent de nombreux utilisateurs informatiques est pouvons-nous ignorer la zone de transit ? La réponse est oui. ne faut pas vraiment sauter la zone de transit, mais comme nous le savons , pour valider le code, nous devons utiliser ces deux commandes Mais dans la démarche, nous avons une autre commande, qui est la combinaison de ces deux commandes, mais ce n'est pas une bonne pratique Ne le faites que lorsque vous êtes sûr à 100 % de ne pas avoir besoin de revoir votre code car c'est le but de la zone de transit. Souvenez-vous de notre exemple de livre de contes, laissez-moi vous montrer comment nous pouvons ignorer la zone de mise en scène. Tout d'abord, permettez-moi modifier quelque chose dans le fichier du chapitre 1. Commençons le premier chapitre. Enregistrez les modifications et revenez à Git Bash. Vérifions le statut. Vous voyez, nous avons un fichier modifié. Maintenant, pour valider ces modifications, comme nous le savons, nous devons écrire deux commandes. Nous devons d'abord préparer le fichier, puis ajouter Commit. Mais ici, nous pouvons directement écrire Gate commit A, qui concerne toutes les modifications modifiées, puis le message. Ou nous pouvons simplement le faire ensemble avant le matin et ensuite, nous pouvons écrire notre message de validation, au début du premier chapitre. Et appuyez sur Entrée. Vérifiez qu'il est correctement envoyé à la porte. Vérifions-le avec git status. Tu vois, on n'a rien à engager. Cette commande ajoutera également toutes nos modifications dans la zone de mise en scène et validera également ce code dans le référentiel git. Mais comme je vous l'ai dit, n'utilisez cette commande que si vous êtes sûr à 100 %. 99 % du temps, nous créons d'abord notre code, puis nous le validons jusqu'à la porte. 16. Supprimer des fichiers des zones: Maintenant, supposons qu'à ce stade nous découvrions que nous n'avons pas besoin du chapitre deux, ou que nous voulions supprimer le fichier du chapitre deux. À partir du code VS, je supprime ce fichier. Bien. Maintenant, vérifions notre statut. Obtenez le statut. voyez, ici, nous pouvons voir que le fichier du chapitre 2 est supprimé parce que nous supprimons notre fichier du répertoire de travail, mais que ce fichier est toujours disponible dans la zone de transit. Laisse-moi te montrer. Nous écrivons donc ici des fichiers Gates. Cette commande renverra tous les fichiers disponibles dans la zone de transit. Vous voyez, nous avons le chapitre un et le chapitre deux. Maintenant, comme je vous l'ai dit, chaque fois que nous apportons des modifications, nous devons les ajouter dans la zone de préparation à l' aide de la commande d'ajout. Nous écrivons donc ici Gate, ajoutons le chapitre deux pour ajouter les modifications, ou nous pouvons dire suppression du fichier du chapitre deux. Nous allons maintenant vérifier une fois de plus les fichiers de la zone de transit. Obtenez des fichiers S. Ici, S signifie liste. Vous voyez, ici nous n'avons qu'un fichier du chapitre 1. Nous allons maintenant vérifier notre statut à l' aide de Git status. Tu vois, nous voilà prêts à nous engager. Nous pouvons écrire Git comet pour message, supprimer le chapitre deux. Et c'est fait. Nous avons supprimé avec succès notre fichier du chapitre deux de notre zone locale et de notre zone de transit. Quoi que nous fassions, qu'il s'agisse de créer un nouveau fichier ou de supprimer le fichier existant, nous devons d'abord ajouter ces modifications à la zone de transit, puis nous pouvons les valider. est aussi simple que ça. Maintenant, vous pourriez vous demander s'il existe un raccourci ou si vous supprimez notre fichier de la zone de travail et de la zone de transit et vous avez raison. Oui, il existe une commande qui effectue ces deux étapes en une seule étape. Nous pouvons écrire get RM RM means remove. Et ici, nous ajoutons le nom de notre fichier, disons le chapitre à deux points TXT. En outre, nous pouvons ajouter ici plusieurs noms de fichiers et nous pouvons également supprimer tous les fichiers par point étoilé TXT, ce qui signifie supprimer tous les fichiers avec l'extension TXT. En utilisant cette commande, nous pouvons supprimer notre fichier de la zone locale et de la zone de transit à la fois. 17. Comment ignorer les fichiers dans git [GitIgnore]: Maintenant, parfois dans notre projet, nous avons un dossier ou un fichier que nous venons de créer pour notre usage. Nous ne voulons pas le mettre dans le dépôt Git. Par exemple, si vous utilisez des packages de nœuds, vous obtenez un dossier de modules de nœuds contenant des milliers de fichiers Nous ne voulons donc pas l'ajouter dans notre référentiel Git. Cela augmentera la taille de notre dépôt sans aucune valeur. Un autre exemple est celui des fichiers temporaires ou des fichiers journaux qui ne sont pas nécessaires pour ajouter un dépôt git. Permettez-moi de vous raconter l' histoire de mon ami, mon ami et moi travaillant dans une entreprise. Mon amie Harley ne connaissait pas Gate. Il doit s'engager avec Git et Git. Un jour, il a enregistré son fichier de mots de passe personnel avec le code. Tous les membres de l'équipe viennent à son bureau pour lui communiquer son mot de passe, mais il ne sait pas comment tous les membres de l'équipe connaissent son mot de passe. À ce moment-là, nous devons ignorer ce fichier ou nous pouvons également ignorer l'ensemble du dossier. Laissez-moi vous le montrer de façon pratique. Ici, dans notre dossier de suivi des tâches, nous créons un nouveau dossier appelé journaux pour stocker les journaux de débogage ou d'application Ici, nous ajoutons un nouveau fichier appelé debug point log dans ce fichier, nous ajoutons du texte Ceci est le journal de débogage. Enregistrez les modifications. Ici, si vous y prêtez peu attention, lorsque nous créons un nouveau fichier dans notre dossier, notre fichier ou dossier est surligné par la couleur verte dans le coin droit du nom du fichier, nous obtenons l'icône U. Pouvez-vous deviner quelle est la signification de ce U ? Écrire ? U signifie fichier non suivi En gros, VSC nous indique que ce fichier n'est pas disponible dans la zone de transit. Ne t'inquiète pas pour ça. Je vous expliquerai tout cela dans les prochaines leçons. Revenons maintenant à notre Gitbsh ici, si nous faisons git status, alors nous obtenons des fichiers non suivis Si nous écrivons ici Git add, ce dossier de journal sera également ajouté à notre zone de transit, ce que nous ne voulons pas. Alors, comment pouvons-nous ignorer ces fichiers ? C'est très simple. Rien que dans notre projet, nous créons un nouveau fichier appelé point Git Ignore. Assurez-vous d'écrire le même nom de fichier ( point Git Ignore Ce fichier doit également se trouver dans le répertoire racine de notre projet. Dans n'importe quel autre dossier. Ce n'est qu'alors que cela fonctionnera. En gros, ce fichier Get ignore indique Git quels fichiers ou dossiers nous voulons ignorer. Ici, nous voulons ignorer le dossier des journaux complet. Nous écrivons des journaux en slash. Si nous voulons ignorer le dossier des modules de nœud, nous écrivons des modules de soulignement de nœud ou si nous voulons ignorer un fichier spécifique, nous pouvons également écrire des journaux, slash debug On peut tout faire ici. Maintenant, au moment où nous enregistrons ce fichier, nous pouvons voir que l'icône U a disparu de notre fichier journal. De plus, le nom de notre dossier et de notre fichier est en gris, ce qui signifie que vous devez ignorer tous les fichiers du dossier des journaux. Laissez-moi vous le montrer encore une fois. Je supprime ces lignes et je les enregistre. Vous voyez ici, nous obtenons U. Et si nous ajoutons à nouveau des logs, slash et les enregistrons, puis ignorons ces Vérifions-les avec leur statut et voyons, nous n'en aurons qu'un seul sur la bonne voie , Gino, que nous venons de créer Ajoutons-le avec Git add point gitignore, puis Git co ignore tous les fichiers journaux et appuie sur Entrée Charmant. C'est ainsi que nous pouvons ignorer les fichiers dans Git. Mais n'oubliez pas qu'en utilisant cette méthode, nous ne pouvons ignorer que ce fichier ou ce dossier, qui n'est pas déjà validé. En termes simples, si nous voulons ignorer notre fichier TXT du chapitre un point maintenant, nous ne pouvons pas simplement le faire avec le fichier Git Ignore car notre fichier du chapitre un est déjà validé dans le dépôt git. Nous devons donc d'abord supprimer notre fichier de la zone de transit, puis nous pouvons ignorer ce fichier. Laisse-moi te montrer comment on peut faire ça ? Ici, dans notre dossier de projet, je crée un nouveau dossier appelé, disons, Ben. Et dans ce dossier, nous créons un nouveau fichier appelé backup point Ben. Ne vous inquiétez pas pour ces noms de fichiers. C'est juste pour une démonstration. Ici, nous ajoutons du texte comme « bonjour ». Enregistrez ceci et vous verrez. Ici, nous obtenons une icône de fichier non suivi. Maintenant, permettez-moi de valider accidentellement ce fichier. Donc, dans notre Git Bash, j'écris Git add period, ce qui signifie tous les fichiers, puis Git commit en testant le fichier But Bin et nous le validons Maintenant, notre fichier est déjà validé. Essayons d'ignorer ce fichier. Permettez-moi de vous montrer quels fichiers se trouvent dans la zone de transit par git As files. Ici, nous pouvons voir que le fichier Bupt Bin est déjà là. Alors, comment pouvons-nous supprimer ce fichier de la zone de transit ? Dans la leçon précédente, nous avons vu Git RM à supprimer et nous avons ajouté le nom de notre fichier, disons, en tant que point de sauvegarde Ben Mais en utilisant cette commande, il supprime ce fichier de la zone de transit, mais également de la zone locale. Mais ici, nous voulons que ce fichier soit en local ou dans notre zone de travail. Donc, pour obtenir de l'aide, nous écrivons H pour obtenir de l'aide. Ici, nous pouvons voir que nous avons l'option dash dash cast, qui ne sera supprimée que de l'index. Index signifie zone de transit. Nous écrivons Git, RM, dacast et nous devons également ajouter ici R pour la suppression récursive car nous voulons supprimer tous les fichiers du répertoire bin Si nous n'écrivons pas ici R, nous obtenons une erreur. Et nous ajoutons le répertoire Bin et notre dossier Bin est supprimé de la zone de transit. Voyons également que notre zone de transit s'y accumule sous forme de fichiers. voyez, le fichier Bin est supprimé ici et vérifions notre statut. Ici, nous obtenons un fichier supprimé, mais nous obtenons également un fichier de suivi depuis Bin. Ici, nous devons ajouter le répertoire Ben dans notre fichier point Getting nor. Enregistrez ceci et voyez, ici nous lisons l'icône, ce qui signifie supprimée. Vérifions à nouveau le statut. voyez, ici, nous obtenons un fichier supprimé et nous ne l'obtenons aucun fichier modifié car nous avons ajouté le répertoire bin dans notre fichier GTI nor Validons ces modifications et validons, supprimons le répertoire bin qui a été accidentellement validé. Maintenant, permettez-moi de modifier quelque chose dans le fichier Bin. Enregistrez ceci et voyez que nous ne recevons aucun message de modification, mais le fichier gitignore reste Peux-tu me dire pourquoi ? Vérifions-le avec le statut ? voyez, ici, nous obtenons un fichier gitignore modifié parce que nous avons oublié d'ajouter notre GetI sans modification à Ne t'inquiète pas, ça m'arrive souvent. Ici, nous organisons simplement les modifications à l'aide de Git add period. Et puis Git commit en ignorant le répertoire win et c'est fait. Vous pouvez donc voir à quel point il est difficile d' ignorer les fichiers déjà validés. La meilleure pratique pour Git est donc ajouter le fichier Git Ignore dès le début. Rendez-vous donc sur github.com slash GitHub , slash Git Ignore Ici, nous obtenons tous les modèles pour le Getting no files. Par exemple, si vous travaillez avec l'application React, vous pouvez rechercher ici node. Et ici, nous obtenons un modèle pour toutes les applications qui utilisent le nœud. Copiez simplement ce modèle et collez-le dans votre fichier Gating Nerve. C'est aussi simple que ça. 18. Afficher les changements entre les zones: Maintenant, permettez-moi de vous poser une question. Comment pouvons-nous voir les modifications que nous apportons en l'utilisant ? Vous pourriez dire que nous pouvons utiliser la commande Git status, et vous avez raison. Mais cette commande ne renverra que le nom du fichier. Et si nous voulions voir ce que nous modifiions dans notre fichier ? Laisse-moi te montrer. Dans notre fichier du chapitre 1, je supprime ces trois lignes et j'ajoute ici c'est le début de notre histoire. Enregistrez ce fichier et nous arriverons ici pour le modifier. Maintenant, laissez-moi vous montrer comment vous pouvez utiliser une autre commande it, qui est intuitive pour différencier. voyez, cela semble très complexe de voir les échanges dans le terminal. Et si vous voyez cela pour la première fois, vous pouvez casser votre écran. Mais laissez-moi essayer de vous expliquer. Ici, nous pouvons le voir faire la différence entre un fichier du chapitre A et un fichier du chapitre un B, ce qui signifie qu'il compare le même fichier avec une version différente. Ensuite, nous avons un index et quelques métadonnées, ce qui n'a pas vraiment d'importance pour nous. Ensuite, nous obtenons ces deux lignes, les modifications dans le premier fichier indiquent le signe moins et les modifications dans le second fichier indiquent le signe plus. Ne t'inquiète pas pour ça. En gros, cela montre que nous supprimons ces trois lignes rouges et ajoutons cette ligne verte. C'est aussi simple que ça. Maintenant, comme je vous l'ai dit, il n'est pas très facile de suivre les changements dans le terminal. Laissez-moi vous expliquer comment utiliser notre éditeur de code pour suivre ces changements ? Tout d'abord, nous devons dire à Kat que nous voulons utiliser le code VS comme outil TIF. Les outils DIF sont des outils de différenciation. Nous écrivons Kit, configurons Dash Global. Nous le définissons comme global, nous n'avons donc pas à le configurer pour chaque projet. Après cela, ajoutez l'outil div point et nous l'avons défini sur le code VS. Avec cette commande, nous donnons simplement nom de notre outil DIV, qui est VSCode Ne vous inquiétez pas, cette configuration n' est qu'un processus ponctuel. Nous devons maintenant indiquer à Git comment lancer le code VS. Nous écrivons à nouveau l'outil Git config Global DIV. Scode point CMD. Codes doubles. Maintenant, dans ma machine, j'ajoute du code sous forme de chemin de code VS, afin de pouvoir l'exécuter depuis n'importe quel répertoire. Si vous ne l'ajoutez pas à votre parcours, ne vous inquiétez pas, je vous le montrerai dans une minute. Ici, nous ajoutons du poids, ce qui indiquera à notre terminal d'attendre. Ensuite, nous utilisons D, qui est pour différencier ou comparer des fichiers, puis nous avons deux autres arguments, à savoir dollar local avec toutes les lettres majuscules espace dollar distantes. Il s'agit des espaces réservés à l'ancienne copie et à la nouvelle copie de notre fichier Maintenant, assurons-nous que nous avons ajouté cette commande dans notre configuration ou non. Nous pouvons donc voir tous nos paramètres de configuration par Git config, Global E, et appuyer sur Entrée. Ici, nous pouvons voir toute notre configuration. Voyez ici que notre dollar local et notre dollar distant ne sont pas ajoutés. Vous pouvez les ajouter. Enregistrez ce fichier, joignez ce fichier de configuration Git Revenons maintenant à Git Bash. Si nous voulons voir des modifications dans le code VS, au lieu d'écrire Git Dev, nous écrivons l'outil Git DV Cela permettra de comparer ce que nous avons dans le répertoire de travail et ce que nous avons dans la zone de préparation. Et il demande le lancement de VSCode. Écrivez « oui » et entrez. Vous voyez, nous avons ici notre fichier du chapitre 1. Maintenant, si vous ne comprenez pas les changements dans un seul fichier, nous pouvons le diviser en deux fichiers. Dans le coin droit, nous avons trois points ici, nous devons sélectionner la vue en ligne Si vous n'arrivez toujours pas à accéder à des fichiers côte à côte, vous devez appuyer sur Ctrl plus B ou Commande+B pour fermer ce panneau de l'explorateur. Ici, nous pouvons clairement voir ce que nous avons changé, c' est-à-dire que nous supprimons ces trois lignes et que nous ajoutons cette ligne verte. Il s'agit de notre ancien code de stage et nous avons apporté des modifications à ce code local. Maintenant, si à l'avenir, vous voulez voir les modifications, vous devez simplement écrire l'outil Git Div. Vous vous demandez peut-être comment pouvons-nous constater changements entre le code de zone de transit et le code de validation ? Nous fermons cette vue de comparaison et dans notre tableau de bord Git, nous devons simplement écrire l'outil Git Div, Dash Dash Stage et appuyer sur Entrée. Ici, on n'obtient rien. Peux-tu me dire pourquoi ? Parce que notre code de zone de transit est le même que notre code de validation. Nous devons mettre en place nos nouveaux changements. Nous écrivons Git add point. Maintenant, nous exécutons à nouveau l' outil Git D. Étape Dash Dash. Lancez via le code, écrivez oui et voyez, nous obtenons ici les modifications entre code régional de la scène et le code de validation. Pour résumer cette leçon, si nous voulons voir les changements entre notre code local et le code d'étape, nous utilisons l'outil Diff, et si nous voulons voir les changements entre le code stagecde et le code Commit, nous utilisons l' outil Di, dest Vous regardez ce cours en permanence, alors, selon ma suggestion, faites une pause de dix à 15 minutes loin de votre écran. Écoutez de la musique ou passez du temps avec votre famille. Prenez soin de vos yeux et à la prochaine leçon. 19. Raccourci pour statut: Actuellement, si nous voulons voir le statut actuel, nous écrivons git status. Mais ces commandes renvoient un statut très long. Il existe maintenant un autre moyen rapide d'obtenir le statut. Pour cela, nous créons un nouveau fichier, chapitre deux points TxD, et y saisissons du texte Nous changeons également quelque chose dans le fichier du chapitre 1. Revenons maintenant à notre tableau de bord Git et au lieu d' écrire git status, nous écrivons git status a en abrégé, puis nous appuyons sur Enter. Vous voyez, ici, nous avons peu de statut. C'est beaucoup plus facile à voir. Nous avons maintenant deux colonnes, gauche et la colonne de droite. Cette colonne de gauche représente la zone de transit et la deuxième colonne représente notre répertoire de travail ou notre zone locale. Actuellement, nous avons modifié notre fichier du chapitre 1 dans la zone de préparation et également dans la zone de travail. C'est pourquoi nous obtenons ici à la fois M et M pour modifié. Laissez-moi vous expliquer de manière simple. Notre fichier du chapitre 1 dans la zone de transit est différent du fichier du chapitre 1 dans notre commit. C'est pourquoi nous arrivons ici en premier. Et notre fichier de zone de travail actuel est également modifié par rapport à celui que nous avons dans notre zone de transit. C'est pourquoi nous sommes ici également. Permettez-moi de vous le montrer de façon pratique. Ici, nous écrivons Git add Chapter one point TXT Si nous écrivons à nouveau ici, git status a, vous voyez, ne vient pas de la colonne de droite, ce qui signifie que notre code de travail est le même que le code préparé. Et si nous validons le premier fichier, il sera également supprimé d'ici. Maintenant, vous vous demandez peut-être pourquoi nous en sommes arrivés là à un double point d'interrogation ? Parce que nous créons un nouveau fichier. C'est pourquoi nous arrivons tous les deux à un point d'interrogation. Ajoutons le fichier du chapitre deux dans la zone de préparation. Git ajoute le chapitre deux TXT. Ensuite, nous retrouvons le statut. C, nous obtenons ici A, qui signifie ajouté. C'est ainsi que nous pouvons rapidement voir le statut. Si vous souhaitez voir le statut complet, vous pouvez utiliser Git status. Si vous aimez cette approche, vous pouvez utiliser ce raccourci. Le choix vous appartient, cela dépend entièrement de vous. 20. Afficher l'historique des engagements: À l'heure actuelle, nous avons validé du code à de nombreuses reprises. Et si on voulait voir tout ce qui s'engage ? Donc pour cela, nous l'écrivons ici, nous l' enregistrons et nous appuyons sur Entrée. Ici, nous avons tous les Camtes dans ordre de la laitue par rapport à la précédente Au tout début, nous obtenons notre dernier identifiant. Chaque commit a son identifiant unique qui est généré automatiquement par celui-ci Lorsque nous voulons accéder à cet acarien ou que nous voulons voir ce qu'il contient , en utilisant cet identifiant unique, nous pouvons accéder à ce commit spécifique Maintenant, nous passons de headpoint à master. Vous vous demandez peut-être quel est le point de départ à maîtriser. Ne t'inquiète pas pour ça. Je vais vous en parler dans les prochaines sections. Pour l'instant, sachez que ce git master est un nom de branche par défaut. La branche est une zone que nous avons créée pour notre propre usage et ce responsable nous dit que nous travaillons actuellement sur cette branche principale. Ne vous inquiétez pas, je vous expliquerai cela en détail dans les prochaines sections. Maintenant, après cela, nous obtenons nom de l'auteur et ici nous obtenons le courrier électronique de l'auteur. Au fur et à mesure que nous obtenons la date et l'heure auxquelles ce commit a eu lieu. Ici, en bas, se trouve notre message de validation. En utilisant ce message de validation, nous savons ce qu'il contient, et c'est pourquoi je vous demande d' écrire un message de validation significatif, que vous et votre collègue pouvez comprendre. Actuellement, nous n'obtenons que trois ou quatre détails de validation , car ces validations sont divisées en pages. Si nous voulons voir d'autres pages, appuyez sur espace. Vous voyez, voici nos autres validations. Maintenant, pour quitter, il suffit d'appuyer sur Q. Maintenant, cette commande de journalisation comporte des options très intéressantes. Ici, nous pouvons écrire le journal Git, tiret d'une ligne. Cela renverra la liste de validation sur une ligne. Nous obtenons donc ici son identifiant unique, et nous sommes les seuls à obtenir une courte description ou un message de validation. Nous avons une autre option, qui est Git log dash dash one line, dass reverse Et voyez, ici, nous avons notre liste de validations dans l'ordre inverse, c' est-à-dire du premier commit au dernier commit. Maintenant, la commande log est une commande puissante pour l'historique de navigation. Nous l'utiliserons beaucoup dans la prochaine section. En fait, nous avons une section complète pour parcourir l'historique de notre code. Pour l'instant, passons à l'essentiel. 21. Désengager les fichiers: Maintenant, si je vérifie notre statut, nous sommes modifiés ici pour le fichier du chapitre un, et nous ajoutons également un nouveau fichier au chapitre deux. Maintenant, comme je vous l'ai déjà dit, nous ne devrions jamais commettre deux tâches différentes en un seul commit. Nous devons donc d'abord valider notre fichier du chapitre deux, puis nous devons valider notre fichier du chapitre un modifié. Pour cela, nous allons d'abord démonter le fichier du chapitre 1. Nous écrivons, récupérons, restaurons das stage et nous écrivons ici le nom de notre fichier, chapitre un point THD. Ici, nous pouvons également écrire plusieurs noms de fichiers, ou nous pouvons écrire un modèle, ou nous pouvons même écrire un point, qui annulera toutes les modifications de notre code Pour l'instant, ici, nous voulons uniquement démonter le fichier THD du chapitre 1 Maintenant, si nous vérifions à nouveau le statut ici, nous devenons rouges, ce qui signifie qu'il a été modifié dans la zone locale ou de travail. Maintenant, il est important que vous compreniez comment fonctionne réellement cette commande de restauration. La commande de restauration prend essentiellement la copie de l'environnement suivant. Ne vous y trompez pas. Laissez-moi vous expliquer de manière simple. Donc, lorsque nous écrivons git restore stage, chapitre 1 point ThD, en gros, vous dites que nous voulons démonter le fichier THD du chapitre 1 Git prend une copie de l'environnement suivant. Quel est l' environnement suivant après la scène ? Souvenez-vous de ce chiffre. Commit est l'environnement suivant après l'environnement d'étape. Il prend donc simplement une copie de notre fichier du chapitre 1 de la dernière commande et l' ajoute simplement dans la zone de préparation. Mais c' est ce qui change dans notre domaine de travail. Indirectement, nous démontons notre fichier du chapitre 1. Maintenant, si je vous pose une question, si nous exécutions cette commande, Get restore stage Chapter two point TXT. Donc, comme je vous l'ai dit, cette commande prendra la copie de l'environnement suivant, qui est l'environnement Commit. Mais notre fichier du chapitre deux n' est pas disponible lors la dernière validation car nous venons de créer notre fichier du chapitre deux, et c'est pourquoi nous ne validons jamais ce fichier. Cette commande supprimera donc notre fichier du chapitre deux de la zone de transit. Vérifions ce statut d'identification. voyez, ici, nous avons deux points d'interrogation, ce qui signifie que notre dossier est en bonne voie. Pour résumer rapidement, si vous avez accidentellement ajouté des modifications à la zone de transit que vous ne souhaitez pas inclure dans le commit suivant, git restore d stage vous aide à replacer ces modifications dans votre répertoire de travail. Cela vous donne la possibilité de réévaluer ou d'apporter réévaluer ou autres modifications avant de les valider. C'est ainsi que nous démontons nos fichiers. 22. Supprimer les modifications dans les fichiers locaux: Maintenant, nous apportons parfois des modifications à notre répertoire de travail, et nous voulons ignorer ces modifications. En termes simples, nous voulons restaurer nos fichiers locaux avec les fichiers de zone prédéfinis. Nous avons donc modifié ici notre fichier du chapitre 1. Supposons que nous voulions annuler ces modifications afin de pouvoir restaurer ce fichier local du chapitre 1 avec le fichier du chapitre 1 de notre zone de transit. Pour cela, nous utilisons la même commande qui est Git restore. Et ici, nous écrivons le nom de notre fichier qui est le chapitre 1 point THD. Maintenant, auparavant, nous écrivons la commande, get restore as staging, chapitre 1 point TXT, qui prend une copie de l'environnement suivant, qui est commit. Parce que dans cette commande, nous mentionnons stage comme notre environnement actuel en utilisant ce tiret comme stage. Maintenant, si nous supprimons le stage de cette commande, pouvez-vous deviner quel est l'environnement actuel ? Actuellement, nous en sommes à l'environnement de travail. Cette commande prendra une copie de l'environnement suivant, et quel est le prochain environnement ? Il prendra une copie de l'environnement de mise en scène. Nous pouvons également écrire cette commande comme ceci. Obtenez et restaurez plusieurs fichiers. Nous pouvons également restaurer tous les fichiers avec point. Notre fichier est restauré depuis la zone de transit. Nous pouvons le vérifier par le statut de Git. Vous voyez, ici nous n'avons qu'un fichier du chapitre deux. Mais pourquoi Git ne restaure pas ce fichier ? Tout simplement parce que Git n'a pas sa copie précédente dans la zone de transit. Git le laisse tel quel. Maintenant, vous vous demandez peut-être comment pouvons-nous supprimer tous les fichiers non suivis ? Pour cela, nous devons taper gate clean command. Vous voyez, nous avons ici une erreur. Il nous indique la force requise, nous pouvons donc écrire Gate Cleang pour une aide rapide Ici, nous pouvons voir que pour forcer la suppression, nous devons utiliser F et nous pouvons nettoyer le répertoire entier. Nous avons également utilisé. Nous écrivons gate clean f, D. Assurez-vous par cette commande tous les fichiers non transformés sont supprimés de notre zone de travail et que nous ne pourrons pas restaurer ces fichiers Vérifiez donc quelles piles vous nettoyez. Maintenant, vérifions le statut. voyez, ici, nous n'obtenons rien, ce qui signifie que tous les fichiers sont restaurés. 23. Restaurer à une version antérieure: Nous savons maintenant qu'une fois qu'il commence à suivre un fichier, il stocke chaque version de ce fichier dans l'historique. Donc, si par erreur, nous avons modifié notre fichier et l'avons également validé, nous pouvons le restaurer à partir de l'historique de git Donc, pour démontrer que nous supprimons d'abord notre fichier du chapitre 1, puis nous restaurerons ce fichier depuis le dépôt Git. Vous souvenez-vous donc de la commande que nous utilisons pour supprimer le fichier du répertoire de travail et également de la zone de transit ? Bien, nous utilisons Git RM, chapitre un point TXT. Voyons notre statut. Vous voyez ici, dans la zone de préparation, que nous avons supprimé le fichier du chapitre 1. Maintenant, validons ces modifications. Donc, supprimez le fichier du chapitre 1 à restaurer. Vérifions-le également dans le code VS. Vous voyez, notre fichier du chapitre 1 est supprimé. Supposons maintenant que nous voulions récupérer ce fichier. Restaurons donc ce fichier à partir du dépôt Git ou de l'historique Git. Regardons notre historique avec Gitlog en une seule ligne. Ici, nous voulons restaurer notre fichier du chapitre 1 à partir de l'avant-dernier commit, ce que nous avons fait. Pour cela, nous avons écrit git restore H pour une aide rapide. Ici, nous pouvons voir qu'après la restauration, nous pouvons ajouter plusieurs options. Et après cela, nous devons mentionner notre source. Source signifie essentiellement commit, et après cela, nous devons mentionner le chemin de notre fichier. Maintenant, permettez-moi de vérifier à nouveau l'historique, Git enregistre une ligne. Nous pouvons maintenant écrire Git, source restaurée. Ici, nous écrivons notre identifiant de validation à partir duquel nous voulons restaurer. Nous écrivons ici cet identifiant de validation. Si nous voulons restaurer un fichier à partir d'un autre historique de validation, nous devons écrire cet identifiant de validation, puis notre nom de fichier, chapitre un point TXT. Maintenant, vérifions le statut. voyez, ici, nous obtenons fichier non suivi et si nous le vérifions dans le code VS, voyez, nous obtenons à nouveau notre fichier du chapitre 1 C'est ainsi que nous restaurons le fichier à partir de l'historique des validations. 24. Opérations Git de base dans VS Code: Donc, jusqu'à présent, dans cette section, nous exécutons chaque tâche avec une ligne de commande, et j'espère que cela dissipera vos doutes sur les opérations de base de Git. Désormais, dans notre code VS, nous pouvons également effectuer certaines opérations de base pour Git. Nous passons donc au panneau de contrôle de source, et nous obtenons ce type d'interface. Dans cette liste de modifications, nous obtenons la liste des modifications. Ici, nous obtenons les mêmes résultats que ceux obtenus avec la commande git status. Nous avons ici un changement, qui se trouve dans le fichier du chapitre 1. Si nous cliquons sur ce fichier, nous pouvons comparer ici notre code actuel avec le code précédent. Nous pouvons également voir ici que ce fichier est un nouveau fichier non suivi. Maintenant, pour mettre en scène ce fichier, nous pouvons le faire très facilement. Il suffit de cliquer sur ce bouton plus. Vous voyez, ici, nous avons des changements d'étape. Nous pouvons également démonter ce fichier très facilement. Il suffit de cliquer sur le bouton moins. Nous avons maintenant des modifications locales dans notre répertoire de travail. Mettons en scène ces changements. Maintenant, vous vous demandez peut-être si nous pouvons valider à partir du code VS ? Et la réponse est oui. Nous écrivons donc ici notre message de validation. Ajoutons à nouveau le fichier du chapitre 1 du code VS. Maintenant, cliquons sur ce Commit, et nous avons validé ce code avec succès . Maintenant, je vais te montrer quelque chose de vraiment cool. Passons au panneau de l'explorateur, et à partir de ce bas, nous obtenons la chronologie. Permettez-moi de zoomer un peu. Vous trouverez ici l'historique de notre fichier ouvert actuel. Ici, nous obtenons toutes les modifications que nous avons apportées à notre code. Si nous voulons voir l'historique du kit, nous utilisons ici cette option de filtre. Il suffit de supprimer la vérification de l'historique local et nous obtenons ici l'historique de ce fichier actuellement ouvert, qui est le chapitre 1. Nous pouvons le consulter en cliquant dessus. C'est ainsi que nous pouvons utiliser notre code VS pour des opérations simples. Maintenant, vous vous demandez peut-être pourquoi ne pas vous montrer cette façon de faire les opérations de base ? Pourquoi j'enseigne la ligne de commande ? Imaginez si je vous montre directement cette leçon sans expliquer toutes les commandes précédentes, vous serez certainement très confus et vous ne comprendrez jamais les bases de git. C'est pourquoi je vous apprends d'abord la ligne de commande. Maintenant, vous savez exactement ce que vous faites dans votre panneau de contrôle de source. 25. Introduction à Github Desktop: Maintenant, laissez-moi vous montrer l'interface utilisateur graphique d'utilisation de Git, qui est Github Dktop. C'est l'un des meilleurs outils de GI convivial pour les débutants pour utiliser Git. Git Kraken est un autre outil populaire, mais il est peu complexe pour les débutants Dans ce cours, nous allons donc apprendre Github desktop, qui est adapté aux débutants et je vais également vous montrer Git Kraken, ce que je recommande Rendez-vous donc sur desktop.github.com, téléchargez l'application Github Dktop et installez-la Voici à quoi cela ressemble lorsque nous ouvrons cette application pour la première fois. Il vous demande de vous connecter avec un compte Github, ou si vous n' avez pas de compte Github, vous pouvez créer un nouveau compte gratuitement J'ai déjà un compte Github, donc je me connecte rapidement avec celui-ci Ici, il me demande mon nom et mon e-mail. Assurez-vous de bien vérifier ces informations. Voir ici, je peux également modifier mon e-mail et confirmer. Maintenant, ici, nous pouvons créer un nouveau dépôt Git et nous pouvons également ouvrir un dépôt Git, et nous pouvons également cloner un dépôt existant. Pour l'instant, ne vous inquiétez pas pour le clonage. Nous verrons cela dans la prochaine section. Nous ouvrons donc ici le dépôt Git. Nous accédons au dossier du projet et sélectionnons notre projet de suivi des tâches. Vous voyez, nous avons ici ce type d'interface. Si nous changeons quelque chose dans notre fichier, ajoutons du texte. J'écris ce premier chapitre pour l'introduction. Et enregistrez les modifications. Maintenant, si nous changeons quelque chose dans notre fichier dans notre application de bureau Github, nous obtenons ces modifications ici À partir de cette icône de réglage, nous pouvons sélectionner le type de division. Maintenant, voici une chose à propos de cette application. Cette application va directement valider notre code. Si nous ne voulons pas valider ce fichier, nous pouvons le désélectionner de cette liste Cette liste est une zone de transit. OK. Voyons maintenant comment valider notre code dans Git. Nous écrivons donc ici notre description de tri. Vous pouvez voir que par défaut, il affiche un message de validation, nous pouvons écrire premier chapitre de mise à jour pour essayer Github Desktop Et si nous voulons écrire une mauvaise description, nous pouvons également l'écrire ici. Ensuite, pour Amit, il suffit de cliquer sur ce Kammit pour accéder à notre branche qui est master. Et c'est fait. Nous avons validé notre code avec succès. Maintenant, nous pouvons également voir l'historique de nos amides depuis cet onglet Voici la liste de tous nos amides. En sélectionnant chaque amid, nous pouvons voir le contenu de son fichier. Vous pouvez donc voir que l'application de bureau iTU simplifie tellement Git. Si vous aimez utiliser la ligne de commande ou le code VS, ou si vous aimez iHub desktop, tout va bien Mais comme vous le voyez avec la ligne de commande, nous pouvons contrôler davantage sur Git. Nous pouvons effectuer diverses tâches à l'aide des commandes du kit. Honnêtement, j'aime utiliser les commandes du kit et le code VS, mais le choix vous appartient. Vous pouvez choisir un outil dans lequel vous vous sentez en confiance. Cela dépend entièrement de vous. 26. Introduction à GitKraken: Ainsi, dans la leçon précédente, nous voyons notre premier outil d'interface graphique, GitHub Desktop Nous avons un autre outil , le kit Kraken, qui est un peu complexe, mais une fois que vous l'aurez compris et que vous vous serez familiarisé avec lui, vous l' utiliserez davantage De plus, Kit Kraken possède plus de fonctionnalités que l'application de bureau GitHub Personnellement, j'aime bien utiliser Kit Kraken. Vous en verrez la raison dans les prochaines sections. Installons également TKracon dans notre système. Rendez-vous sur kitcracon.com, et vous trouverez ici un bouton Cliquez simplement dessus pour lancer le téléchargement. Une fois le téléchargement terminé, nous ouvrons une installation et nous pouvons facilement installer Git Kraken Maintenant, lorsque nous ouvrons Git Kraken pour la première fois, nous obtenons l'option Ouvrons une option de dépôt et nous pouvons nous connecter en utilisant Github Pour l'instant, ouvrons un dépôt. Vous voyez, les détails de mon compte Git sont automatiquement effacés parce que je me connecte simplement lors de la précédente leçon de bureau Github Je peux donc filmer ça. Nous avons ici ce type d'interface. Nous pouvons ouvrir le dépôt ou cloner depuis Internet, ou nous pouvons créer un nouveau dépôt. Actuellement, nous voulons ouvrir le référentiel depuis le local Nous allons donc dans le référentiel ouvert et ouvrons notre projet en cours. Voici à quoi ressemble notre dépôt. C'est un peu complexe pour les débutants car c' est tellement encombré Je ressens la même chose lorsque j'utilise Git Kraken pour la première fois. Mais croyez-moi, au fur et à mesure que nous nous familiarisons avec Git, tout cela devient super facile. Voici toutes les comètes et nous pouvons voir plus de détails sur cette Camt en les sélectionnant et sur le côté droit, nous obtenons les Vous voyez ici que nous obtenons un identifiant de validation, un message de validation. Ensuite, nous obtenons des informations sur l'auteur qui a validé cette date et cette heure et en dessous, nous obtenons une liste des fichiers que nous supprimons, ajoutons ou modifierons. En gros, nous obtenons les modifications que nous avons apportées dans ce commit. Ici, nous pouvons raccourcir ces fichiers et nous pouvons également voir les fichiers dans une arborescence de dossiers. Lorsque nous cliquons sur ce fichier, vous voyez, ici nous obtenons le fichier et nous pouvons voir ce fichier en mode fractionné à l'aide de cette icône. Pour le moment, tout tourne autour de Kraken. Ne t'inquiète pas. Nous verrons Git Kraken plus en détail dans les prochaines sections Rendez-vous dans la section suivante. 27. Section 03 Regarder l'historique des codes: Bienvenue dans la troisième section du cours d'informatique ultime. Dans cette section, nous verrons comment parcourir plus en détail notre historique de Cami abord, nous verrons comment voir tous les commits, filtrer les commits par nom d' auteur, date, message de validation. Nous verrons également comment définir des raccourcis pour les commandes longues ? Ensuite, nous verrons des amides spécifiques, comparerons deux amides, reviendrons au commit spécifique, détecterons les bogues, blâmerons, attribuerons étiquette au gummit et Je sais que vous êtes enthousiaste, alors commençons cette section. 28. Projet local de clonage: Maintenant, pour parcourir l'historique, nous avons besoin d'un projet dans lequel nous avons peu de validations. Donc, en dessous de cette vidéo, vous trouverez le dossier des ressources, et dans ce dossier, j'ai ajouté le projet Task Track que j'ai créé en SDML et CSS Laissez-moi vous montrer comment cloner n'importe quel projet Git existant sur votre machine. Donc, lancez le dossier de ressources, et voici le cours Task track Zip Nous pouvons le décompresser, nous pouvons simplement copier ce dossier à partir d' ici et le coller dans le dossier de notre projet Nous pouvons maintenant commencer à utiliser ce projet. C'est aussi simple que ça. 29. Explorer la commande Log en détail: Tout d'abord, ouvrons notre projet dans Git Bash. Dans la section précédente que nous avons vue pour suivre l'historique de notre projet Git, nous utilisons la commande Git clock. Cette commande nous donnera tous les détails de validation sur chaque commit , comme Commit a les détails de l'auteur, date et l'heure, et le message de validation. De plus, nous mettons ces validations dans l'ordre, ce qui signifie que nous obtenons d'abord le dernier commit et à la fin, nous obtenons notre premier commit. Nous avons plus d'une page, puis nous pouvons appuyer sur la touche espace ou nous déplacer de haut en bas à l'aide des touches fléchées. Pour quitter cette commande, nous appuyons sur Q. Maintenant, vous souvenez-vous par quelle commande nous obtenons ce journal avec le moins de détails ? Bien, nous pouvons écrire ici Git log dash sur une ligne. Vous voyez ici que nous ne recevons que peu de messages «   has » et que nous validons. Nous avons déjà vu ces deux commandes. Voyons maintenant cette commande de journalisation plus en détail. Et si nous voulions voir les fichiers changer à chaque commande ? Par exemple, dans la deuxième commande, quels fichiers sont modifiés ou que modifions-nous dans la dernière commande ? Pour cela, nous devons simplement écrire datat à la fin de notre commande de log Cela signifie des statistiques. voyez, ici, nous avons un fichier modifié et nous l'avons changé par son nom ici. Après cela, nous pouvons voir 16 insertions. De même, nous avons ces détails pour chaque comète. Maintenant, si vous êtes confus par beaucoup de détails, vous pouvez également le faire. Ajoutez ici une ligne et verrez que nous obtenons un peu moins de détails sur Comet. Ici, nous ne voyons que le fichier qui change et le nombre de lignes que nous modifions. Mais que se passe-t-il si nous avons besoin de voir quelle ligne nous ajoutons, supprimons ou mettons à jour ? Ne vous inquiétez pas, c' est très simple. Nous écrivons gate, log, une ligne, Despatch. Ici, nous obtenons les lignes en vert, que nous avons ajoutées dans le fichier. Et si nous supprimons quelque chose de ce fichier, ces lignes apparaissent en rouge. Grâce à ces commandes, nous pouvons voir très rapidement ce qui s'est passé dans notre projet. Maintenant, pour arrêter cela, nous devons appuyer plusieurs fois sur l'espace, et quand nous arrivons, nous appuyons sur Q. 30. Filtrage de l'historique: Voyons maintenant comment filtrer historique de nos Commit et n'obtenir que les détails spécifiques que nous voulons voir. C'est la même chose que nous filtrons les produits sur Amazon. Et c'est aussi très amusant à faire. Laisse-moi te montrer. Nous verrons donc d'abord comment filtrer nos amis en utilisant le nom de l'auteur Ici, nous écrivons gate, log, une ligne, author est égal à ici nous écrivons notre nom d'auteur. Si le nom de l'auteur comporte un espace, vous devez inclure ce nom dans les codes doubles. Sinon, ça se confond. Ici, ce nom d'auteur est aussi sensible, il faut écrire exactement le même nom. Et si vous voulez ignorer sensitive, alors à la fin, écrivez simplement I et obtenez ignore sensitive. Vous voyez ici que nous obtenons des gamètes nommés Mt Patel. Comment filtrer davantage ces acariens ? Bien, nous pouvons filtrer les amides en utilisant des dates. Donc Git log, tiret une ligne, tiret B quatre équivalent à ici, nous devons écrire notre date en double code comme celui-ci. 2024 notre mois 01-30. Tu vois, ici, nous recevons tous les amides avant cette date. Maintenant, parfois, lorsque nous travaillons sur de grands projets, nous aimons voir Camids s' engager après une date précise Nous avons donc ici après, et ici nous passons notre date dans le même format. Nous pouvons également transmettre des chaînes comme hier, deux jours, il y a une semaine, il y a un an, etc. C'est très utile. Je m'en sers beaucoup pour prendre un ou deux jours de congé. Maintenant, nous voulons parfois filtrer notre message de validation. Par exemple, uniquement les validations dont le message de validation contient le mot task. Nous l'écrivons, enregistrons, tirons une ligne, tirons l'équivalent en double code, nous écrivons une tâche. Cela fait également la distinction majuscules/majuscules, alors assurez-vous d'écrire correctement le mot. voyez, ici, nous obtenons kmtes dont le message de validation contient ce mot de tâche, et si nous ignorons la distinction majuscules/minuscules, nous ajoutons ici write, nous ajoutons ici I.C , ici nous obtenons kmtes dont le mot de tâche figure dans le message de validation Maintenant, nous voulons parfois trouver un commit spécifique qui ajoute ou supprime la fonction ou la variable. Par exemple, nous travaillons sur le projet Todos, nous voulons savoir quand nous ajoutons la fonction Ajouter des objets ou quand nous la supprimons Nous pouvons donc faire quelque chose comme ça. Git log, tiret d'une ligne, majuscules ici en double code, nous devons écrire le nom de notre fonction, addTDS Actuellement, dans ce projet, nous n'avons pas cette fonction. Je cherche donc ici. Vous voyez, nous avons ici les commits. Maintenant, imaginez que nous voulions parfois ne voir que les trois dernières validées ou les cinq dernières comètes. Ensuite, nous pouvons écrire git log, tiret d'une ligne, cinq. Vous voyez, nous avons ici les cinq dernières comètes. De plus, nous avons parfois besoin de voir l'historique d'un fichier spécifique. Par exemple, nous voulons voir le point d' index STMLFlehtory, lorsque ce fichier Alors on pourra faire quelque chose comme ça. Git log, tiret d'une ligne. Indexez le point html, et regardez ici nous pouvons voir l'historique. Maintenant, si votre nom de fichier est déjà enregistré dans la bibliothèque Git comme votre journal de fichiers, vous pouvez ici séparer cette commande du nom de fichier en utilisant un double tiret. Vous voyez, nous obtenons ici le même résultat. Maintenant, permettez-moi de vous poser une question. Et si dans cette commande, nous voulions voir les modifications à l'intérieur de ce fichier ? C'est vrai. Nous devons écrire la page en tiret, mais nous devons écrire la page avant ce double tiret, car ce double tiret sépare la commande du nom du fichier et nous voyons ici les modifications apportées au fichier. 31. Définir des alias pour les commandes: Maintenant, nous devons parfois exécuter plusieurs commandes Git que nous utilisons très fréquemment, mais elles sont un peu longues ou difficiles à mémoriser. Nous pouvons définir un raccourci pour ces commandes. Par exemple, nous exécutons fréquemment cette commande d' une ligne Git log dash. Définissons un raccourci ou, en termes simples, définir un Lias.ellas signifie simplement Nous écrivons Git config dash global Alias, point final. Ici, nous devons écrire le nom de notre raccourci pour cette commande. Nous écrivons donc log for log. Assurez-vous d'utiliser des noms significatifs, car en fin de compte, vous devez vous souvenir des noms des raccourcis, puis nous devons écrire notre commande d'origine, qui est log one line. Ici, nous devons envelopper notre commande avec des codes doubles car il y a un espace entre les deux et appuyer sur Entrée. Maintenant, vérifions-nous si nous l'avons correctement configuré ou non. Nous l'écrivons donc config global E, et il ouvrira notre fichier de configuration dans notre éditeur de code par défaut Tu vois, à la fin, nous demandons à notre alias log d'enregistrer une ligne. Si vous souhaitez mettre à jour ou supprimer quoi que ce soit, vous pouvez le faire à partir d'ici. Pour l'instant, nous ne voulons rien changer, alors fermons ce fichier. Maintenant, utilisons notre alias. Écrivez t lg, et vous verrez ici que nous obtenons le résultat de notre commande C'est ainsi que nous pouvons définir des raccourcis pour économiser temps et de la mémoire, car nous n'avons pas besoin de nous souvenir de l'intégralité de la commande. Pour le reste de ce cours, je n'utilise pas cet alias car si quelqu'un s' inscrit au milieu de ce cours, il ne comprendra pas comment j'utilise l'alias. Mais vous pouvez certainement l'utiliser pour votre pratique. Cela dépend entièrement de vous. 32. Afficher l'engagement spécifique en détail: Jusqu'à présent, nous avons vu comment voir tous les commits. Mais parfois, nous voulons voir les détails spécifiques, comme commit spécifique de Bits Commit. Pour cela, nous pouvons écrire Git, show, et ici nous écrivons notre référence de validation. Vous trouverez ici les détails de ce commit spécifique. Ici, nous pouvons voir que nous n' avons qu'un seul fichier modifié et en bas, nous avons les modifications. Maintenant, si nous voulons obtenir le dernier commit récent, nous pouvons écrire ici, obtenir la tête en majuscules. Si nous voulons aller plus loin dans la liste de validation sans écrire le commit, nous pouvons écrire ici jusqu'à et nous pouvons écrire ici le numéro, disons deux. Git trouve donc d'abord la tête, puis avance deux étapes vers le bas et nous donne des détails sur ce commit. Vous pouvez voir que c'est très simple et facile. Maintenant, si nous voulons voir le nom du fichier modifié dans notre commit spécifique, nous devons écrire ici Git, show, head till two, name only. voyez, ici nous n'avons qu'un seul fichier qui change dans ce commit. Maintenant, permettez-moi de vous donner une autre situation. Et si nous voulions voir le contenu complet du fichier spécifique dans un commit spécifique. Nous obtenons donc notre commande précédente et ajoutons simplement la colonne ici. Et ici, nous écrivons le chemin de notre fichier comme file point TXT, ou si nous avons un dossier, nous pouvons écrire Css detyle point css Ici, nous obtenons le contenu complet du fichier spécifique dans notre dernière troisième commande. C'est ainsi que nous pouvons voir le commit spécifique plus en détail. Dans la leçon suivante, nous verrons comment comparer les commandes. 33. Comment comparer deux commits: Ainsi, lorsque nous devons comparer A deux validations pour voir ce qui a été ajouté, supprimé ou modifié dans notre code. Pour cela, nous allons utiliser la commande Git di. Cette commande nous indiquera la différence entre notre répertoire de travail et le dernier commit. À l'heure actuelle, nous n' avons aucune différence. C'est pourquoi nous ne recevons rien. Ici, nous pouvons également comparer deux validations spécifiques. Disons « tête dans deux espaces ». Ici, aux deux endroits, nous pouvons également ajouter une référence de validation. Vous voyez, il contient plusieurs fichiers et plusieurs modifications. Maintenant, si nous voulons voir un seul fichier spécifique changer entre ces validations, que ferons-nous ? Simplement, à la fin de cette commande, nous ajoutons notre nom de fichier, style CSS point CSS. Dans la leçon suivante, nous verrons comment restaurer notre code selon le commit spécifique. 34. Retour à une version spécifique: Maintenant, nous voulons parfois restaurer notre code dans l'un des kits spécifiques. Par exemple, cet omet. Nous voulons que notre code soit exactement ce que nous avons engagé dans cette omission Nous écrivons donc Git, vérifions-le, et nous ajoutons ici notre référence d' omission Tu vois, on passe ici à ce met. Mais ici, nous recevons également cet avertissement, qui nous met en garde contre l'état de la tête détachée. Maintenant, de nombreux développeurs sont très confus au sujet de l'État, mais ce n'est pas très difficile. Laisse-moi t'expliquer. Nous avons ici notre structure de validation. C'est le nombre de comètes. C'est le premier commentaire et tout à droite, nous nous sommes rencontrés pour la dernière fois Ici, nous pouvons voir que tous ces commits sont liés à son précédent commit. Maintenant, comme nous pouvons le voir dans notre Git Bash, nous sommes actuellement dans notre branche principale Branch est le sujet peu avancé de Git. Nous verrons cela dans la prochaine section. Pour l'instant, comprenez simplement que la branche est comme une ligne que les développeurs créent pour le travail de projet individuel. Par exemple, si le responsable vous demande de travailler sur un formulaire de connexion, en tant que développeur, vous créez une nouvelle branche pour travailler sur le formulaire de connexion. Master ou main est une branche par défaut de git. Ici, ce master est une référence qui représente notre dernier kmt. Maintenant, chaque fois que nous validons un nouveau code, ce maître passe au dernier kat. Maintenant, comme nous le savons dans Git, nous pouvons créer plusieurs branches. Dans ce cas, comment git sait-il actuellement sur quelle branche nous travaillons ? Pour résoudre ce problème, nous avons une autre référence appelée head. Head indique la branche actuelle sur laquelle nous travaillons. Nous l'avons déjà vu. Au fur et à mesure que nous ajouterons de nouveaux commits, ce responsable et ce master passeront également à notre dernière version. Maintenant, lorsque nous passons au commit spécifique, notre référence principale se déplace vers ce commit. Et voici l'état de tête détaché. Idéalement, lorsque nous sommes dans l'État de tête détaché, nous ne devrions pas y introduire de nouveau code à ce moment-là. Si nous créons un nouveau commit, celui atteint sera ajouté ici. Maintenant, à un moment donné, lorsque nous tournons la tête vers le maître, aucune autre comète ne peut accéder à cette comète Git déclare ce commit comme un commit mort, et après un certain temps, il le supprimera automatiquement de son enregistrement. Il est donc préférable de ne pas valider le code lorsque nous sommes dans l'état de tête détaché. Nous pouvons toujours consulter notre code et expérimenter avec celui-ci. Maintenant, comme nous pouvons le voir ici, notre passe Git change. Auparavant, nous sommes arrivés ici, maître. Mais lorsque nous utilisons la commande spécifique, nous obtenons ici le hachage de validation de notre validation de paiement À l'heure actuelle, si nous enregistrons toutes nos commandes en utilisant Git log sur une ligne, nous n'obtenons ici que les comètes qui sont validées avant cette comète spécifique Les autres comètes sont invisibles à ce stade. Ne vous inquiétez pas, ces autres comètes ne sont pas supprimées. C'est tout simplement invisible. De plus, notre référence principale est ici. Maintenant, pour voir ces comètes invisibles, il faut ajouter ici une autre variable, c'est tout Ici, nous obtenons toutes nos comètes et nous pouvons voir notre référence principale est ici et que notre référence principale est ici Maintenant, pour revenir à la référence principale ou principale, nous pouvons écrire ici Gate, checkout master, et voir, nous passons à master et voir notre tête pointer vers master. Et maintenant, nous avons tous les comads. De cette façon, nous pouvons voir notre code précédent dans notre éditeur de code ou dans l'explorateur de fichiers. Et c'est pourquoi la commande de paiement est importante. 35. Détecter le commit bugged Git Bisect: Imaginez maintenant que quelque chose se passe dans notre code et que nous obtenions nnn Berg dans notre application, alors comment pouvons-nous identifier dans quel bogue de commande s'est produit ? Une solution consiste à vérifier toutes ces commandes une par une à l'aide de la commande de paiement, mais cela prendra beaucoup de temps. Dans git, nous avons une commande pour identifier rapidement la commande de bogue, qui consiste à utiliser Git by set. Pour démarrer ce processus, nous devons écrire gate par set, démarrer et appuyer sur Entrée. Ici, nous pouvons voir que notre Gitbsh est en mode bissection. Maintenant, après avoir lancé le processus de bisection, nous devons d'abord marquer notre commit actuel comme étant bad kommt Si vous voulez savoir quel est l'acarien actif actuel, nous pouvons le voir d'ici, qui est notre commit principal. Ici, nous le marquons comme un mauvais manteau parce que nous rencontrons un insecte dans ce manteau. Divisez-le en deux. De plus, si vous souhaitez marquer un autre kit comme mauvais, à la fin, nous devons écrire sa référence de validation. Je sais que c'est un peu confus, mais dans une minute, vous le comprendrez. Maintenant, après cela, nous devons déterminer la démarche, qui est la dernière bonne rencontre que nous connaissons Par exemple, jusqu'à ce que cela soit atteint, nous savons que notre application n' a aucun bogue. Ensuite, nous devons faire en sorte que cela soit aussi bon que possible. Nous écrivons donc gate, bissect good, et nous saisissons ici notre référence Comite Maintenant, enregistrons simplement nos comètes, voyons, maintenant notre tête passe à la moitié de nos comètes Voici maintenant la partie logique de la commande bisec. Imaginons que nous ayons ces dix comètes. Nous désignons notre dernière comète comme mauvaise comète, et notre première comète est la bonne comète rencontrée. Dès que nous avons défini notre première amet comme étant un bon Kumto, nous nous retrouvons à mi-chemin entre le bien et Maintenant que nous sommes concentrés sur ce point, notre code de travail actuel sera remplacé par ce code amet Nous pouvons consulter notre candidature ici à. Si nous avons un insecte dans ce manteau, nous le marquerons comme étant mauvais. Si nous n'avons pas de bogue dans cette annonce, nous marquerons cette date comme étant une bonne date. Par exemple, nous constatons que cet amet ne pose aucun problème. Nous allons donc marquer cela comme bon en utilisant Git BSc good. Maintenant que nous marquons cet âge comme bon, notre tête se déplace vers le point intermédiaire entre notre mauvais kmt et notre bon kat Maintenant, nous vérifions à nouveau notre code. S'il est bon, nous le marquons comme bon. Et si nous trouvons que ce kamete est mauvais, marquons comme une mauvaise Ce processus continuera à réduire la liste, et nous aurons alors la comète à l'origine de Burg. C'est l'idée même de la commande bisec. Ainsi, dans notre commit, nous pouvons vérifier notre code dans le code Vas et voir s'il contient BG ou non. Imaginons que nous trouvions que ce commit contient un bogue. Ensuite, nous marquons «   get by sec bad ». Maintenant, encore une fois, nous allons vérifier notre liste, voir comment elle est déplacée vers ce commit. Nous vérifions à nouveau notre code et imaginons que ce commit n'a aucun bug. Ensuite, nous allons le rendre performant en utilisant Git Biseccd. voyez, ici, nous obtenons ce commit comme étant celui qui a ajouté le bug dans notre application. C'est ainsi que fonctionne la commande bisec. Cela peut sembler un peu confus, mais si vous utilisez cette commande une fois, vous la comprendrez si facilement par la suite. Maintenant, nous pouvons voir que nous sommes toujours en mode bissection. Pour quitter ce mode, nous devons écrire get bisect reset et voir que nous sommes revenus à notre commande principale C'est ainsi que nous pouvons identifier les bogues dans les compteurs sans vérifier tous les compteurs de la ligne 36. Obtenir la liste des contributeurs: Maintenant, si parfois nous voulons savoir combien de validations ont été effectuées par les utilisateurs pour connaître la contribution. Pour cela, nous avons écrit Git short log. voyez, ici, nous obtenons nom d'utilisateur et le nombre de validations de cet utilisateur. De plus, nous obtenons le résumé des messages de validation. Ici, dans ce projet, je suis le seul contributeur. C'est pourquoi il ne montre que mon nom. Maintenant, nous pouvons même modifier cette commande en utilisant plus d'options. Ici, nous l'écrivons brièvement, H pour une aide rapide. Et voyez ici que nous avons toutes les autres options. Par exemple, nous pouvons écrire N ou tiret numéroté pour raccourcir le résultat en fonction du nombre de validations effectuées par chaque utilisateur Maintenant, si nous avons une longue liste de commits, alors pour chaque contributeur en C, nous devons faire défiler la page. Après ce N, nous pouvons écrire un tiret pour ignorer le message de validation récapitulatif. Ici, nous n'obtenons que le nombre de virgules et le nom d'utilisateur. Dans la leçon suivante, nous allons voir l'historique du fichier. 37. Historique de navigation du fichier: Maintenant, nous avons déjà vu cette commande. Je l'ajoute simplement ici parce que cela fait partie de la navigation dans la section historique. Donc, comme nous le savons, pour regarder l'historique, nous pouvons l'écrire, le journaliser, et pour regarder l' historique d'un fichier particulier, nous pouvons écrire le nom du fichier qui est un point d'index HTML. Voyez ici que nous obtenons la liste des codes dans lesquels ce fichier a été modifié Si nous voulons affiner cette liste, nous pouvons utiliser ici la variable tiret d'une ligne. Tu vois, maintenant c'est lisible. Et si nous voulions voir les modifications se produire dans ce fichier ? Nous pouvons utiliser here datat pour obtenir les statistiques, ou nous pouvons indiquer le nombre de modifications apportées à ce fichier Vous voyez, dans le premier commit, nous avons 150 modifications. De même, nous avons ici 35 modifications dont 32 insertions et 3 suppressions. Maintenant, si nous voulons voir les modifications réelles apportées au fichier, alors ce que nous allons faire à l'endroit où se trouve ce ds dat, c'est écrire dispatch. Vous pouvez voir que les commandes Git ne sont pas difficiles. Ce n'est qu'une question de pratique, et j'ai confiance en vous. Après avoir pratiqué cette commande git dans un projet, vous pouvez les utiliser dans n'importe quel autre projet sans vous inquiéter. 38. Voir l'auteur de chaque ligne [Git Blame]: Maintenant, parfois, dans notre fichier de projet, nous voulons savoir qui est l' auteur d'une ligne en particulier. Cela arrive dans mon projet, un nouveau développeur rejoint mon équipe et il écrit un très mauvais code. Si je demande à quelqu'un qui écrit ce code, personne ne répondra, et je sais déjà qui écrit ce code. Je demande donc toujours à ce développeur de vérifier qui écrit ce code. Je ne me moquais pas de ce développeur au début, nous sommes tous à ce niveau. Il n'y a rien de mal à cela. Personne ne devient parfait dès le premier jour de codage. C'est un voyage qui prend du temps. Pour en revenir à notre exemple Git, si nous voulons connaître l' auteur d'une ligne particulière, nous pouvons écrire git blame, et ici nous écrivons le nom ou le chemin de notre fichier. voyez, ici nous obtenons tout le contenu du fichier ligne par ligne avec les détails. Ici, nous arrivons d'abord à valider la référence dans laquelle cette ligne retourne. Ensuite, nous obtenons le nom de l'auteur et nous obtenons également la date et l'heure. Maintenant, si parfois notre fichier comporte de nombreuses lignes et que nous voulons connaître une seule ligne spécifique, nous pouvons écrire L ici, puis nous écrivons ce numéro de ligne, la fin du numéro de ligne. Disons que nous voulons n'en voir que trois et quatre. Ensuite, nous écrivons 34. Si nous voulons voir les lignes trois, quatre et cinq, nous écrivons 35. Vous voyez ici, nous n'avons que trois, quatre et cinquième lignes. Ainsi, vous pouvez utiliser commande blame pour connaître l'auteur de chaque ligne. Dans la leçon suivante, nous verrons comment attribuer une balise à valider. 39. Marquage des engagements avec des balises: Maintenant, imaginez que cette aide soit prête à être lancée en production, ou que nous voulions marquer ce code de validation comme étant la version 1.0. Mais je le donne déjà dans la version 1.0. Je dois donner ici la version 1.0 0.1. Donc, donner un nom de version au médicament revient à donner des balises dans Git. Marquons cette rencontre comme étant la version 1.0 0.1. Nous écrivons ici git tag, version 1.01. Ici, nous pouvons écrire notre référence de commit et ici nous n'ajoutons aucune référence de commit, puis par défaut, attribuer cette balise à notre commit actuel, qui est le commit principal. Maintenant, si nous enregistrons nos validations, vous voyez, nous obtenons ici la version 1.01 du tag après cette référence de validation Maintenant, si nous voulons vérifier notre code pour ce commit, nous n'avons pas besoin d'écrire cette référence de commit. Nous pouvons simplement utiliser Git, consultez la version 1.0. Tout comme nous utilisons cet ID de validation, nous pouvons utiliser cette balise, version 1.0. Supposons maintenant que je veuille voir tous les tags que j'ai donnés à ce projet. Ensuite, nous écrivons simplement la balise Git et voyons ici que nous obtenons toutes les balises que nous attribuons. Supposons maintenant que nous ajoutions cette balise mystiquement, et que nous voulions la supprimer Nous écrivons donc simplement git tag D, nous écrivons le nom de notre tag, qui est la version 1.01 Nous pouvons maintenant voir que le tag est supprimé de la liste. Nous avons ici cette balise de version 1.0, nous appelons balise légère, ce qui signifie que nous ne donnons à notre amid qu'une référence en tant que version 1.0. Maintenant en marche, nous avons également une étiquette annotée. Maintenant, vous pouvez vous demander ce que sont les balises annotées ? La balise annotée est donc utilisée pour ajouter plus de détails tels que le nom, la date et l'heure du tagger et le message de validation En termes simples, avec les balises annotées, nous pouvons simplement ajouter plus de détails avec nos balises Voici la commande pour les balises annotées. Nous écrivons le tag de porte A pour la version annotée 1.01 M, qui signifie message Et dans les codes doubles, nous pouvons saisir notre message comme dans la version 1.01 Sachez que ce message n' est pas très utile, mais je vous montre simplement que si vous souhaitez ajouter un message avec cette balise annotée, vous pouvez le faire de cette façon Maintenant, si nous écrivons une balise , nous obtenons deux balises. Si vous voulez voir un message texte, nous devons écrire le tag Git N. Vous voyez, ici, nous obtenons les messages du tag. Si notre balise est une balise légère, nous recevons ce message de validation sous forme de message de balise. Donc, ne vous y trompez pas. Maintenant, si nous voyons notre version 1.01 avec la commande Afficher la version 1.01, puis voir ici en haut, nous obtenons également les détails du tag tels que le nom, l' e-mail, la date et l'heure auxquelles nous donnons ce tag et le message du tag C'est ainsi que nous utilisons des balises pour marquer les versions. 40. Historique des engagements dans Github Desktop: Voyons donc l'historique de nos CID dans l'application Github Extra Ouvrons donc ce projet de section dans l'application Github Extra Accédez au fichier, ajoutez le référentiel local. Et nous voyons ici le chemin de notre dossier. Et il vous suffit de sélectionner ce dossier. Dans la leçon précédente, nous verrons comment voir les modifications apportées à l'application de bureau Github Nous allons maintenant voir comment parcourir l'historique des validations à l' aide de cette application. Nous avons donc ici la liste des validations sur le côté gauche et nous avons également ici notre texte et ici en haut, nous avons le message de validation, nom de l'auteur et la référence du commit. Voici maintenant la liste des fichiers modifiés. Si nous cliquons dessus, nous obtenons les modifications ici. De plus, nous pouvons changer de point de vue à partir de ce paramètre Maintenant, nous pouvons voir que nous n'avons que très peu d'options pour parcourir l'historique de nos validations. Par exemple, nous ne pouvons pas filtrer nos validations, ne pouvons pas rechercher une fonction ou une variable spécifique et bien d'autres choses encore. L'application de bureau Github possède une interface utilisateur simple, mais elle n'est pas la meilleure pour utiliser Git C'est un article que j'aime bien. Dans cet article, je vois des développeurs dire qu'ils n' aiment l'application de bureau Github lorsqu'ils sont débutants avec Git Mais à mesure qu'ils apprennent Git plus en détail, ils n'aiment pas vraiment l'application de bureau Github Je suis légèrement d'accord avec cela, mais cela ne signifie pas que vous devez désinstaller l' application de bureau Github Vous pouvez utiliser Github destra Publication si vous êtes Cela dépend entièrement de vous. 41. Historique de navigation dans VS Code et GitKraken: Voyons maintenant comment parcourir historique à l'aide de notre éditeur de code préféré VS code. Ainsi, comme nous l'avons vu dans la section précédente, nous pouvons voir ici nos modifications dans le code. Mais que se passerait-il si nous voulions voir l'histoire de nos comètes et aussi la liste des comètes Nous pouvons le voir dans le code VS, mais nous pouvons le voir en utilisant une extension appelée Gitans C'est l'une des extensions Git les plus populaires de VSCode, et ce qui est amusant, c'est que cette extension a été créée par Git Kraken Vous utilisez Git Kraken au lieu de Github desktop, vous verrez alors la même interface que celle que nous voyons dans cette extension Voyez ici que nous avons deux autres options sur le côté gauche pour git lens. Ouvrez ce premier, laissez-moi dézoomer un peu, fermez-le, fermez-le également. Maintenant, dans ce domaine, nous avons de nombreuses options. Vous voyez, d'abord, nous avons le graphe de validation. C'est l'un des moyens les plus populaires de visualiser l'historique des omissions. Ici, nous pouvons voir, nous obtenons une liste de nos validations et ici nous pouvons également obtenir le texte que nous donnons aux validations. Ensuite, nous avons le message de validation, le nom de l'auteur, les modifications apportées aux fichiers, heure et la référence de validation. En haut, nous avons également la barre de recherche pour rechercher les comètes. Si nous recherchons quelque chose ici, seules les annonces dont le message de validation contient ce mot seront mises en évidence . Maintenant, pour plus de filtres de recherche, nous avons un petit menu déroulant ici. Tout d'abord, nous recevons mes modifications, qui ne nous montreront que les comètes vous avez commises Ensuite, nous avons un message pour rechercher le message de validation. Ensuite, nous avons l'auteur par lequel nous pouvons rechercher les commits par nom d'auteur. Ensuite, nous avons le commit SHA dans lequel nous pouvons rechercher des commits par référence de commit. Ensuite, nous pouvons également rechercher un fichier spécifique. Par exemple, nous écrivons ici index point HTML. Vous voyez, ici, nous n'avons que les commits surlignés. Enfin, nous avons un changement par lequel nous pouvons rechercher des fonctions ou des variables. Maintenant, si nous sélectionnons une commande sur le côté droit, nous pouvons voir plus de détails sur ce commit. En haut, nous obtenons la référence de validation. Ici, nous obtenons notre nom, heure et aussi notre message de validation. Maintenant, en bas, nous avons une section pour le fichier modifié, et ici nous obtenons le nombre de fichiers ajoutés, qui est zéro, le nombre de fichiers modifiés, qui est un, et le nombre de fichiers supprimés, qui est zéro. Et en dessous, nous avons la liste des fichiers ajoutés, modifiés ou supprimés. Si nous sélectionnons ce fichier, nous pouvons voir la différence que nous faisons dans ce fichier. Très utile Maintenant, après les graphes de validation, nous avons plus d'options. Mais comme nous pouvons le constater, il y a beaucoup de choses que nous ne pouvons pas voir ici, et c'est pourquoi les commandes Git sont essentielles à apprendre. C'est à vous de décider ce que vous voulez apprendre. À mon humble avis, apprendre les deux est plus bénéfique pour vous. Laissez-moi vous montrer comment parcourir l'historique à l'aide de l'application Git Kraken Nous ouvrons notre dossier de projets, que nous voulons ouvrir. Cliquez simplement avec le bouton droit de la souris ici et ouvrez-le avec Git Kraken Voici l'interface de l'application Git Kraken. Elle est très similaire à l'extension Git lens. Ici, nous obtenons la liste des validations que nous avons effectuées en haut, nous avons également des options de recherche dans lesquelles nous pouvons effectuer une recherche par message de validation. Ici, nous pouvons également filtrer les validations des auteurs. Maintenant que nous sélectionnons le commit, nous obtenons les détails du commit sur le côté droit. Ici, nous obtenons la référence de validation, message de validation, l'auteur, la date et l'heure, ainsi que les fichiers modifiés. Si nous sélectionnons Fichier, nous obtenons ici les modifications. Nous pouvons également modifier le type de vue en mode fractionné. En haut, on peut également reprocher de voir l'auteur du commit. Sur le côté droit, nous avons également une arborescence de dossiers, et nous pouvons également afficher tous nos fichiers de projets. Vous pouvez donc voir qu'en utilisant l'application Kraken, nous pouvons facilement parcourir notre historique Nous utilisons l'objectif Git, alors nous n'avons pas beaucoup d'espace. Il y a beaucoup de monde. Donc, utilisez ce que vous voulez, c'est à vous de décider. Maintenant, dans la section suivante, nous allons voir le sujet le plus important de git , à savoir les branches. Rendez-vous dans la section suivante. 42. Section 04 Travailler avec les succursales: Bienvenue dans la quatrième section du cours Git ultime. Dans cette section, nous allons tout apprendre sur les branches, comment créer des branches, les visualiser, les comparer aux branches, comment les fusionner, résoudre les conflits et bien d'autres choses encore. C'est l'un des sujets les plus importants de Git. Je sais que cela vous enthousiasme, alors commençons cette section. 43. Qu'est-ce que Branch: Maintenant, comme nous le savons, notre projet de suivi des tâches est le STMLNCSSPject, j'ai créé pour pratiquer Git Imaginez maintenant que nous ajoutons une nouvelle fonctionnalité. Par exemple, la fonctionnalité glisser-déplacer dans ce projet. Ainsi, au lieu d'ajouter cette fonctionnalité dans notre branche principale, nous pouvons créer une nouvelle branche. La branche Git est comme une nouvelle ligne dans nos mets. Donc, comme nous le savons, lorsque nous validons notre code, nous donnons à Master Pointer notre dernier commit. Maintenant que nous décidons d' ajouter une nouvelle fonctionnalité à notre projet, nous créons d'abord une nouvelle branche, disons une fonction glisser-déposer ou une fonctionnalité DND Maintenant, cette branche possède le même instantané de notre code. Ici, nous pouvons valider notre nouveau code de fonctionnalité et lorsque nous validons, ce code n' affectera pas notre code de branche principal. Nous pouvons travailler sur notre code de manière isolée. Vous pouvez maintenant vous demander pourquoi nous avons besoin de créer des branches. Pouvons-nous même envoyer notre code à la branche principale ? Non, nous ne pouvons pas le faire car si nous écrivons du code , ce n'est pas le problème. Mais si nous avons modifié notre code, nous ne voulons pas le stocker dans l'historique de notre code Si nous créons une branche et que nous avons modifié notre code, nous pouvons simplement supprimer complètement cette branche et cela n' affectera pas notre branche principale C'est l'idée. Vous vous demandez peut-être comment Git sait sur quelle branche ou quelle couche nous travaillons ? Pour cela, Git dispose d'un autre pointeur appelé head. Nous avons déjà vu ce pointeur. Par défaut, notre pointeur principal est associé au pointeur principal ou au pointeur principal. Si vous travaillez sur une autre branche, Git ne déplace le pointeur principal que sur le commit de cette branche. C'est ainsi que fonctionnent les branches Git. Par souci de simplicité, n'oubliez pas que si vous voulez travailler sur quelque chose de différent, vous pouvez le faire de manière isolée en créant des branches. Dans les grandes entreprises, de nombreuses équipes travaillent sur différentes branches, leur code ne posera donc problème avec la branche principale, et nous obtenons un code stable dans notre historique. 44. Créer une nouvelle succursale: Maintenant, pour pratiquer les branches, nous allons utiliser notre projet précédent, qui est le cours Task Track. Si vous commencez par cette section, vous pouvez obtenir ce dossier de projet Task Track dans les ressources de cette vidéo. Dans ce projet, nous travaillerons de manière imaginaire sur la fonctionnalité Dragon Drop. Pour cela, nous allons créer notre première nouvelle agence. La création de la branche dans Git est très simple. Il suffit d'écrire la fonctionnalité de branche Git slash DND, qui signifie Dragon Ici, vous pouvez utiliser n'importe quel nom. J'utilise les fonctionnalités du DND pour indiquer que nous travaillons sur une autre fonctionnalité, et non sur la correction des bogues C'est à vous de décider comment vous voulez l'appeler. J'ai trouvé ce style plus utile, donc je l'utilise. Maintenant, pour voir les branches, nous pouvons écrire, fermer , brancher et jeter un coup d'œil. Ici, nous n'avons que deux branches dotées d'une barre oblique DND et notre branche par défaut, qui est master Actuellement, nous sommes sur la branche master, et c'est pourquoi nous avons une étoile avant une branche master. Et nous pouvons également voir ici le nom de la branche actuelle. Maintenant, pour travailler sur la branche du MDN, nous devons d' abord passer à cette branche du MDN. Au tout début, pour changer de branche, nous devons utiliser la commande Git checkout. Mais comme cette commande est un peu confuse, introduisez une nouvelle commande spécifique pour changer de branche, qui est Git switch. Ici, nous écrivons le nom de notre branche, qui est feature slash DND Voyez ici notre marque Lovely qui a changé. Maintenant, ouvrons ce projet dans le code VS en utilisant le point de code. Maintenant, supposons que nous prédisions avoir ajouté une fonction glisser-dessiner. Pour démontrer, j'ouvre ce dossier JS et dans ce script point le fichier JS. Et en haut, j'ajoute commande en utilisant Control Slash ou Command Slash, en ajoutant la fonction ag et draw En bas, dans le journal des points de la console, il s'agit de la fonction glisser-déposer. Enregistrez ce fichier et voyez ici les modifications. Maintenant que nous pouvons le prévoir, nous terminons ici l'implémentation de notre fonctionnalité Dragonrop. Nous pouvons ajouter ces modifications à la zone de transit à l'aide de Git add period. Ensuite, Git comt et message implémentent la fonctionnalité Dragon Drop voyez, ici, nous avons un fichier modifié et deux insertions. Sympa. Voyons maintenant les commits. Obtenez le journal, une ligne. C, en haut, nous avons des fonctionnalités slash DND commit et notre pointeur se trouve actuellement sur la branche features Je tiens donc à préciser une chose : les modifications que nous avons apportées dans cette branche ne seront visibles que dans cette branche. Si nous revenons à la branche master avec kit switch master, voyez, nous avons ici l'ancienne version de notre code. Maintenant, si nous enregistrons nos validations, nous n'aurons pas accès à la fonctionnalité Slush D and D coat car elle représente un pas en avant par rapport à notre maîtresse Kate Si vous voulez voir toutes les branches, nous devons écrire ici : gate, log, d tiret, one line, d tiret all. Tu vois, nous avons ici la succursale. À l'avenir, nous terminerons avec succès implémentation de cette fonctionnalité et nous souhaitons ajouter ce code à notre branche principale. Nous pouvons fusionner ce code dans la branche principale. Nous verrons cela dans les prochaines leçons. Mais après avoir fusionné notre branche avec la branche principale, nous devons supprimer notre branche Pour la suppression, nous écrivons la branche Git D, ici nous écrivons le nom de notre branche, les fonctionnalités D et D. Maintenant, cela nous donnera une erreur ou nous pouvons dire un avertissement, c' est-à-dire que cette branche n'est pas complètement fusionnée parce que nous n'avons pas fusionné cette branche avec la branche master. Maintenant, si vous voulez sûrement supprimer cette branche, nous pouvons écrire la même commande avec la majuscule D. Actuellement, je ne supprime pas cette branche car dans les prochaines leçons, je vais vous montrer comment travailler avec la branche et la fusionner. J'espère que vous comprenez Branches. En termes simples, les branches get aident les développeurs à travailler de manière isolée. 45. Voir les changements entre les branches: Parfois, dans le cadre de notre projet, nous ne pouvons pas vraiment nous souvenir de ce que nous changeons dans notre succursale, en particulier lorsque nous prenons une pause de deux ou trois jours. Alors, comment pouvons-nous voir la liste des Komats que nous exécutons après notre branche principale ? Pour cela, nous utilisons kit, log, master, point point. Ici, nous écrivons le nom de notre branche, qui est feature slash DND voyez, ici nous n'en avons qu' une , comme nous l'avons fait dans la dernière leçon. Si nous avons effectué plusieurs validations, nous obtenons également toutes ces validations ici. Si nous voulons ne voir que le message de validation, nous pouvons bien sûr utiliser un tiret d'une ligne. Maintenant, vous vous demandez peut-être, et si je voulais voir les modifications réelles que nous avons apportées entre notre code de branche principal et le code de branche du DND Vous souvenez-vous de la commande que nous utilisons pour faire la différence entre deux validations Nous utilisons la commande Diff pour cela. Nous écrivons Git, Dave, master, point, point, qui sont des barres obliques D et D. Par cette commande, nous voyons la différence entre ces deux branches voyez, ici, nous avons modifié notre fichier JS à un point de script, qui se trouve dans le dossier JS, et nous pouvons voir que ces deux lignes sont ajoutées. Tiens, j'ai un petit raccourci pour toi. Si nous travaillons sur l'une de ces branches, ne pouvons écrire que l'autre référence de commit ou le nom de branche. En termes simples, nous voici actuellement sur la branche principale. Nous pouvons simplement écrire ici comme ceci, Kate D et nous écrivons directement le nom de notre branche avec laquelle nous voulons comparer. Fonctionnalités slash D et D. Vous voyez, ici, nous voyons la différence Maintenant, vous pourriez dire que ces deux sorties sont différentes et c'est vrai. Le fait est que nous comparons la branche principale à notre fonctionnalité, branche Slash DND, et c'est pourquoi ces deux lignes sont Maintenant, dans le système de raccourcis, nous comparons la fonctionnalité, branche DND avec notre branche principale, et c'est pourquoi nous obtenons ici une suppression de deux lignes Mais cela n'a pas d'importance car nous voulons simplement voir la différence. Parfois, nous voulons voir uniquement les fichiers qui ont été modifiés. Donc, pour cela, nous pouvons écrire Get did name uniquement, ou nous pouvons utiliser n status, et nous écrivons notre branche DND des fonctionnalités voyez, ici, nous ne changeons un seul fichier qui est un fichier script point JS. Donc, si nous fusionnons cette branche DND avec notre branche principale, notre seul fichier sera modifié Nous utilisons uniquement l'option «   Dash » de votre nom, puis nous n'obtenons que les noms de fichiers. Mais lorsque nous utilisons le statut du tiret de nom, nous obtenons les noms des fichiers avec leur statut de modification, d'insertion ou de suppression. Dans la prochaine leçon, nous allons voir sassing git. 46. Stacking maître: Maintenant, avant de commencer à apprendre à planquer, permettez-moi de vous donner une condition. Imaginez que vous travaillez sur projet important et que vous êtes à la moitié de votre code. Maintenant, tout à coup, votre manager vient vous voir et vous demande de corriger le bogue de la fonctionnalité Dragon Drop dès maintenant. Maintenant, dans cette situation, que vas-tu faire ? Une option est que vous pouvez valider les modifications que vous avez apportées, puis travailler sur la fonctionnalité Dragon Drop. Mais comme je te l'ai dit, tu as atteint la moitié de ton code. Vous ne pouvez pas valider ce code. Cela n'a pas l'air professionnel. Maintenant, quelle est la solution à cette situation ? À ce moment-là, nous pouvons enregistrer nos modifications actuelles dans le coin de la porte et lorsque nous aurons terminé notre autre tâche, nous pourrons revenir à ces modifications. De cette façon, notre demi-code ne restera pas entre virgules et nous ne perdrons pas non plus notre demi-code Ce processus par lequel nous stockons notre demi-code dans coin s'appelle atsing, ce qui signifie le cacher quelque part Pour afficher le demi-code, j'ajoute dans le script point jslecs point log C'est un demi-code. Je ne veux pas perdre. Enregistrez les modifications, et si nous vérifions notre statut actuel, nous obtenons ici une modification, et si nous essayons de passer à la branche Features DND, nous obtenons le message d'erreur indiquant que vos modifications locales apportées aux fichiers suivants seront remplacées lors aux fichiers suivants seront remplacées Veuillez valider vos modifications ou les mettre en place avant de changer de branche. En gros, cela signifie que si nous ne validons pas ou n'organisons les modifications et que nous essayons de passer à une autre branche, nous perdrons ces modifications. Donc, pour cacher le code, nous écrivons Git push A, et ici nous écrivons notre message de stress pour le résumé Disons que nous travaillons sur des modifications de la conception du site Web. Vous voyez, nous obtenons un répertoire de travail et un index enregistrés sur Master. Nous voulons maintenant voir toutes les réserves que nous avons créées dans le cadre de notre projet. Ensuite, nous écrivons la liste des statistiques Git. voyez, ici, nous avons le S, la marque rouge entre crochets , zéro sur la branche Master et notre message SS. Maintenant, voici une chose. Cette commande git stash push n'ajoutera pas de fichier non suivi dans les escaliers Par exemple, ici, dans le dossier JS, je crée un nouveau fichier appelé tamp point js Et dans ce fichier, j'ajoute un fichier temporaire de commande. Sauvegardez ceci. Et si nous écrivons Git status, nous obtenons ici le fichier JS temporaire sous forme de fichier non suivi Donc, si nous exécutons ici Git push, Git n'ajoutera pas ce fichier dans notre cache par défaut Donc pour cela, nous devons écrire ici, ou nous pouvons écrire A, puis pour le message de réserve Ici, nous pouvons également les combiner, puis nous écrivons notre message de réserve, qui ajoute un fichier temporaire Maintenant, si nous lançons à nouveau git stash list, nous arrivons à stash Découvrez ici notre premier tiret, passez aux statistiques aérer un, et notre dernier tiret ajouté à stats aerate zéro. Ici, nous avons réussi à annuler nos modifications actuelles. Nous pouvons maintenant passer à la branche feature DND en utilisant le commutateur Git, la branche features DND. voyez, ici, nous obtenons le nom de la branche actuelle, et dans notre éditeur de code, notre fichier de script est également remplacé par la version DND des fonctionnalités N'oubliez pas que nous modifions cette ligne de console. Maintenant, imaginez que nous achevions notre travail sur cette branche, afin que nous puissions à nouveau passer à la branche principale. Nous voulons maintenant obtenir les modifications que nous avons ajoutées dans la réserve Maintenant, avant d'ajouter ces modifications, nous voulons voir quelles sont ces modifications. Donc, pour voir les changements, nous écrivons Git show, et ici nous écrivons le nom de notre réserve qui est itéré entre crochets Ci, zéro Maintenant, si vous ne voulez pas écrire ce nom bizarre, nous ne pouvons écrire que ce chiffre zéro. Vous voyez ici, nous n'obtenons rien car dans ces statistiques, nous n'avons ajouté que untrackfle temp Par défaut, le fichier de suivi n'est pas affiché dans cette commande. Donc, pour voir également UntrackFle, nous devons ajouter ici U. Vous voyez, nous avons maintenant le fichier Temp point js Si vous souhaitez appliquer ces modifications dans notre répertoire de travail local, nous pouvons écrire Git apply zero. voyez, maintenant nous obtenons le fichier de suivi et nous pouvons également le vérifier dans notre éditeur de code. Bien. Maintenant que nous appliquons ces modifications dans notre répertoire de travail, nous n'avons plus besoin de ce zéro. Nous pouvons donc supprimer la réserve et nous ne voulons pas en accumuler trop dans notre projet C'est une très bonne pratique de retirer les réserves dont nous n'avons plus besoin. Nous pouvons écrire Gates drop zero. Maintenant, si nous voyons la liste des staches, c' que nous n'obtenons pas la cachette Maintenant, appliquons simplement cette réserve à notre répertoire de travail. Nous écrivons Git, appliquons, et ce que nous écrivons ici, nous l'écrivons. Nous écrivons ici à nouveau, zéro parce que nous supprimons le premier zéro et que nous marquons notre chiffre de un à zéro. Vous voyez, nous avons deux modifications dans notre projet, l'une dans le fichier script et l'autre dans le fichier de piste. Supprimons également ce stress. Nous pouvons donc le réécrire drop, zero. Ou nous pouvons également l'utiliser clairement. Cette commande supprimera toute stase de notre projet. Tu vois, toutes les stases ont disparu maintenant. 47. Comprendre la fusion dans Git: Maintenant, imaginez que nous en avons terminé avec notre fonction glisser-déposer Nous voulons donc fusionner ce code avec notre branche principale. Mais avant de faire quoi que ce soit, nous devons d' abord vérifier la branche actuelle. Tu vois, nous sommes sur la branche principale. Nous devons donc d'abord passer à la branche feature slash DND. Mais ici, nous avons quelques changements dans notre répertoire de travail, et c'est pourquoi cela nous a valu de changer de répertoire. Mais ici, nous ne voulons pas ces modifications Nous pouvons donc passer de force à notre branche DND feature slash Pour cela, nous devons écrire gate, switch, four, feature slash DND branch. Vérifiez votre code avant d'exécuter cette commande dans vos projets, car vous perdrez définitivement vos modifications. Maintenant, dans notre fichier scrap point js ici dans la console, j'écris « terminé avec la fonction glisser-déposer » et supprime également cette commande par le haut. Supprimons cette console. Ce fichier et supprimez également ce fichier de tampons pour chiens. n'est pas ce que nous voulons. Revenons maintenant au terminal. Ici, nous procédons d'abord à la mise en œuvre de nos modifications. Et puis nous pouvons simplement Git Cate M, fonctionnalité complète, glisser-déposer. Bien. Nous voulons maintenant fusionner notre branche DND de fonctionnalités avec notre branche principale Il existe donc deux types de fusion dans Git. Le premier est rapide pour la fusion et le second est la fusion à trois voies Voyons chaque type de fusion avec un exemple simple. Tout d'abord, nous verrons le rapide de notre fusion. Nous avons donc ici plusieurs amides, puis nous créons une nouvelle branche appelée feature D&D. Maintenant, une nouvelle branche appelée feature D&D. dans cette branche, nous avons créé plusieurs comètes À ce stade de l'aide, nous en avons terminé avec notre fonctionnalité et nous décidons de fusionner notre branche de fonctionnalité avec la branche principale. À ce moment-là, nous pouvons directement fusionner ces deux branches sans nous soucier de quoi que ce soit. Nous avons appelé cette fusion une guerre rapide contre la fusion. Voyons maintenant la fusion à trois voies. Auparavant, après avoir créé la branche, nous n'avions rien validé dans notre branche principale. Mais dans le monde réel, cela s'est produit très rarement car, comme nous le savons, de nombreux développeurs travaillent sur une seule application. Il existe une possibilité dans laquelle d'autres développeurs s'engagent dans la branche master. À cette époque, nos succursales se diversifient. Nous avons donc quelques modifications dans la branche master que nous n'avons pas dans nos fonctionnalités S, D et D. Maintenant, si nous exécutons merge ici, Git ne déplace pas notre master vers le commit DND feature slash car cela supprimera les modifications de la branche principale Ainsi, lorsque nous exécutons la commande here merge, Git crée un nouveau commit qui combine les modifications apportées par ces deux branches. Vous vous demandez peut-être pourquoi nous appelons cette fusion une fusion à trois voies , car elle dépend des trois validations. Le premier est le point commun de deux branches. deuxième est la dernière atteinte dans la branche principale, appelée pointe de la branche principale, et la troisième est la pointe de la branche DND avec barre oblique fonctionnelle Regardez ces trois comètes et fusionnez notre code en fonction du fait que cette nouvelle comète créée par la démarche s' appelle merge Pour récapituler, il existe deux types de fusion. La première est la page pour ou la fusion si nos branches ne divergent pas ou nous pouvons dire que nous n'avons pas ajouté de nouvelle comète dans notre branche principale après avoir créé une nouvelle branche La deuxième est la fusion à trois voies si nos branches divergent ou si nous pouvons dire que nous avons effectué un nouveau commit dans la branche principale après avoir créé la Dans les prochaines leçons, nous verrons les deux fusionner. Ne vous inquiétez pas, c' est très simple. 48. Appliquer la fusion rapide: Voyons maintenant le rapide de notre fusion. Pour résumer rapidement la fusion, nous avons un chemin de validation linéaire et get déplace directement le pointeur principal vers nos fonctionnalités Voyons comment nous pouvons le faire. Tout d'abord, nous allons enregistrer tous nos codes, et comme nous le savons, si vous voulez voir les branches, nous devons les utiliser log, tiret une ligne, tiret tout. Et lorsque nous travaillons avec des branches, nous pouvons écrire ici l'option Dash Graph. Je recommande vivement d' utiliser cette option graphique car elle nous montrera que nous avons ou non diverses comètes De plus, vous n'avez pas besoin d' écrire cette longue commande à chaque fois. Vous pouvez utiliser comme pour cela. heure actuelle, nous n'avons pas comètes diverses et c'est pourquoi nous ne pouvons pas voir de graphes variés, mais cela ressemble à ceci Maintenant, nous pouvons voir que nous sommes actuellement dans la branche principale du DND parce que notre pointeur principal se trouve ici Maintenant, pour fusionner cette branche DND fonctionnelle dans notre branche principale, nous devons d'abord passer à la branche principale Bien. Nous pouvons maintenant voir notre pointeur principal est déplacé vers la branche principale. Maintenant, pour fusionner ces branches, nous écrivons git merge, puis nous écrivons le nom de notre branche, que nous voulons fusionner dans la branche master. Tu vois, on passe vite à la fusion. Maintenant, nous pouvons à nouveau voir toutes les comètes à l'aide de notre commande précédente Ici, nous n'avons pas nouvelle comète, il suffit de déplacer le pointeur principal vers la branche SS DND parce que nous avons comètes linéaires ou nous pouvons dire que nous n' avons pas d'amides divers Et si parfois nous ne voulions pas appliquer la fusion rapide. C'est totalement bon. Dans git, nous pouvons également appliquer une fusion non rapide, et nous le verrons dans la prochaine leçon. 49. Fusion avancée non rapide: Maintenant, laissez-moi vous montrer comment éviter une fusion rapide Donc, pour démontrer, nous devons créer une nouvelle branche, puis passer à cette branche. Il s'agit donc de deux étapes différentes. Permettez-moi de vous montrer le raccourci pour effectuer ces deux étapes en une seule étape. Nous pouvons donc écrire le commutateur de porte C pour créer ici nous écrivons le nom de notre branche. Disons que Feedback sur les fonctionnalités. Vous voyez, nous passons directement à la branche des commentaires. Revenons maintenant au code VS, et ici j'ouvre le point d' index STMLFle Si vous vous demandez comment j' ouvre le fichier, appuyez simplement sur Ctrl plus P ou Commande plus P et écrivez le nom du fichier ici. Maintenant, en bas, après notre balise principale, j'ajoute un commentaire pour le formulaire de commentaires. Imaginons que nous ajoutions ici un formulaire de commentaires, enregistrions les modifications et que nous revenions à notre Git Bash. Ici, nous procédons d'abord à l'étape de toutes les modifications, puis les validons sous forme de message de validation à l'aide de la fonction de feedback. Bien. Maintenant, examinons l'historique de nos commentaires. Tu vois, nous avons ici notre dernier commit. Fusionnons maintenant cette branche de feedback avec notre branche principale en procédant à une fusion non accélérée Ce que nous allons faire avant de fusionner, nous revenons à la branche principale Maintenant, nous écrivons Gate, merge, Ff pour ne pas avancer rapidement et écrivons simplement ici le nom de notre branche, qui est Feature Slash Feedback Par cette commande, nous disons à Git que s'il est possible d'avancer rapidement dans cette fusion, ne le faites toujours pas et créez une nouvelle commande combinant deux branches. La différence entre une fusion rapide et une fusion non rapide réside dans la fusion rapide, git ne crée pas de nouveau commit, mais dans la fusion non rapide, Git crée une nouvelle mais dans la fusion non rapide, Git crée Maintenant, au moment où nous appuyons sur Entrée ici, Git demande un message de validation de fusion. Par défaut, nous obtenons ici ce message de validation généré par git. Si nous voulons le modifier, nous pouvons le modifier ici. Enregistrez le fichier et fermez-le. Maintenant, dans notre terminal, nous pouvons voir la fusion effectuée. Et si nous voyons l'historique avec l'option graph, voyez, ici nous obtenons le graphique de nos validations. Nous pouvons voir notre pointeur principal, mais notre branche de feedback sur les fonctionnalités est toujours là, et Git crée une commande de fusion qui combine les modifications de feedback sur les fonctionnalités avec la branche master Et nous obtenons ce graphique parce que nous ajoutons l'option graph dans notre commande log. Maintenant, vous pourriez vous demander quelle est la meilleure chose à faire pour fusionner ? Fusion rapide ou nous devrions utiliser une fonction non rapide pour ou une fusion. Voyons les avantages et les inconvénients de ces deux fusions. Tout d'abord, lorsque nous utilisons fast pour fusionner, nous pouvons voir notre histoire très clairement car il n'y a pas de divergence entre les comètes Mais si nous utilisons non fast pour la fusion, notre historique peut sembler un peu confus heure actuelle, nous pouvons le constater parce que nous n'avons qu'une seule divergence. Mais dans le monde réel, les grands projets n'ont pas qu'une seule branche. Sont de multiples branches et de nombreuses branches diverses. C'est pourquoi le mode rapide de fusion ne prête pas à confusion, ce qui signifie également que le mode rapide de fusion offre plus de clarté visuelle et, d'autre part, nous avons moins de clarté visuelle à propos de nos comètes Maintenant, une autre chose est que si nous utilisons la fusion rapide, nous pouvons ignorer certains contextes comme lorsque des modifications spécifiques sont intégrées. Mais si nous utilisons non fast pour la fusion, nous ne perdons aucun contexte. À chaque fusion de comètes, nous avons des informations sur le moment et l'endroit où nous apportons des modifications Ensuite, dans Fast Per Merging, nous ne pouvons plus isoler le code de nos deux branches Mais si la fusion n'est pas rapide, nous pouvons isoler le code de nos deux branches car nous avons des gommes de fusion distinctes Voici les avantages et les inconvénients de ces deux fusions. À mon avis, ces deux options ont des avantages et des inconvénients. Vous travaillez en tant qu'individu, vous pouvez sélectionner le type de fusion de votre choix. Cela dépend entièrement de vous. Mais souvent, votre équipe vous demandera d'utiliser la fusion rapide ou non. Maintenant, lorsque nous sommes en train de travailler, se peut que nous ayons oublié de n'utiliser aucune option d'avance rapide, et votre entreprise vous demande de n' utiliser que l'option non rapide. La solution à cette situation est donc que nous pouvons définir option de transfert non rapide pour notre référentiel actuel, ou nous pouvons également la définir pour tout le référentiel informatique de notre système. Pour cela, nous pouvons l' écrire config, FF, no. Cette commande désactivera transfert rapide dans notre dépôt actuel. De plus, si nous voulons désactiver le transfert rapide pour tous les référentiels , nous pouvons simplement ajouter dads Global 50. Comprendre la fusion à 3 voies: Voyons maintenant la fusion à trois voies. Comme nous le savons, si nous créons une nouvelle branche, effectuons un commit sur cette branche, puis que nous validons également sur notre branche principale, nous pouvons appeler ces deux branches ou diverger l'une de l'autre Maintenant, dans cette situation, regardez les deux extrémités de ces branches et regardez également la comète commune par laquelle ces deux branches divergent Il trouve le meilleur moyen de combiner ces deux branches et d'appliquer ces changements à la nouvelle comète. Pour le démontrer, nous créons à nouveau une nouvelle branche. En utilisant le commutateur C pour Create, puis nous donnons à notre nom la fonction Slash user Register Revenons maintenant au code VS. Ici, dans le dossier du projet, nous créons un nouveau dossier appelé registre des utilisateurs. Et dans ce dossier, nous créons un nouveau fichier appelé register form point SGML Et à l'intérieur de celui-ci, j'ajoute rapidement extrait de code HTML et je change le titre du registre en tant que nouvel utilisateur Enregistrez ce fichier et retournez sur notre terminal. Ici, nous enregistrons d'abord toutes les modifications , puis nous les validons également sur notre branche de registre des utilisateurs. Bien. Regardons notre historique en utilisant Git log, dash one line, dash all, Des dash graph. Tu vois, nous avons ici notre nouvelle succursale. Revenons maintenant à la branche principale. Dans le fichier script point js, nous ajoutons ici la ligne de journal point de la console, et ici nous apprenons à la console la fusion tridirectionnelle Enregistrez le fichier, et dans le Git Bash, nous organisons d'abord nos modifications, puis nous les validons simplement Git, mettez à jour le fichier script point js pour une fusion à trois voies. Bien. Revoyons maintenant l'histoire. Ici, nous pouvons voir la divergence entre nos branches. Si nous travaillons sur cette branche, nous pouvons directement nous rendre ici sur la branche principale. C'est ce qu'on appelle une branche divergente. Fusionnons maintenant ces deux branches. Voici une bonne nouvelle pour vous. Nous n'avons pas de commande séparée pour la fusion à trois voies. C'est la même commande que nous utilisons pour la fusion rapide Si nous avons des branches divergentes, ce qui signifie que nous sommes entrées dans la branche principale après avoir créé une nouvelle branche, appliquez automatiquement la fusion tridirectionnelle Quelle est la commande de fusion ? vrai, git merge, et ici nous ajoutons une fonctionnalité slash user et appuyer sur Tab Il exécutera automatiquement la commande. Ici, demandez le message de validation de la fusion. Je le laisse tel quel, ferme ce fichier et vois ici nos branches fusionnées. Et si nous voyons notre graphique historique, nous pouvons voir ici que nous avons notre comète ramifiée, et ici nous avons Amid, ce que nous avons fait sur notre branche principale, et Gate a fusionné ces deux comètes dans ce commit de fusion séparé C'est ainsi que fonctionne la fusion à trois voies. Vous pourriez vous demander que la fusion à trois voies et la fusion rapide sont les mêmes, et je me suis posé la même question lorsque j'ai appris à fusionner à Gait La réponse est non. Ils ne sont pas les mêmes. Ils peuvent se ressembler, mais ils ne sont pas identiques les uns aux autres. La différence est que lors de la fusion, nous avons des comètes linéaires et que nous voulons tout de même combiner des branches dans les nouvelles comètes de fusion C'est ce que l'on appelle une fusion avancée non rapide. Mais dans le cas d'une fusion à trois voies, nous avons toujours des comètes divergentes, obtenons automatiquement des branches combinées dans la nouvelle C'est la différence entre une fusion non rapide et une fusion à trois voies Dans la leçon suivante, nous verrons comment supprimer la branche de fusion de notre référentiel ? 51. Effacer la branche après la fusion: Je sais que lorsque nous travaillons avec des branches dans le git, si nous finissons de travailler sur une branche et que nous les fusionnons dans le master, nous n'avons pas besoin de cette branche. Cela créera de la confusion pour nous et pour les membres de notre équipe également. Voyons quelles sont les branches que nous avons créées en utilisant la branche git. voyez, ici nous avons quatre branches, et maintenant je veux savoir quelles branches nous fusionnons dans notre branche actuelle, qui est master. Nous écrivons git branch, dash merge. voyez, nous obtenons ici la liste des commits qui sont entièrement fusionnés dans notre branche master actuelle. Ici, nous obtenons toutes les branches car nous fusionnons toutes ces branches dans notre branche principale. Nous pouvons maintenant supprimer les branches en utilisant la branche Git, D, et nous écrivons le nom de notre branche, disons feature D&D. Maintenant, si nous voyons l'historique de nos noms, c'est que la fonctionnalité DND a été supprimée de Voici l'histoire de l'avant et de l'après. Tu vois, il suffit de retirer la branche d'ici. Le milieu y restera tel quel. Actuellement, je ne supprime pas ces autres branches car j'en aurai besoin à l'avenir. Maintenant, permettez-moi de vous donner un bonus. Au lieu de regarder les branches qui sont fusionnées, il est facile de voir directement les branches qui ne le sont pas, afin que nous puissions les fusionner à l'avenir. Nous ne devons pas oublier de ne pas abandonner cette branche par erreur. Pour cela, nous écrivons git branch, no, d merged. Vous voyez ici, nous n'obtenons aucune branche car nous fusionnons toutes les branches dans notre branche master actuel. Dans la leçon suivante, nous verrons comment résoudre un conflit dans git. 52. Comment résoudre les conflits dans Git: Avant de commencer cette leçon, je voudrais vous poser une question simple. Imaginons que nous ayons deux branches. L'un est le master, et le second est la fonctionnalité Slash Login. Imaginons maintenant que nous modifiions le fichier SM à points d'index dans notre branche principale et que nous validions les modifications. Et également dans la branche de connexion aux fonctionnalités, nous changeons quelque chose dans le point d'index STMLFle En bref, dans ces deux branches, fichier SML à points d' index est différent Dans ce cas, si nous fusionnons ces deux branches, Git confond les modifications apporter et celles à éviter. C'est ce que l'on appelle des conflits dans Git. Ainsi, lorsque nous modifions le même fichier dans différentes branches, Git peut automatiquement fusionner ces deux branches, cela s'appelle un conflit. Vous pouvez maintenant vous demander quelles sont les solutions possibles en cas de conflit. Le premier est donc le changement. Nous modifions la même ligne de notre fichier dans les deux branches. Ensuite, dans une branche, nous supprimons un fichier, et dans l'autre, nous modifions ce même fichier. Des conflits se produisent également. De plus, nous renommons le nom du fichier dans une branche et le même fichier dans l'autre branche De plus, nous ajoutons le fichier un point TXT dans la première branche, et nous ajoutons également le fichier un point TXT dans la deuxième branche, mais le contenu du fichier est différent de celui des conflits. Ce sont les situations courantes dans lesquelles un conflit peut survenir. Maintenant, vous vous demandez peut-être ce qu'il va faire dans cette situation ? Et quelle est la solution pour résoudre le conflit ? Simply git nous demandera et nous donnera des options sur les modifications que nous voulons apporter. Cela n'interférera pas dans le conflit. Il nous demandera simplement ce que nous voulons faire dans cette situation. Laissez-moi vous le montrer de façon pratique. Pour démontrer le conflit, nous devons d'abord créer un conflit. Écrivons Gate switch C, feature login et ce que cette commande écrit. Il créera une branche de connexion aux fonctionnalités et passera également à cette branche. Maintenant, permettez-moi de modifier le fichier ScrapTGS. La deuxième ligne, que j'écris ici, console point log, console pour les fonctionnalités, branche de connexion slash Enregistrez ce fichier, et laissez-moi organiser les modifications et également les valider avec un message de validation, modifier le fichier script point js pour la connexion aux fonctionnalités. Terminé. Passons maintenant à la branche master et également dans le code VS, nous changeons également la deuxième ligne et écrivons ici, Console pour la branche master. Enregistrez ce fichier. Et goûtons aux changements. Et aussi, nous validons avec un message, Modifie le fichier script point js pour le master. Essayons maintenant de fusionner ces deux branches. Nous exécutons donc Gate merge, feature slash login. voyez, ici, nous avons un conflit et une porte indiquant un conflit de fusion dans un fichier script point JS. Et aussi, il est dit que fusion automatique échoue et corrige le conflit, puis le résultat de la validation Ici, nous devons effectuer les modifications manuellement et nous pouvons également voir que nous sommes en train de fusionner Permettez-moi de vous montrer le statut actuel par git status. Vous voyez, nous avons ici un chemin non fusionné. Laisse-moi te montrer quelque chose de cool. Ouvrez le code VS et voyez, ici nous avons changé la ligne surlignée, ce qui provoque un conflit. Ne vous laissez pas embrouiller par cet écran. C'est vraiment simple. voyez, nous obtenons d'abord le pointeur d'en-tête, qui indique la branche actuelle qui est master, et en dessous, nous avons le changement, nous le validons dans la branche master. Ensuite, nous avons une ligne de séparation, puis nous avons la modification que nous avons apportée à la branche feature ss login. Tu vois ? Ici, nous avons quelques options que le code VS nous offre. La première est d'accepter les modifications en cours. Si nous le sélectionnons, il accepte les modifications en cours, il appliquera donc les modifications de la branche actuelle. Nous allons annuler cette opération à l'aide de Control plus set ou de Command plus set. Maintenant, si nous sélectionnons Accepter les modifications entrantes, cela appliquera les modifications de la deuxième branche, et nous pouvons appliquer les deux modifications, et la dernière option consiste à comparer les deux modifications. Il comparera nos fichiers côte à côte. Clôturons donc ce comparatif. Ici, nous avons des options par code VS. Nous pouvons également modifier le fichier manuellement. Supprimons donc cette fonctionnalité, supprimons le pointeur de connexion, supprimons également cette séparation de lignes et supprimons également ce pointeur principal Si nous voulons déplacer ces lignes vers le haut ou vers le bas, nous pouvons également le faire. Mais souvenez-vous toujours que nous n'ajoutons pas nouveau code car le but principal de la fusion est de fusionner le code de deux branches, pas d'ajouter un nouveau code, mais parfois nous devons ajouter de nouvelles modifications. Si cela n'est pas évitable, vous pouvez également le faire. Maintenant que nous avons terminé nos modifications, nous servons le fichier et le renvoyons au terminal. Ici, nous devons d'abord organiser les modifications par git add period. Voyons maintenant notre statut actuel. Vous voyez, nous n'avons pas de chemin non fusionné. Nous pouvons écrire Git commit et nous obtenons le message de validation ici. Je le laisse tel quel, ferme le fichier et vois, nous fusionnons nos deux branches, et l'état de fusion a également disparu 53. Interrompre le conflit dans Merge: Maintenant, parfois, nous exécutons la commande de fusion et cela génère un conflit, mais à ce stade, nous ne voulons pas résoudre ce conflit parce que le conflit se produit par erreur. Donc, au lieu de passer à l'état de fusion, nous utilisons cette commande de fusion Pour cela, je ne vais pas créer une nouvelle branche et créer un conflit. Je vais vous montrer mon enregistrement d'écran précédent avant que nous résolvions notre conflit. Ici, nous exécutons la commande Git merge. Tu vois, nous avons un conflit. Nous ne voulons pas aller plus loin, nous pouvons écrire, créer, fusionner et voir que nous avons pris du recul par rapport à l'état de fusion 54. Réinitialiser la validation de fusion: À l'heure actuelle, lorsque nous fusionnons deux branches et notre code cesse de se garer ou tombe en panne, cela peut arriver parce que nous commettons une erreur lors de la fusion des branches Il existe donc deux solutions à cette situation. Tout d'abord, nous pouvons réinitialiser notre commit de fusion à la version précédente avant la fusion. Et la deuxième option est que nous pouvons annuler notre code de fusion et le valider dans le nouveau fichier at. Ne vous y trompez pas, laissez-moi vous expliquer chaque scénario. Nous voyons donc d'abord la comète Reset Merge. Ici, dans notre Caid, notre pointeur principal se trouve sur notre Merge Met Voici notre pointeur de branche. Maintenant, dans ce commit de fusion, nous avons le problème. Nous pouvons donc réinitialiser notre comète en déplaçant ces deux pointeurs vers le point précédent avant de fusionner En gros, nous réinitialisons la couche de fusion sur la couche précédente Maintenant, vous pouvez vous demander ce qui va se passer avec ce commit de fusion ? Ainsi, au fur et à mesure que nous déplaçons notre pointeur principal et notre pointeur principal vers le point précédent, ce médium devient inutile Après un certain temps, cet amid sera automatiquement supprimé de notre référentiel. Maintenant, comme nous pouvons le voir indirectement, nous modifions ou réécrivons l'historique des validations, et ce n'est acceptable que si nous avons un dépôt localement Mais si de nombreux membres de l'équipe travaillent sur ce projet, nous n' envisageons pas cette option. Dans ce cas, lorsque des membres de l'équipe travaillent sur le même projet, nous devons annuler notre code et le valider dans la nouvelle commande Encore une fois, nous avons l'historique de nos validations. Lorsque nous annulons notre fusion, Git était alors le bout des branches Maintenant, au lieu de déplacer ce pointeur vers la comète précédente, Git prend les modifications par rapport à l'amet précédent, l'annule, puis crée une autre comète qui sera la validation inverse. Nous pouvons voir que ce code de validation précédent est le même que ce code de validation inversé Cette méthode est plus pratique car ici nous ne réécrivons pas notre historique Git Permettez-moi de vous montrer ces deux méthodes une par une. Tout d'abord, nous voyons l'option de réinitialisation. Pour cela, nous écrivons git reset, dash dash hard. Nous écrivons ici avec acharnement. Je vais vous expliquer cela dans une minute. Et ici, nous écrivons notre référence de validation , que nous pouvons appeler head till one. Maintenant, avant d'exécuter cette commande, assurez-vous d'écrire le commit dès cette fusion ammt quelque part dans vos nœuds Maintenant, en gros, cette commande indiquera à Git de déplacer le pointeur principal et le pointeur principal vers le commit précédent. Ici, vous pourriez vous demander quoi sert cette option difficile ? Ainsi, lorsque nous exécutons la commande de réinitialisation, nous avons trois options souple, mixte et difficile. Permettez-moi de vous les expliquer en détail. Nous avons donc ici le code de notre répertoire de travail, le code la zone de transit, et nous avons notre code de validation. Désormais, lorsque nous exécutons la commande de réinitialisation avec l'option logicielle, elle réinitialise uniquement notre code de validation selon le commit spécifique, mais elle ne touche pas le code de répertoire de travail de notre code de zone intermédiaire . Les modifications que nous avons apportées au répertoire de travail et à la zone resteront donc les mêmes que celles que nous avons actuellement. Maintenant, si nous utilisons l'option mixte DSD, qui est l'option par défaut, cela réinitialisera le code de validation et modifiera également le code de zone de transit en fonction de ce commit spécifique Et maintenant, pouvez-vous deviner à quoi sert cette option difficile ? Bien sûr, cela réinitialisera le code de validation, code de zone de transit et également le code du répertoire de travail à la commande spécifique. C'est pourquoi nous utilisons l' option difficile avec la commande de réinitialisation. Exécutons donc cette commande. Vous voyez, nous en sommes arrivés à ce commit et nous pouvons également voir le message de validation. Revoyons notre historique. Vous voyez ici que notre responsable et maître sont déplacés vers le commit précédent sur la branche master, et nous ne voyons pas notre commit de fusion dans cette liste, mais nous pouvons toujours passer à ce commit car Get supprime ce commit immédiatement. Nous écrivons git reset dash had, et ici nous écrivons ce commit de fusion, qui est E sept, E sept, d huit. Vous voyez maintenant que notre tête est déplacée vers le commit de fusion. Nous pouvons voir dans notre histoire que nous obtenons la même fusion avec. Dans la leçon suivante, nous verrons la meilleure façon d' annuler une fusion, c' est-à-dire de revenir en 55. Annuler la validation de fusion: Maintenant, laissez-moi vous montrer la deuxième option pour annuler la fusion, qui consiste à annuler les modifications de fusion Pour cela, nous écrivons git revert, et ici nous écrivons notre commit has, que nous voulons Dans notre cas, il s'agit de ce head commit. Nous écrivons donc ici, dirigeons et appuyons sur Entrée. Vous voyez, ici nous avons une erreur. Commit est une fusion, mais aucune option n'a été donnée. L'annulation échoue. Alors, de quelle option parle Kit ? Voici donc notre commit de fusion. Lorsque nous disons revenir au commit de fusion, Git a deux options abord, G rétablira le commit au dernier commit de la branche master, et nous l'appelons commit en tant que premier parent car nous sommes sur la branche master Maintenant, la deuxième option est revenir à la dernière comète de la branche fonctionnelle, appelée deuxième parent Nous écrivons donc ici git revert M one, qui est le premier parent de notre branche actuelle, qui est master, et quel commit nous voulons annuler, nous voulons annuler le commit Nous voulons annuler les modifications en tant que deuxième commande parent, puis nous pouvons écrire ici M deux, mais c'est rare Remplaçons-le en un et appuyons sur Entrée. Maintenant, demandez le message de commande. Je ne veux pas le modifier, alors je ferme simplement le fichier. Voyons maintenant l'historique. voyez en haut, nous avons un nouveau Commit, qui est le commit inverse de ce commit de fusion C'est ainsi que nous pouvons annuler notre fusion sans réécrire l'historique des validations. Je préfère toujours choisir cette option d'inversion plutôt que de réinitialiser, mais en fin de compte, c'est à vous de choisir. Si votre projet est local, vous pouvez utiliser ce que vous voulez. Mais lorsque vous travaillez en équipe, il est préférable de revenir en arrière. 56. Fusion de squash dans l'historique des engagements: Maintenant, avant d'apprendre le squash merging, qui est une autre technique de fusion, permettez-moi de vous donner une situation Voici donc l'historique de nos validations, et nous avons une branche appelée Fix Bergh Login Dans cette branche, nous corrigeons un bogue dans notre fonctionnalité de connexion. Dans cette branche, nous avons donc quelques commits F un, F deux et F trois. Nous en avons terminé avec la correction du bogue dans le formulaire de connexion. Nous pouvons fusionner ces deux branches. Maintenant, comme nous pouvons le voir, ces F un, F deux et F trois font partie de l'historique de nos validations. Mais pour corriger le bogue, imaginez que nous ayons fait de mauvais commits, comme modifier un peu ce bogue et le valider. Nous en sommes à la moitié de la correction du bogue, et pour les points de contrôle uniquement, nous avons créé ces comètes Dans ce cas, nous ne voulons pas ajouter ce F un, deux et F trois dans notre historique des validations. La solution est donc qu'avant de fusionner nos branches, nous créons un kami de courge, qui est la combinaison de ce F un, F deux et F trois dans une seule comète Ensuite, nous pouvons simplement déplacer notre pointeur principal vers cette comète. Mais n'oubliez pas qu' il ne s'agit pas du point fusionné, car cette comète n'a pas deux parents rencontrés et nous pouvons également voir qu'elle n'est pas connectée à la comète F 3. Comme nous avons ici toutes les modifications apportées à cette branche, nous pouvons supprimer cette branche de notre historique. Maintenant, nous avons une histoire linéaire et nous n'avons pas de mauvais revêtement de branche. C'est l'avantage d' utiliser Squash Merge. Maintenant, vous vous demandez peut-être si nous devons toujours utiliser technique du squash merge ? La réponse est non. Nous n'utiliserons Squash Merge que lorsque les comètes de nos branches sont défectueuses ou si nous ne voulons pas les conserver dans l'historique Par exemple, j'aime utiliser la fusion de squash lorsque je travaille pour corriger de petits bugs ou de très petites fonctionnalités, ce que je peux terminer en une à deux heures Les situations, je n'ai pas besoin de ces points de contrôle. Mais si la fonctionnalité ou le bogue est important, je n'utilise pas Squash Merge et je garde les points de contrôle dans l'historique Voyons maintenant la fusion de squash dans notre projet. Ici, tout d'abord, créons rapidement une nouvelle branche en utilisant le commutateur Git, C Fix Bugs Login. Nous passons au code VS pour le modifier, je supprime ces trois lignes de console et j'adhère au journal des points newconsole Corrigez le bogue de connexion Checkpoint 1. Imaginez que vos heures de bureau soient terminées et que vous souhaitiez corriger le bogue demain. C'est pourquoi CheckPoint One. Enregistrez maintenant ce fichier sur notre terminal, et au lieu de lancer stage et Comet en deux étapes, nous pouvons utiliser le raccourci Git AM et écrire un message de validation, cochons bogue dans la fonction de connexion, point de contrôle 1 Bien. Maintenant, pour le démontrer plus clairement, nous allons faire un autre commit dans cette branche. Dans notre cas, nous venons le lendemain au bureau pour corriger complètement le bogue. Donc vis Cd, et ici nous supprimons le point de contrôle car nous corrigeons complètement le bogue Encore une fois, revenons au terminal, et ici nous écrivons gate com AmfigBug dans la fonction de connexion terminée Bien. Voyons maintenant l'historique. Voyez ici en haut, nous avons deux branches de validation. Mais comme vous pouvez le voir, ça a l'air moche. Qu'est-ce que ce point de contrôle ? Ici, nous appliquons Squash Merge. C'est vraiment simple. En gros, les commandes sont très simples, ce qui fait que cette situation prend plus de temps ici. Mais il est important de vous montrer le véritable exemple. Maintenant, vous vous demandez peut-être nous pouvons faire pression pour une fusion parce que nous n' avons pas de branches divergentes Oui, nous pouvons le faire rapidement pour notre fusion, mais dans ce cas, nous ne voulons pas enregistrer ces deux comètes dans l'historique Nous voulons simplement enregistrer les modifications, et c'est pourquoi nous procédons ici à Squash Merge, qui combinera les modifications de ces comètes à deux branches. Tout d'abord, nous devons passer à notre branche principale. Maintenant, auparavant, nous écrivons pour merge, Git Merge, Fixburg Login Mais pour Squash Merge, nous ajoutons simplement ici les options squash. Ici, nous pouvons voir que nous avons fait du squash Kammit. Et voici la liste des fichiers qui ont changé. Dans notre cas, nous n' avons qu'un seul fichier car nous ne modifions que le fichier script point JS, mais cela n'a pas directement ajouté ce commit dans notre historique. Ces modifications ne concernent que la zone de transit. Laisse-moi te montrer. Nous exécutons Gate status, C, ici nous obtenons le fichier script point js, qui est modifié. Nous pouvons maintenant valider ces modifications, gate commit. Ici, nous écrivons un message de validation de combinaison, qui indique que toutes les modifications se produisent dans cette branche Supposons que nous ayons corrigé un bogue sur la page de connexion en corrigeant le type de données et le point de terminaison dans la demande d'API. Bien. Maintenant, voyons l'historique. voyez, en haut, nous avons une autre comète, mais elle n'est pas liée à la branche de connexion Fix buerg slash Ainsi, lorsque nous supprimons ce correctif dans la branche de connexion de Buurgs, nous obtenons un historique des validations clair et linéaire. Maintenant, vous vous demandez peut-être : et si nous ne supprimons pas cette branche ? Idéalement, nous devrions supprimer la branche après avoir effectué une fusion par squash car cette branche n' est pas déclarée comme branche fusionnée. Laissez-moi vous montrer ce que je veux dire. Si nous écrivons Ket branch, le tiret est fusionné. Ici, nous obtenons la branche de connexion FixBurg en tant que branche non fusionnée. Mais comme nous le savons, nous avons déjà ajouté ce code de branche dans notre historique en utilisant squash merge. Cela créera de la confusion dans notre histoire. Il est donc préférable de supprimer cette branche lorsque nous faisons une fusion de squash. Vous souvenez-vous de la commande que nous allons utiliser pour supprimer la branche ? Ne t'inquiète pas Si vous ne vous en souvenez pas, vous pouvez également utiliser le kit de triche Nous écrivons la branche Git, D, et ici nous écrivons le nom de la branche qui est Fixburg login Ici, nous obtenons une erreur indiquant que les branches ne sont pas complètement fusionnées. Nous devons donc supprimer cette branche avec force. Vous apportez la commande précédente et nous supprimons simplement ce D et ajoutons ici D.C, notre branche a été supprimée avec succès. Maintenant, si nous vérifions l'historique de nos validations, nous sommes effacés de votre historique. Nous utilisons Squash Merge lorsque nous ne voulons pas enregistrer les mauvais commits de nos branches. 57. Comment rétrograder la branche: Alors, qu'est-ce que le rebasage dans Git ? rebasage est une technique utilisée pour remplacer le commit de base de la branche par un autre Laissez-moi vous expliquer à l' aide d'un exemple. Voici l'historique de nos validations et nous travaillons sur la branche appelée features OT. Maintenant, pendant que nous travaillons sur la branche OT, supposons que quelqu'un s'est engagé dans la branche principale. Nous voulons maintenant fusionner ces modifications de branche principale dans notre branche de fonctionnalités sans créer de fusions inutiles Ici, quelle est la solution ? Une solution consiste à fusionner ces deux branches, puis à continuer à travailler dessus. Mais ensuite, nous devons créer également une autre fonctionnalité sans les deux branches. Nous pouvons le faire. Une autre solution consiste à utiliser le rebasage, ce qui signifie essentiellement que nous pouvons modifier la base de notre branche Il s'agit actuellement de la base de notre filiale Oth. Si nous changeons notre base avec ce dernier commit principal, nous pouvons apporter des modifications dans notre branche oth sans fusionner les branches C'est ce qu'est Rebase. Nous modifions simplement le commit de base de notre branche. Maintenant, voici une chose que vous devez garder à l'esprit : cette technique de rebasage réécrire notre Lorsque nous changeons notre base pour un autre amet, Git ne change pas le F one Kamete d'origine Il suffit de prendre ces deux couches et créer la même amette qu'elles, puis les associer à la dernière couche de maître , puis de déplacer ce point de branchement ici Maintenant, comme nous pouvons le voir, ces commandes ne sont pas connectées au F pour valider, supprimeront ce F et F pour valider. C'est pourquoi le rebasage réécrit l'historique des commandes, et c'est pourquoi nous n'appliquerons le rebasage que lorsque nous travaillons localement Sinon, notre histoire deviendra une masse. Maintenant, laissez-moi vous montrer comment nous pouvons effectuer le rebasage. Tout d'abord, nous devons créer une nouvelle branche en utilisant le commutateur Git, la fonctionnalité C OT et revenir au code VS. Ici, nous créons simplement un nouveau fichier dans Jsfolder appelé auth point Et ici, nous nous contentons de points log lors de l'authentification. Enregistrez ce fichier. Maintenant, diminuez ces changements. Et puis validez-le avec un message au point orth Jspile Je sais que ce n'est pas le bon message, mais pour la démo, ça va. Nous avons donc maintenant une branche avec un seul Kat. Regardons notre historique. Ici, nous devons faire un kamite en master pour créer des kamits divergents Donc, tout d'abord, nous allons revenir à la branche master. Ouvrez le code VS et je modifierai le fichier script point js. Ici, je supprime simplement ce message de console, et ici quelques modifications requises pour la branche OT et je l'enregistre. Revenons maintenant au terminal et goûtons aux modifications, bien, et nous les validons également. Git commit M , modifications requises pour OT. Regardons maintenant notre historique. Tu vois, maintenant notre histoire est différente. Si nous ne divergeons pas nos branches, alors Gait, appliquez par défaut une fusion rapide. Nous avons maintenant nos branches divergentes. Dans ce cas, nous avons deux options. Nous pouvons appliquer une fusion à trois voies ou nous pouvons rebaser. À l'heure actuelle, c'est vers cette adresse que nous indiquons notre succursale. Maintenant, en reprenant nos bases, nous allons pointer nos deux branches vers ce sommet, qui est le dernier ami du master Pour le rebasage, la première étape consiste à passer à la branche que nous voulons rebaser Ici, nous voulons rebaser notre branche OT des fonctionnalités, et après cela, nous appliquerons le rebase Nous allons d'abord passer à la branche feature OT. Maintenant, quelle est la commande pour rebase ? C'est vraiment simple. Écrivez git, rebase et master. En gros, nous disons à Git. Nous voulons rebaser notre branche actuelle sur le pointeur Master, qui est actuellement la dernière commande de la branche master Vous voyez, nous avons révisé notre branche avec succès. Dans le monde réel, nous sommes souvent confrontés à des conflits au cours du rebasage Je vais vous montrer comment nous pouvons gérer les conflits dans la prochaine leçon. Actuellement, nous nous concentrons uniquement sur le simple rebase. Voyons ce que nous allons obtenir dans l'histoire. Vous voyez, nous avons ici une histoire linéaire. Maintenant, si nous voulons les fusionner, nous passons d'abord au master, puis nous exécutons simplement get merge, feature OT et done. voyez, ici, nous procédons rapidement à notre fusion parce que nous avons un historique linéaire. Pour vous expliquer cela plus clairement, voici l'histoire avant et après. Nous pouvons voir que nous n'avons pas le même manteau de branche. Comme je vous l'ai dit, j'ai créé une nouvelle comète , identique à l'ancienne branche kmete Si nous avons trois médicaments dans les deux branches, nous pouvons obtenir trois nouvelles couches Dans la leçon suivante, nous allons voir ce que nous allons faire en cas de conflit lors du rebase 58. Résoudre les conflits tout en réduisant: Voyons maintenant comment gérer conflits lors du rebasage Cela n'a rien de spécial. Nous suivrons le même processus que celui utilisé pour résoudre les conflits par le passé. Mais il y a deux ou trois commandes utiles dont nous avons besoin pendant ce temps. Donc, tout d'abord, il faut à nouveau créer une nouvelle branche. Disons que je suis littéralement à court de nom. Disons FixBugot. Apportons maintenant quelques modifications à notre fichier STML à points d'index. Ici, je change le titre de notre site Web. Ensuite, nous écrivons simplement Fix Auth bug. Dites les modifications et revenez à notre terminal. Voici un petit conseil. Si vous n'aimez pas basculer entre deux fenêtres, vous pouvez également ouvrir le terminal dans le code VS. Appuyez simplement sur Ctrl plus Batak ou Commande plus Batak. J'aime utiliser itbash alors je passe à ça. Tout d'abord, organisons nos modifications et validons également les modifications. Gate commit Fixburg dans le cadre de l'authentification Bien. Nous devons maintenant valider les modifications dans la branche principale et dans la même ligne pour créer un conflit. Revenons donc à la branche master et passons au code VS. Et dans le fichier STL à points d'index, nous changeons également le titre, adhérons à plus de points d'exclamation Enregistrez ce fichier. Goûtons le changement et validons également les modifications avec un message. Modifiez le titre du site Web. Regardons notre historique. Vous voyez, nous avons ici des branches divergentes. Maintenant, nous rebasons simplement cette branche sur le dernier pointeur principal Quelle est la première étape du rebase ? Nous passons à la branche que nous voulons rebaser. Nous passons à la succursale FXBurgoth. Que ferons-nous alors ? Nous écrivons simplement kit rebase master. Voyez ici que nous obtenons le conflit dans le fichier HTML d'index. Ouvrons le code VS, et ici nous pouvons voir un conflit. Nous pouvons maintenant choisir l'une de ces trois options. Je sélectionne ici la première option, sauf les modifications en cours. Enregistrez ce fichier et retournez dans le terminal. Ici, nous pouvons voir que nous sommes dans le processus de rebase. Maintenant, nous n'avons qu'un seul conflit. Si nous avons plusieurs conflits, nous devons tous les résoudre. Ensuite, il suffit d' écrire git rebase, dash, puis de continuer le processus de rebase pour la prochaine branche de la comète Si le prochain commit comporte également des conflits, les résolvons à nouveau et exécutons à nouveau cette commande git rebase, dash continue Nous continuons jusqu'à ce que tous nos conflits soient résolus. Donc, si pour un amide, nous voulons éviter les conflits, nous pouvons utiliser ici une autre option, Dash Dash Kip Cela évitera le conflit actuel qui nous entoure. Par exemple, nous avons un conflit et nous ne voulons pas le résoudre, alors nous utilisons ici Skip. Nous avons également une autre option, qui est Dash About pour parler du processus de rebase sans résoudre les conflits C'est très utile alors que nous sommes tant de conflits et que nous ne voulons pas les résoudre ici. Donc, dans cette situation, nous pouvons parler de ce processus de rebase. Tu vois, notre processus de rebase est terminé. Nous ne procédons pas ici à un rebase, car il s' agit du même processus que celui que nous avons vu dans la leçon précédente Et une autre raison est que nous avons branche divergente dont nous avons besoin dans la prochaine leçon C'est pourquoi j'ai opté pour ce processus de rebase. Si vous voulez rebaser, vous pouvez le faire. Mais dans la leçon suivante, vous devez créer des branches divergentes Comme vous pouvez le constater, rebase réécrit littéralement l'histoire C'est pourquoi utiliser le rebasage avec des projets locaux. 59. Technique de cueillette de cerise: Voici maintenant notre histoire de Cate. Supposons que nous ayons, comme dans la branche WigberGoth, A un et A. Maintenant, nous voulons copier intégralité de cet Evan Camt et l'ajouter dans notre branche principale ou dans une autre branche Vous pourriez dire que nous pouvons fusionner ces deux branches, mais voici le problème. Notre succursale de Fixburgoth n' est pas prête à fusionner. Nous avons du travail à faire dans la succursale de Wigberg slash Oth. À ce moment-là, nous utiliserons une technique appelée «   cherry peg ». Lorsque nous voulons copier un gamète entier d'une branche à une autre, nous utilisons la technique de cueillette des cerises Ici, dans notre projet, nous pouvons voir que nous avons notre branche principale et que nous avons une branche Figburgoth avec une seule Camt Pour le démontrer plus clairement, nous allons créer un gamète supplémentaire dans la branche auth. Nous sommes actuellement sur la succursale Wix per South. Dans le code VS du fichier scrip point js, nous ajoutons simplement une autre ligne de console, écrivons les modifications pour le deuxième commit pour FixBugot Ces changements ne sont pas importants car nous ne travaillons pas sur le vrai projet. Ici, notre objectif principal est d'apprendre Git, enregistrer les modifications et de revenir à notre terminal. Mettons en scène et engageons-nous ensemble. Gate AM corrige le bogue d'authentification dans le fichier Scrape Dot JS. Vous vous demandez peut-être pourquoi j'utilise cette commande ensemble et pourquoi je l' utilise parfois séparément. La commande unique ne sera exécutée que lorsque nous aurons des mises à jour. Si nous ajoutons un nouveau fichier, nous devons d'abord préparer ce fichier, puis le valider. Bien. Revoyons maintenant l'histoire. voyez, dans une branche, nous avons deux gamètes et ici, nous avons un gamète dans la branche principale Maintenant, choisissons cette première rencontre. Ce commit contient donc ce que nous voulons copier. Pour moi, c'est e67 90d4, où nous voulons ajouter ce commit, nous avons besoin de cette copie de commit dans notre Tout d'abord, nous passons à la branche master. Maintenant nous l'écrivons Cherry Pik ici nous écrivons notre commit, que nous voulons copier voyez, nous avons ici un conflit, et c'est pourquoi je vous ai dit de ne pas le résoudre dans la leçon précédente, et nous pouvons également constater que nous sommes en train de sélectionner les cerises. En cas de conflit, nous accédons simplement au code VS et résolvons le conflit. Ici, nous acceptons les modifications entrantes. Enregistrez ce fichier et retournez dans le terminal. Nous vérifierons ici notre statut actuel. Vous voyez ici que nous obtenons un chemin fusionné. Nous devons donc échelonner nos modifications, point final. Et maintenant, vérifions à nouveau le statut. Voir le chemin non fusionné a disparu. Nous pouvons donc maintenant valider, Gate, valider et appuyer sur Entrée. Ouvrez via le code, et ici nous écrivons un message de validation. À la fin, je rédige simplement une copie afin que nous puissions rapidement identifier. Voyons l'histoire de notre amet. voyez, nous avons ici le nouveau copykamet et notre branche est toujours la même qu'avant Nous copions donc les modifications de cet amet sans fusionner la branche Fibergoth dans notre branche principale Maintenant, laissez-moi vous expliquer pourquoi cette technique porte le nom de cueillette de cerises. nom de la cueillette des cerises reflète donc le caractère sélectif de ce processus. Donc, si vous voyez un cerisier sur cet arbre, nous en avons beaucoup. Mais pour manger la cerise douce, nous devons sélectionner une cerise spécifique de l'arbre, puis nous pouvons déguster la cerise. J'ai la bouche pleine d'eau. Maintenant que nous sélectionnons une cerise spécifique dans le cerisier de git, nous avons mitre et nous choisissons un commit spécifique et nous en tirons parti Comme nous cueillons des cerises. C'est pourquoi Git a appelé cette technique technique « technique de cueillette de cerises ». J'espère que ça te plaira. Rendez-vous dans la prochaine leçon. 60. Ajouter un fichier spécifique à une autre branche: Maintenant, dans la technique de cueillette des cerises, souvenez-vous que nous copions une viande entière. Mais que se passe-t-il si nous voulons simplement copier un fichier spécifique du Kami ? Voici donc comment nous pouvons le faire. Nous sommes donc actuellement sur la branche master, et si nous regardons notre fichier script point js, nous n'avons ici que deux lignes de console. Maintenant, si nous passons à la branche FXBurgoth et que nous voyons, dans notre fichier script point js, nous obtenons deux Nous voulons maintenant copier ce fichier script point js depuis la branche FXBurgothBranch et l'ajouter dans notre branche et l'ajouter dans notre Nous revenons à nouveau à la branche principale car nous voulons ajouter le fichier dans la branche principale. Ici, nous écrivons Git, restaurons la source égale à, et ici nous écrivons le nom de marque à partir duquel nous voulons copier le fichier, savoir Vicksburg oth Ensuite, nous écrivons le chemin du fichier que nous voulons copier. Nous écrivons Js script point js. Assurez-vous d'écrire le chemin du fichier, pas uniquement le script point js. Sinon, vous obtiendrez une erreur. Ici, nous pouvons également séparer le nom de notre fichier de la commande en utilisant un double tiret. Nous l'avons déjà vu. N'oubliez pas qu'il s'agit ici de récupérer le fichier copy script point js, dernière version de la branche WigberGoth, et de le coller dans notre branche principale actuelle Maintenant, si nous examinons notre fichier script point js, nous obtenons ici deux lignes de console identiques à celles de FixBurgoth Nous pouvons maintenant mettre en scène les chaînes et si vous voulez valider, nous pouvons également valider notre code C'est ainsi que nous pouvons copier un fichier spécifique d'une branche à une autre. 61. Brancher et fusionner dans VS Code: Voyons maintenant la fonctionnalité de branchement et de fusion dans notre code VS. La première chose que je veux clarifier est code VS n'a pas toutes les fonctionnalités, ce que nous faisons à l'aide des commandes git. Voyons donc ce que nous avons dans VSCode. Ouvrez le contrôle de source. Ici, nous obtenons notre scène et fichiers de scène. Nous l'avons déjà vu. Maintenant, ici en bas, après vient, nous avons la section des branches. Ici, nous pouvons voir toutes nos succursales. Nous avons le master Fix BouGot et le dossier de branche des fonctionnalités Vous vous demandez peut-être si nous n'avons pas créé ce dossier de fonctionnalités. Alors qui l'a créé ? Permettez-moi de vous dire que nous le créons parce que nous utilisons une barre oblique dans le nom de la branche, et pour toutes les branches de fonctionnalités, nous utilisons une barre oblique dans le nom de la branche C'est pourquoi nous avons ici un dossier de fonctionnalités. Si nous avons plus d'une branche avec Fix Berg, nous obtenons également ici le dossier Fix Berg. Maintenant, nous pouvons voir que nous sommes actuellement sur la branche principale car nous avons ici Tick Mark. De plus, nous pouvons changer de branche à partir d'ici. Nous pouvons également créer une nouvelle branche à partir d'ici. Nous avons également afficher la branche sous forme de liste et quelques options supplémentaires. Maintenant, si nous cliquons sur n'importe quelle branche, nous pouvons comparer les options. Sélectionnez le, et nous écrivons ici le nom de notre marque que nous voulons comparer. Disons Pis Burgot. Voyez maintenant cette option convertie en menu déroulant. Nous pouvons voir ici les fichiers qui sont modifiés ou modifiés. Actuellement, nous n' avons aucun fichier ici, mais si nous avons des fichiers , en cliquant dessus, nous pouvons voir les modifications. Maintenant, laissez-moi vous montrer comment effectuer la fusion. Cliquez avec le bouton droit sur la branche Fix Burg Oth et sélectionnez Fusionner dans la branche actuelle. Ici, nous avons de nombreuses options de fusion. Tout d'abord, nous avons merge, qui est une simple commande de fusion comme git merge et le nom de branche. Après cela, nous avons une fusion rapide. Ici, nous pouvons voir que nous n'avons qu' une avance rapide. indiquons ainsi la démarche, n'utilisez la fusion rapide que si possible Sinon, laissez-le tel quel sans le fusionner. Ensuite, nous avons la fusion par squash, puis nous n'avons pas de fusion rapide, et enfin nous l'avons fait sans avance rapide et sans validation, ou nous pouvons également annuler ou procéder à une défusion. Sélectionnons simplement la fusion par défaut, et nous fermons ce fichier de message de validation et la fusion est terminée. Maintenant, si nous voyons nos amides, nous arrivons ici à merge commit Maintenant, si nous écrivons une fuite sur le Camt précédent, nous obtenons ici l'option de retour. Ici, nous sélectionnons l'inversion simple et voyons ici que nous obtenons le tour inverse Maintenant, nous pouvons également réinitialiser notre Camt. Ici, nous avons quelques options, soft, hard ou mix Pour l'instant, annulons cela. Comme nous pouvons le constater, ce contrôle de source est très déroutant pour les branches. Je n'utilise pratiquement pas ce contrôle de source pour les succursales. Pour les branches, nous avons installé l'extension Git Lens, qui est un excellent outil. Cliquez ici sur l'icône Git Lens. Ici, dans un premier temps, nous obtenons l'icône du graphe Commit. Cliquez dessus et voyez, nous avons ici le graphique de validation. Maintenant, pour y voir plus clair, je ferme cette extension d'objectif Git, je ferme également tous ces fichiers par le haut et je clique sur cette option Ouvrir dans la zone de l'éditeur. Fermons la fenêtre du terminal. Vous voyez, ce graphique semble plus clair. voyez, au début de ce projet, nous avons une histoire linéaire. Ensuite, nous créons nos commentaires sur les fonctionnalités de notre branche, puis nous les fusionnons dans la branche principale. Après cela, nous créons une autre branche et les fusionnons à nouveau dans master. Maintenant, en haut, nous pouvons voir ici que nous avons une branche. Maintenant, si nous cliquons sur n'importe quelle branche, nous avons plusieurs options. Tout d'abord, nous sommes passés à une autre branche, réinitialisé les modifications, renommé la branche, créé une branche, créé une balise, etc. Créons maintenant une nouvelle branche ici. Entrez le nom de la succursale. Disons que Vicksburg Slash s'enregistre. Appuyez sur Entrée, et nous avons ici trois options. Créez une branche, créez, changez et annulez. Nous sélectionnons donc Créer et basculer. Maintenant, ouvrons un fichier, appuyons sur Ctrl plus P ou Commande plus P, et ouvrons le fichier JS à point ouvert Ici, nous apportons quelques modifications. Enregistrez ce fichier, puis validez ces modifications. Passez donc au contrôle de source. Et ici, nous écrivons notre message de validation. Disons que vous travaillez sur l'inscription à Fix Berg et que c'est fait. Revenons maintenant au graphe de validation. Ici, nous pouvons voir notre branche active actuelle est FixBurglarGistration, et nous avons également Maintenant, si nous cliquons avec le bouton droit sur la branche principale, nous obtenons plus d'options, passons à la branche, fusionnons avec la branche actuelle, rebasons, renommons, et bien plus encore voyez, nous avons ici les mêmes options que celles que nous avons dans le contrôle de source. la prochaine leçon, nous verrons comment voir les branches et les fusionner dans Github DesktraLablication 62. Brancher et fusionner dans Github Desktop: Comme nous le savons, pour les interfaces utilisateur graphiques, nous avons deux applications. Le premier est Github desktop et le second est Kraken. Si vous êtes sûr de vouloir utiliser Kraken, vous pouvez sauter cette leçon et passer directement à la leçon Git Kraken Voici l'interface de l'application de bureau Github. Maintenant, pour les succursales, nous avons ici la liste des succursales. Vous voyez, ici, nous pouvons voir notre succursale actuelle. Maintenant, pour changer de branche, il suffit de cliquer sur cette branche. Tu vois, nos succursales ont changé. Ici en haut, nous avons la possibilité de créer une nouvelle branche, ce qui est très simple. Maintenant, ici en bas, nous avons la possibilité de fusionner la branche du sélecteur dans la branche principale Sélectionnons-le et ici, nous devons sélectionner la branche que nous voulons fusionner. Imaginons FixBurgRegistration, que nous avons créé dans Cliquez sur FixburgRegistration. Sélectionnons Rate Merge Camt. Si nous avons un conflit, nous pouvons le résoudre à partir du code VS, puis poursuivre la fusion. Ici, nous recevons le message de réussite de la fusion, et si nous vérifions notre historique de validation, vous pouvez voir la validation de la fusion. Maintenant, si nous voulons accéder à plus d'options de branche , nous avons ce menu de branche. Ici, nous pouvons créer une nouvelle branche, renommer, supprimer, comparer, fusionner dans la branche actuelle, fusionner, rebaser, etc. Maintenant, permettez-moi de vous montrer une comparaison. Donc, par rapport à une succursale, et nous avons ici des options de comparaison. Mais comme vous pouvez le voir ici, nous ne pouvons pas voir correctement l'historique des validations avec les branches. C'est pourquoi de nombreux développeurs n'aiment pas Gitub desktop. Si vous aimez Gitub Desktop, vous pouvez utiliser l'historique des validations de VS code pour surveiller les validations et les branches, puis utiliser Merge Tool dans l'application de bureau Github C'est une meilleure option. En fin de compte, le choix vous appartient. 63. Brancher et fusionner dans GitKraken: Maintenant, ouvrons l'application Git Kraken. L'histoire pénale est toujours mon cœur. Regarde comme c'est beau. Nous pouvons voir clairement les branches et l'historique des validations bien mieux qu'en utilisant le code VS ou l'application de bureau Github voyez, nous avons ici un graphique clair pour les branches , que nous pouvons facilement comprendre. En haut, on peut voir la liste des branches. Et si nous sélectionnons une branche, nous pouvons passer à cette branche. C'est très simple. Laissez-moi vous montrer comment créer une nouvelle branche. Cliquez avec le bouton droit sur la branche et nous avons ici un tas d'options. Sélectionnez Créer une nouvelle branche. Ici, nous donnons le nom de la succursale. Disons que la fonctionnalité Slash se déconnecte. Ici, nous pouvons voir que nous obtenons le passage automatique à cette branche. Faisons maintenant quelques amas dans cette branche. Revenons à VS code openscrip point sple et enfin, à la console point log, nous implémentons la fonctionnalité Logout Les modifications et validons ces modifications. Donnez le message de validation. Disons implémenter la fonctionnalité de déconnexion et la valider. Petit conseil ici, si nous voulons voir la branche active actuelle, nous pouvons la voir à partir d' ici dans le code VS. À partir de là, nous pouvons également passer à l'autre branche. Revenons à la branche Master, où nous const également point log et ajoutons des mises à jour dans le fichier script point js Nous allons également valider avec un message, mettre à jour le fichier script gs. Sachez que ce n'est pas un bon message de validation, mais c'est juste pour une démonstration. Revenons-y maintenant Kraken et nous pouvons voir comment la branche diverge Lovely Maintenant, avant de procéder à la fusion, voyons comment comparer deux branches. Sélectionnez la branche de déconnexion et maintenez en sécurité. Et sélectionnez l'autre branche qui est master. voyez sur le côté droit, nous avons la différence entre deux branches, et en dessous, nous avons la liste des fichiers concernés. Si nous sélectionnons le fichier, fichier est ouvert avec les modifications. Je change intentionnellement la même ligne ici, donc nous avons un conflit dans la troisième ligne et fusionnons. Sélectionnez la branche principale et branche droite sur la branche de déconnexion que nous voulons fusionner Ici, nous avons une fusion, et nous avons également une rebase Sélectionnons Fusionner. voyez, ici nous avons un conflit, et ici nous avons tous les fichiers en conflit Nous sélectionnons le fichier script point JS, et nous obtenons ici ce bel outil de fusion. Ici, sur le côté gauche, nous avons des modifications depuis le master, et sur le côté droit, nous avons des modifications depuis la branche Logout, et en bas, nous avons le résultat final Ici, nous pouvons sélectionner les branches en cochant la case, et nous pouvons également sélectionner les deux. Nous pouvons également supprimer à partir d'ici, et si nous avons plusieurs conflits, pouvons les voir à partir d' ici avec les flèches vers le haut et vers le bas. Maintenant, lorsque nous sommes satisfaits de nos conflits, nous enregistrons simplement les modifications à partir d'ici. Maintenant, sur le côté droit, nous avons la liste des fichiers de scène. Nous avons également un message de validation prêt. Nous avons maintenant deux options, Comte et merge, et sur le point de fusionner. Passons à Commit et à merge. Ici, en haut, on obtient T merge Comte. Très simple et facile. Imaginez maintenant que nous obtenions une erreur dans notre code à la suite de cette fusion. Nous pouvons également annuler ou rebaser notre Commit. Cliquez avec le bouton droit sur le Commit et sélectionnez l'option Revert Commit Nous demanderons une confirmation pour Kat immédiat. Nous sélectionnons Oui, C, ici nous obtenons Revert Kumt Maintenant, si vous voulez réinitialiser l'amide à ce milieu avant de procéder à la fusion, nous pouvons écrire, cliquer ici et sélectionner Réinitialiser. Ici, nous avons trois options : douce, mixte et dure. Nous l'avons déjà bien vu. Maintenant, voici une chose. Imaginez que vous n'ayez pas appris les commandes git avant d'utiliser Git Kraken ou toute autre interface utilisateur graphique, alors vous allez certainement tomber dans un état confus C'est pourquoi j'ai décidé de vous enseigner d'abord les commandes Git , puis les interfaces utilisateur graphiques comme Git up desktop et Git cracon C'est parti pour la réinitialisation matérielle et nos commandes de fusion et d'annulation ont disparu. C'est ainsi que nous pouvons travailler avec les branches et les fusionner dans le Git Kraken Je sais que cette section est un peu plus longue, mais ce sont toutes des leçons de fusion très importantes. Vous avez donc fait un excellent travail. Offrez-vous une petite gâterie, écoutez de la musique, jouez à des jeux ou faites une nouvelle promenade. Nous poursuivrons notre quête de maîtrise des kits dans la section suivante. Rendez-vous donc dans la section suivante. 64. Section 05 Travailler en équipe: Bienvenue dans la cinquième section du cours Ultimate Kit. Dans cette section, nous verrons comment travailler en équipe avec Git. Actuellement, notre référentiel se trouve dans notre environnement local, mais dans le monde réel, nous devons travailler sur un référentiel sur le cloud. Vous vous demandez peut-être comment pouvons-nous travailler avec les autres membres de l'équipe au sein d'une même entreprise ? Nous avons appris comment récupérer modifications auprès des autres membres de l'équipe, publier nos modifications, extraire des requêtes, résoudre des problèmes et bien d'autres choses encore Je sais que vous êtes enthousiasmé par cette section, et je le suis également. Donc, sans perdre de temps, voyons comment nous travaillons en équipe sur un seul projet à l'aide de Git. 65. Aperçu du travail en équipe: Donc, comme je vous l'ai dit, jusqu'à présent, nous ne travaillons que localement. Mais dans le monde réel, nous ne travaillons pas seuls. De nombreux développeurs travaillent sur un seul projet, et c'est pourquoi nous verrons comment les développeurs travaillent ensemble sur le même projet en l'utilisant. Alors permettez-moi de vous poser une question simple. Voici notre référentiel. Comment pensez-vous que les autres membres de l'équipe peuvent travailler avec ce référentiel ? Une solution consiste à héberger ce référentiel quelque part sur le serveur et à ce que tous les développeurs travaillent sur le référentiel unique. C'est ce qu'on appelle un système de contrôle centralisé des personnes. Et si le serveur sur lequel se trouvait notre dépôt se déconnecte ou passe en maintenance ? Ensuite, tous les développeurs doivent s'asseoir et attendre que le serveur sorte de la maintenance. Cette approche ne fonctionne pas correctement. Maintenant, une autre solution s'adresse à chaque développeur, nous leur donnons un référentiel sur leur propre PC ou ordinateur portable. Ils ne dépendent d'aucun serveur. Ils peuvent à tout moment travailler sur leur dépôt. C'est ce qu'on appelle des Vers et un système de contrôle distribués, et Git est l'exemple de ce système de contrôle et de contrôle distribués. Maintenant, vous pouvez vous demander si tous les développeurs travaillent sur leur propre système, comment peuvent-ils collaborer avec les membres de l'équipe ? Pour travailler en équipe, nous utilisons un référentiel centralisé tous les développeurs. Tous les développeurs ont leur propre référentiel, mais nous avons également un référentiel central qu'ils utilisent pour la collaboration. Permettez-moi de vous expliquer cela à l'aide d'un exemple concret. Supposons que c'est toi et que c'est moi. Ici, nous travaillons sur un même projet, qui est, disons, une application de commerce électronique. Tout d'abord, nous allons cloner notre projet existant pour nous deux dans notre système personnel. Supposons maintenant que vous travailliez sur votre tâche, que vous fassiez des caméras, et que lorsque vous serez prêt, vous introduisiez ces modifications dans ce dépôt. Maintenant que nous avons des mises à jour sur le dépôt, j'en suis informé. J'ouvre ce dépôt et j'enregistre les modifications dans mon système. Maintenant, mon code et le code de ce dépôt deviennent identiques. Mais imaginez que j'en arrive à un conflit. Je résous le conflit ici sur ma machine, puis j'envoie mon code vers ce référentiel. Maintenant, les autres développeurs et vous pouvez extraire ce code mis à jour et continuer à travailler sur ce projet. C'est ce qu'on appelle un flux de travail centralisé et suivez évidemment ce flux de travail centralisé. Ne vous y trompez pas. Le flux de travail centralisé et le système de contrôle et de contrôle centralisés ne sont pas les mêmes. Ce sont des choses différentes, seuls les noms sont similaires. Suivez ce travail centralisé Maintenant, certaines entreprises utilisent leur propre serveur privé pour héberger ce référentiel dans leur entreprise, mais la maintenance de leur propre serveur n'est pas coûteuse pour les nouvelles entreprises. Les nouvelles entreprises aiment donc utiliser un serveur basé sur le cloud qui peut héberger leur référentiel en privé. C'est une option bon marché et intéressante pour les nouvelles entreprises et les startups. De nombreuses entreprises fournissent ce type de services cloud pour l' hébergement de référentiels, et vous avez raison. Github est l'une des plateformes d'hébergement de référentiels. Nous avons également Gitlab, Bitbucket, GIT et bien Mais nous savons tous que Github est l'une des plateformes les plus populaires, nous allons donc utiliser Github Vous utilisez une autre plateforme d' hébergement, mais vous pouvez continuer ce cours car nous parlons de travail en équipe. Peu importe la plateforme d' hébergement que vous utilisez. Quoi que vous fassiez sur Github, je pense que toutes les bases peuvent être effectuées autre plateforme d' hébergement de référentiels Et si vous travailliez seul ? Dans ce cas, vous pouvez également utiliser Gitub pour stocker notre code en tant que Même 20 à 40 % des développeurs utilisent Gitub pour stocker leur ligne et gérer leur CV À l'avenir, ils ne perdront pas leur code. Il sera également disponible sur leur compte Github. Il est bénéfique pour vous d'apprendre cela. À partir de la leçon suivante, nous allons voir ce flux de travail en cours. Je suis très enthousiaste à ce sujet. 66. Comment télécharger un projet sur github: Avant de commencer à créer un nouveau dépôt, de nombreux étudiants me demandent comment puis-je télécharger notre projet Git existant sur Github ? Laissez-moi vous montrer comment nous pouvons télécharger des projets locaux sur Github Tout d'abord, nous verrons le téléchargement du projet à l'aide de Github Dektop, puis je vous montrerai Gate Cracon Donc, d'abord, j'ouvre Github Dektop ici, d' abord, nous vérifions que notre dépôt est ouvert ou non S'il n'est pas disponible dans cette liste, nous accédons au fichier dans le référentiel local parcourons simplement ce dossier et ouvrons notre projet ici. Maintenant, si nous n' avons aucune modification, nous arrivons ici à l'option de publication directe du référentiel. Sinon, nous avons également cette option ici après l'option de branche. Ici, nous pouvons voir que ce dépôt n'est disponible que sur votre machine locale. En le publiant sur GitHub, vous pouvez le partager et collaborer avec d'autres personnes. Cliquez donc sur ce bouton de dépôt public. Nous allons obtenir cette fenêtre contextuelle qui demande le nom du dépôt. Je lui donne Tas track pour Git. Si vous souhaitez écrire une description, vous pouvez l'écrire ici. À partir de là, nous pouvons rendre notre dépôt privé ou public. Si nous transformons notre dépôt en république, n'importe qui sur Internet pourra regarder notre code. Une chose est que si vous souhaitez collaborer avec d'autres, nous devons rendre notre dépôt public. Si nous le rendons privé, nous devons payer pour un dépôt privé pour la collaboration. Si vous souhaitez simplement stocker du code, nous pouvons utiliser un référentiel privé. Je décoche cette case pour dépôt public et je clique simplement sur publié Regardez-le publier. Si vous souhaitez vérifier, nous pouvons consulter notre dépôt sur Github en utilisant ce bouton C'est aussi simple que cela. Maintenant, laissez-moi vous montrer comment nous pouvons faire de même avec l' application Git Kraken Ouvrez l'application Git Kraken et sélectionnez le dépôt que vous souhaitez publier Maintenant, avant de publier le dépôt, nous devons connecter notre compte Github à l'application Get Kraken Cliquez donc sur ce bouton de réglage à partir d' ici et accédez à l'onglet d'intégration. Ici, nous avons quelques services d'hébergement par défaut, c'est sec Github et nous voyons ici que nous ne sommes pas connectés Connectons-nous à Github. Il vous sera demandé de vous connecter avec votre compte Github. Je me connecte avec mon compte. Il nous demandera de vous connecter ou d'autoriser. J'autorise et ici j'écris mon mot de passe et je l'ouvre simplement dans le Crack et l'application. Vous voyez ici que nous obtenons notre compte. Fermons maintenant ces paramètres. Nous n'en avons pas besoin. Maintenant, pour publier un dépôt, nous devons d'abord ajouter une télécommande, cliquer sur cette icône Cloud qui correspond à télécommande et ici nous pouvons voir que nous n'avons aucune télécommande. Nous pouvons donc en créer de nouveaux. Ici, nous pouvons voir que Github a été sélectionné, et il demande le nom du référentiel, le nom de la télécommande, que nous voyons dans cette liste distante, la description du référentiel, et nous pouvons également le rendre public ou privé Ne vous inquiétez pas, cliquez simplement sur Créer une télécommande et appuyez sur le bouton Local Rev. Et puis nous recevons un message de réussite. Nous pouvons également le consulter sur github.com. Cela semble un peu compliqué car nous poussons tous nos camts en une seule fois Mais dans le monde réel, nous créons d' abord notre référentiel, puis y travaillons. Ne vous inquiétez donc pas pour ça. Dans la leçon suivante, nous allons créer un nouveau dépôt à l'aide du site Web Github et apprendre les concepts des sections dans leur référentiel Vous ne vous laissez donc pas tromper par ce projet principal. 67. Comment créer un nouveau projet sur github: Ouvrez donc github.com, et si vous n' avez pas de compte Gitub, vous pouvez facilement créer un C'est vraiment simple et facile. Assurez-vous également de vérifier votre compte de messagerie avant de créer un nouveau référentiel. Je me suis déjà connecté avec mon compte ici. Maintenant, pour créer un nouveau dépôt, cliquez sur cette icône en forme de plus. Ici, nous avons un nouveau dépôt, et nous pouvons également importer un référentiel depuis un autre emplacement. C'est parti pour un nouveau dépôt. Ici, nous entrons d'abord le nom de notre dépôt , que nous voulons donner. Disons CardWishGT parce que j'ai le référentiel Cardwisname Maintenant, ici, nous pouvons écrire la description de ce dépôt. Ensuite, nous avons l'option publique ou privée. Comme je vous l'ai déjà dit, si nous choisissons le mode privé, nous devons payer pour travailler en équipe. Nous sélectionnons donc ici public. Nous avons maintenant quelques options. Vous pouvez ajouter un fichier ad me dans lequel nous pouvons écrire une longue description de notre projet ou de notre site Web, et nous pouvons également sélectionner le fichier Getting nor. Ici, nous avons une liste de langues. Pour l'instant, nous n'en voulons pas et nous cliquons sur Create Repository. Ensuite, nous créons un nouveau dépôt. Ici, en haut, nous pouvons voir notre nom d'utilisateur et couper le nom de notre dépôt Si quelqu'un vous demande de voir votre code, vous pouvez lui donner cette URL Github Mais pour cela, vous avez besoin d'un dépôt public. Sinon, les gens ne le verront pas. Nous avons maintenant la liste de nos succursales. Actuellement, nous n'avons qu' une seule succursale, qui est la principale. Cette branche principale est la même que notre branche principale. Github a appelé la branche principale comme branche principale. Après cela, nous avons le numéro de branche et nous obtenons également le nombre de tags. Ici, nous pouvons rechercher un fichier spécifique. Nous pouvons également créer un nouveau fichier et télécharger des fichiers. Maintenant, dans cette boîte carrée, nous pouvons voir notre projet. Ici, nous pouvons voir notre dernier Commit. Maintenant, vous pouvez vous demander, nous n'avons rien commis. agit du commit créé par Github pour créer un nouveau dépôt Ici, nous pouvons voir que Commit a du temps lorsqu'il commet et tous les commits. Vérifions-le. Nous avons ici la liste des commits. Nous pouvons le filtrer par utilisateur à partir d' ici et nous pouvons également le filtrer par heure. Maintenant, à partir de là, nous pouvons voir les validations par branches, et si nous voulons voir plus de détails sur les validations, nous pouvons cliquer dessus. Ici, nous obtenons la branche qui est principale. Nous obtenons le nom d'utilisateur et nous gagnons également du temps. Après cela, nous pouvons voir le fichier modifié avec deux ajouts et zéro suppression et nous pouvons voir ces lignes ici. Bien. Retournez à notre page de code. Ici, nous obtenons la liste des fichiers du projet et sur le côté droit, nous avons également le message de validation. Dans quelle commande ce fichier est ajouté ou modifié. Nous pouvons également consulter le contenu du fichier à partir d'ici. Il y a une petite introduction au dépôt Github. Dans la leçon suivante, nous verrons comment ajouter des membres de l'équipe dans ce référentiel. 68. Ajouter des membres d'équipe à un projet: Actuellement, notre dépôt est public, mais personne ne peut toujours envoyer de commits dans notre dépôt. Vous pourriez dire que nous avons déjà rendu notre dépôt public et que personne ne peut toujours envoyer de commits. Pourquoi ? Le dépôt public signifie que tout le monde peut consulter notre référentiel, mais nous devons ajouter les membres de notre équipe tant que collaborateurs dans ce référentiel. Nous passons ici à l'option de réglage. Dans la section d'accès, nous obtenons l'onglet collaborateurs. Ici, nous pouvons voir que nous n'avons aucun contributeur. Ajoutons un membre de l'équipe à ce projet. Ici, nous ajoutons un membre, et nous pouvons rechercher le compte des membres de l'équipe en utilisant d'utilisateur, le nom complet ou le compte e-mail. J'écris mon deuxième compte. Il s'agit de mon nouveau compte que j'ai créé pour ce cours. Si je n'accepte pas votre invitation, suis désolée, car je n' accèderai probablement pas à ce compte à l'avenir. Si vous n'avez pas d' autre compte, vous pouvez créer un deuxième compte pour cette section ou inviter vos amis qui souhaitent également apprendre Git. De cette façon, vous comprendrez mieux ces leçons. Regardez comme cet utilisateur et cliquez sur Ajouter à ce dépôt. Ici, nous avons un collaborateur, mais comme nous pouvons le voir, nous avons une invitation en attente Lorsque vous ajoutez quelqu'un à votre dépôt, Git lui envoie des demandes de collaboration par e-mail. Si la personne accepte l'invitation, félicitations. Vous avez un collaborateur. Mais cette personne a également la possibilité de refuser. C'est ainsi que nous pouvons ajouter des membres de l'équipe ou des collaborateurs dans notre référentiel. 69. Cloner un dépôt Git dans notre machine: Comme nous le savons, nous créons un nouveau dépôt à partir de notre compte Github Mais comment pouvons-nous commencer à travailler sur ce dépôt ? Parce que nous n'avons pas ce dépôt dans notre machine. Voyons comment ajouter ou cloner dépôt depuis Github sur notre machine Accédez à l'option code, et ici nous obtenons le lien de notre dépôt sur Github Copiez-le et ouvrez le dossier dans lequel vous souhaitez cloner ce dépôt. Je suis donc dans le dossier de mon projet, ouvrez Gitwsh ou le terminal dans ce Ici, nous écrivons simplement Gate, clonons, et nous collons notre URL. Si vous utilisez Windows, Control plus V ne fonctionnera pas. Alors cliquez avec le bouton droit de la souris ici et voyez, nous avons une option de page et nous avons également un raccourci pour cela. Maintenant, si nous exécutons cette commande, clonez ensuite ce dépôt avec le nom du référentiel comme nom de dossier. De plus, si vous souhaitez le modifier, nous pouvons également le faire. Disons que je veux juste Cartwish et que j'appuie sur Enter. C, fais cloner ce dépôt. Nous avons donc maintenant toutes les comètes, toutes les branches, littéralement tous les détails sur le dépôt tet Allons dans ce dossier cartws. Changez donc de répertoire en cartwis. Voyons maintenant les manteaux, donc Git Log, Dash Dash P Line, Dash Dash All, Dash Graph. Nous avons maintenant une seule commande, qui est la commande initiale. Ici, nous pouvons voir que notre pointeur principal est sur cette commande, mais nous avons deux autres pointeurs ici, origin main et origin head Qui l'a créé et pourquoi ? Comme nous le savons, le headpointer est utilisé pour savoir sur quel commit nous sommes, et main est notre branche par défaut Maintenant, lorsque nous clonons notre projet depuis GitHub, Git crée une branche distante et lui donne le nom d'origine Il ne s'agit pas d'une branche d'origine. Il s'agit simplement d'une succursale distante. Si nous essayons de passer à la branche, cela ne fonctionnera pas. Nous pouvons également vérifier cela en utilisant la branche git. Vous voyez ici, nous n'avons qu'une seule branche qui est principale. Maintenant, laissez-moi vous montrer quelque chose d'utile. Si nous écrivons gate remote, nous obtenons ici notre dépôt distant qui est origin. Vous vous demandez peut-être ce qu' est un dépôt distant ? Un dépôt distant est le projet ou le dépôt hébergé sur le serveur, comme Github ou Beat Bucket En termes simples, le référentiel distant est, ce qui n'est pas dans notre machine locale. Notre dépôt actuel ne se trouve pas seulement sur notre machine locale, il est également stocké à distance, comme sur Github Ce dépôt distant , appelé comme origine, est utilisé pour fournir des informations sur notre projet Github Comme sur quelle branche les développeurs travaillent actuellement et plus encore. est pour cette raison que Git crée deux autres pointeurs Origins main ou master et Origins head Permettez-moi de vous expliquer cela à l'aide de l'exemple. Supposons que vous et moi travailliez sur le même projet et que nous clonions tous les deux notre projet depuis Github Maintenant, lorsque nous clonons notre projet depuis GitHub, Git crée ces deux pointeurs origin main et origin head Supposons maintenant que je travaille sur une fonctionnalité et que je place la caméra sur notre référentiel. Déplacez ce pointeur principal d'origine vers ce point tardif sur la branche principale. Donc, essentiellement, origin main nous indiquera où se produisent les derniers changements dans notre référentiel Github Donc, si quelqu'un d' autre crée une autre comète, le pointeur principal d'origine se déplace vers cette comète. Vous pourriez dire que vous comprenez Origins Main, qui représente les dernières modifications apportées à notre référentiel. Mais pourquoi cette barre oblique d'origine se déplace également avec cette origine en tant que principale. Honnêtement, il ne bouge pas. Il se trouve sur la même branche. La tête d'Origin est utilisée pour nous indiquer quelle est la dernière succursale passée à la caisse ou, en termes simples, quelle est la dernière page de la succursale consultée ou le dernier travail réalisé par un membre de l'équipe. Supposons que nous ayons ici cette branche de page de produits fonctionnels. Si vous êtes moi ou un développeur passe à l'une des autres branches, alors cette tête d'origine pointera vers cette branche. C'est ainsi que fonctionne ce pointeur. Donc, pour résumer, seul le pointeur principal est utilisé pour nous indiquer sur quel commit nous travaillons actuellement. Origin Min ou Origins Master nous indiquent où se produisent les dernières modifications dans notre référentiel Github Cela nous permet de connaître les dernières modifications apportées à notre référentiel Github Origins HAD nous indique quelle est la dernière vue de succursale ou le dernier travail réalisé par un membre de l'équipe. Ne t'inquiète pas pour ça. Tous vos doutes se dissipent lorsque vous voyez tout cela en action. 70. Récupérer les modifications: Comme nous le savons, il s'agit de notre dépôt Gitub et de notre dépôt local, nous clonons à partir du github Maintenant, ces deux dépôts ne sont pas connectés l' un à l'autre. Ainsi, lorsque quelqu'un place les modifications sur ce dépôt gitub, nous n'obtenons pas automatiquement les validations Nous devons exécuter la commande Git fadge pour obtenir les nouveaux commits dans notre dépôt local Ici, nous devons faire attention. Actuellement, dans notre dépôt local, nous travaillons sur la comète C one. Notre pointeur principal, ou on peut dire principal, est toujours sur cette comète. Mais comme je vous l'ai dit dans la leçon précédente, notre pointeur principal d'origine avancera car il représente les dernières modifications apportées au référentiel distant. En utilisant la commande Git patch, nous obtenons un déclassement, mais notre pointeur principal ou principal est toujours sur notre commit C one mise hors service est donc inscrite dans notre historique, mais notre répertoire de travail n' est toujours pas affecté, ce qui nous permet d'éviter tout conflit Maintenant, si vous êtes à l'aise pour appliquer ces modifications à votre répertoire de travail, nous pouvons exécuter git merge et le nom de ce pointeur, qui est origin Min. Nous n'avons donc pas de branches diversifiées ici. Quel type de fusion Git effectue. Absolument juste. Git exécute une passe pour ou une fusion. Et si nous avons des conflits, les résolvons comme nous les résolvons précédemment, puis c'est fait. Disons pratiquement ce correctif Git. Donc, sur ce navigateur, je me connecte avec mon autre compte Github Et dans cette machine, j'ai mon compte original, que Dieu vous bénisse. Ici, nous n'avons que mon dossier. Modifions-le donc dans ce fichier et validons-le simplement. Cliquez sur ce fichier, et à partir de là, nous pouvons modifier ce fichier et changer ce texte. C'est pour une deuxième validation et il suffit de valider les modifications. Ici, nous pouvons écrire le message de validation. Je le laisse tel quel. Ici, assurez-vous de sélectionner Commit to main branch. Nous pouvons également créer une nouvelle branche à partir d'ici avec ce commit. Mais nous verrons cette option dans la prochaine leçon. Cliquez simplement sur Valider. Revenons maintenant à notre fenêtre de code, voyez, nous avons ici deux comètes. Maintenant, si nous le voyons dans notre dépôt local , nous n'en obtenons qu'un seul. Voyons maintenant comment récupérer dépôt depuis notre dépôt distant Nous écrivons git fetch, puis nous écrivons le nom de notre télécommande qui est origin Nous n'écrivons rien, alors par défaut, Git prend origin. Tu vois, c'est du patch. Regardons maintenant notre historique. voyez, nous arrivons aux comètes, et nous pouvons aussi voir origine principale et la tête d'origine sont déplacées vers cette comète, mais que notre tête est toujours là Voyons maintenant comment ajouter ces modifications dans notre répertoire de travail. Je suggère que nous écrivions git merge, et que nous écrivions le nom de notre pointeur, origins main. Et nous l'avons fait. Ici, nous procédons rapidement à notre fusion et nous pouvons également voir dans notre historique que le pointeur est déplacé vers notre deuxième commande et que nous ouvrons également le fichier IDM dans le code VS, puis nous obtenons le fichier RDM mis à jour 71. Apporter les changements: Dans la leçon précédente, nous avons vu que pour obtenir les dernières modifications depuis le dépôt distant, nous devons utiliser la commande patch, puis pour ajouter des modifications dans notre répertoire de travail, nous devons la fusionner. Comme nous pouvons le constater, il s' agit d'une approche en deux étapes. Nous pouvons également le faire en une seule étape, et savez-vous par quelle commande il est tiré ? Supposons que nous ayons ces amds dans le référentiel local et le référentiel distant Ici, nous validons dans notre référentiel local et ici, un autre membre de l'équipe ajoute également un amid au référentiel distant. Maintenant, si nous exécutons la commande git pool , Git ajoute ce commit sit dans notre dépôt local et pointeur d'origine passe à celui-ci au milieu. Maintenant, git fusionne ces deux modifications et crée une nouvelle couche. Maintenant, de nombreux développeurs n' aiment pas cette approche car nous pouvons voir qu'elle crée un nouveau kamit de fusion et que nous obtenons également des commandes diverge L'autre solution, au lieu de fusionner, nous pouvons également effectuer un rebasage Nous pouvons donc exécuter la commande git, pull, rebase, qui rebasera notre comité ce commit principal origin slash, et c'est ainsi que nous obtiendrons un historique linéaire et clair Maintenant, quelle est la meilleure option pour le pull, le merge ou le rebase ? Honnêtement, cela dépend vraiment de notre situation. Votre responsable vous dira probablement utiliser la fusion ou le rebase, ne vous inquiétez pas à ce sujet Personnellement, j'aime utiliser rebase au lieu d'utiliser merge, car notre historique des validations restera propre Voyons donc cela dans notre référentiel. Donc, pour la pull request, nous devons d'abord valider certaines modifications dans notre dépôt local, ainsi que dans le référentiel distant. J'ouvre donc notre dépôt local dans le code VS et je crée un nouveau fichier, disons, scrap point js, ici, console point log. Il s'agit d'un fichier gratté. Enregistrez les modifications, puis validez ces modifications. Revenons à Git Bash it Ed period, c staging et Gitatm createscript point Regardons maintenant notre historique. voyez, ici, nous avons trois Camits et notre tête est déplacée vers notre dernier ami et origine principal et le responsable d'origine est toujours sur ce commit Créons maintenant Cait dans notre dépôt distant. Passez au deuxième compte. Et ici je crée un nouveau fichier à partir d'ici, et ici nous écrivons notre nom de fichier. Disons que les plans sont parsemés de points TxD. Physiquement, je vais écrire des plans dans ce dossier. Donc, étape numéro un, créez une mise en page de site Web de base pour ce projet. Maintenant, validons ceci, donc validons les modifications. Je laisse ce message de validation tel quel et opte pour Commit. Terminé. Vous voyez, nous avons ici trois commits. Revenons maintenant à notre Git Bash. Ici, nous exécutons la commande git pull, qui ajoutera notre commit de dépôt distant dans notre projet , puis le fusionnera. Il vous demandera un message de validation. Je ne veux pas le changer , alors ferme ça. Vous voyez, la fusion est terminée. Regardons notre historique. voyez, ici, nous obtenons le commit de fusion, et nous obtenons également les manteaux de plongée. Maintenant, laissez-moi vous montrer comment nous pouvons rebaser avec Pull. Avant cela, annulons ce commit de fusion. Donc, git reset, d dash hard, et nous voulons faire un pas avant le début. Alors dirigez-vous vers l'un d'eux. Consultez notre historique. Tu vois, on réinitialise notre fusion, et on obtient cette branche séparée. Alors lançons git pull, rebase. En gros, nous demandons à Git de rebaser notre commit actuel le pointeur principal d'origine et de voir s'afficher un message de réussite Revoyons notre historique une fois de plus. voyez, nous avons une histoire linéaire, et cette origine principale est de se déplacer ici. Dans la leçon suivante, nous verrons une autre commande très utile , la commande push. 72. Pousser les modifications vers le dépôt distant: Actuellement, dans notre dépôt local, nous avons quatre comètes, mais dans notre dépôt distant, nous n'avons que trois kamets Nous n'avons pas celui-ci chez. Si nous voulons ajouter ce kamide au dépôt distant, nous devons utiliser la commande Git push Maintenant, comme nous le savons, cette commande principale sera déplacée vers notre dernier kamid, également dans notre dépôt, Origin Main sera également déplacée vers cette comète Nous l'écrivons push. Ici, nous devons écrire le nom de notre dépôt distant qui est origin. Après cela, le manteau que nous voulons pousser, qui est le principal. Actuellement, nous sommes également sur main, nous pouvons donc supprimer ce principal, nous pouvons également supprimer l'origine car il s'agit du référentiel distant par défaut. Maintenant, il peut parfois vous demander nom d'utilisateur et votre mot de passe Github avant de lancer le code Tu dois l'écrire quand il te le demande et c'est fini. Regardons notre historique. Vous voyez ici que notre origine Min est déplacée vers notre commande principale. Si nous voulons vérifier, nous pouvons consulter notre page GitHub Vous voyez ici, nous obtenons quatre amets et si nous vérifions ici, nous obtenons des camets Nous avons réussi à transférer notre code vers notre dépôt distant. Maintenant, permettez-moi de vous montrer une autre situation. Supposons que nous ayons ici trois gamètes et que dans un dépôt distant, nous n'en ayons que deux Maintenant, avant de placer cette caméra sur la télécommande, membre de notre équipe envoie un autre kamit ici Si nous envoyons notre code, notre commande push échouera Peux-tu me dire pourquoi ? C'est vrai. Dans ce cas, l'historique de notre dépôt local et de notre dépôt distant est différent. Si Git nous autorise toujours à effectuer des push, nous risquons de perdre le commit de ce membre de l'équipe. Et c'est pourquoi Git échoue à notre commande push. Maintenant, de nombreux développeurs utilisent parfois Git push F pour pousser notre code avec force Ainsi, lorsque nous exécutons cette commande, supprimons cet amit et ajoutons notre amid à distance Mais ce n'est pas une bonne pratique, car nous supprimons essentiellement le travail des membres de notre équipe. Donc, si vous n' avez pas de raison principale, alors selon ma suggestion, n'utilisez pas la force de poussée. Maintenant, quelle est la solution à cela ? Donc, si notre demande push échoue, nous faisons d'abord une pull request. Cela ajoutera ce bonbon dans notre référentiel local, puis en utilisant la fusion ou le rebase, nous pourrons ajouter des modifications dans notre Amid puis transférer nos modifications à distance Désormais, l' historique de notre dépôt local et de notre dépôt distant est le même. Les commandes les plus utiles pour Git sont donc git pull et Git push, car ces deux commandes sont très utilisées pour travailler en équipe. 73. Pousser les balises à distance: Supposons maintenant qu'à ce stade, notre application soit prête pour la version 1.0. Vous souvenez-vous de la commande d'ajout de balises ? Ne vous inquiétez pas, vous pouvez consulter mon chit sheet Git. Nous écrivons donc ici la version 1.0 de git tag. Avec cette commande, nous ajoutons une balise à notre commit actuel. Si nous voulons attribuer cette balise à un commit spécifique, nous pouvons écrire ici le pointeur ou le commit. Pour l'instant, ajoutons une balise à notre dernier commit. Vérifions-le. Journal Git. Vous voyez, notre dernier commit est marqué comme tag version 1.0. Maintenant, je voudrais te dire quelque chose. Cette balise n'est visible que dans notre dépôt local. Cela n'est pas visible sur le référentiel distant Github. Alors, comment pouvons-nous envoyer nos balises vers un référentiel distant ? Pour cela, nous devons écrire git push. Ici, nous écrivons le nom de notre télécommande qui est origine. Ici, nous écrivons le nom de notre tag que nous voulons pousser, qui est person 1.0. Terminé. Maintenant, vérifions-le sur le site Github, nous obtenons notre tag ou non Tu vois, ici, nous avons une étiquette. Voyons cela plus en détail. Ici, nous pouvons voir le nom de l'auteur, heure, et nous pouvons également télécharger le code source complet à partir d'ici. Je l'utilise beaucoup lorsque je travaille sur de grands projets. C'est ainsi que nous pouvons appuyer sur un tag. Supposons maintenant que nous voulions supprimer cette balise, afin que nous puissions écrire la même commande ici, nous ajoutons Dash delete. Vous voyez, il a été supprimé avec succès. Maintenant, si nous vérifions notre historique, nous pouvons voir que le tag est toujours là car cette commande supprime simplement le tag de notre référentiel distant. Si nous voulons également supprimer cette balise du dépôt local, nous écrivons Get tag, D, nous écrivons le nom de notre balise. Vous voyez, il est également supprimé de notre dépôt local. 74. Créer des versions pour Github: Ainsi, dans la leçon précédente, nous verrons comment nous pouvons attribuer des balises. Mais voici une chose à propos des tags. Dans les balises, nous ne pouvons pas décrire le contenu de la version 1.0. Donc, si un nouveau développeur rejoint notre équipe, nous devons lui expliquer le contenu de cette version. Sinon, nous devons leur dire de voir tous les changements. Mais ne vous inquiétez pas, Github fournit une solution très utile à cette situation Dans Github, nous pouvons ajouter des versions pour décrire le contenu de cette version Nous passons donc à la section, et voici les versions. Nous n' avons actuellement aucune version, nous en créons donc une nouvelle. Maintenant, en haut, nous avons la possibilité de sélectionner le tag. Actuellement, nous n'avons pas de tag car nous l'avons supprimé lors de la leçon précédente. Ici, notre tag nomme la version 1.0, et nous créons un nouveau tag Après cela, nous sélectionnons une branche, qui est principale. Ici, nous pouvons écrire le titre de notre communiqué. La plupart du temps, nous écrivons le même nom que le nom de notre tag, mais vous pouvez également donner votre nom. Cela dépend entièrement de vous. Dans cette zone de texte, nous pouvons maintenant décrire nos modifications et fonctionnalités. Donc, d'abord, nous sélectionnons le titre ici et ici, notre titre, disons, les détails de la version. Vous voulez voir un aperçu, alors nous pouvons également le voir. De plus, nous avons de nombreuses options. Ajoutons des points pour plus de détails. Créons une mise en page de base du site Web, corrigeons le bogue de mise en page et concevons la page d'accueil. Voyons l'aperçu. Tu vois, on a nos coordonnées. Maintenant, en bas, nous pouvons également joindre des fichiers binaires à cette version. Si vous avez une version compilée de votre application ou un fichier binaire que vous souhaitez ajouter, vous pouvez le modifier ici. Si votre version n'est pas prête à être publiée, nous pouvons la considérer comme une version préliminaire. Les membres de l'équipe savent que ce n'est pas prêt pour la production. Supposons maintenant que nous soyons prêts à publier. Je décoche cette case et je clique sur publier. Ici, nous obtenons notre nouvelle version et nous pouvons voir les détails, quelques informations de base, et sous forme de texte, nous avons également ici notre code source. Release est une très belle fonctionnalité pour travailler en équipe, et nous pouvons également l'utiliser comme documentation de notre parcours applicatif. Si nous allons sur la page d'accueil, sur le côté droit, nous obtenons toutes les versions de ce référentiel. Donc, une chose que je veux vous dire, c'est que version est la fonctionnalité de Github, pas de Git Nous ne pouvons voir les versions qu'en utilisant Github, pas par ligne de commande Dans la leçon suivante, nous verrons comment travailler en équipe en branche. 75. Travailler avec des branches: Voyons maintenant comment vous pouvez travailler avec les branches en équipe. Ici, je crée une nouvelle branche avec kit switch C feature slash ad to cart Regardons maintenant notre liste de succursales. C. Ici, nous avons deux branches, principale et Ajouter au panier. Mais cette nouvelle branche n'est disponible que dans un environnement local. Maintenant, si les membres de notre équipe veulent travailler dans la même succursale, comment peuvent-ils le faire ? Pour cela, nous devons transférer cette branche vers notre dépôt distant. Ou en promouvant ce que nous utilisons, n'est-ce pas ? Nous utilisons git push origin mean pour envoyer des modifications à l'origine. Mais ici, nous mettons tout à jour car cette commande ne fera que transmettre des codes à la télécommande, pas aux branches. Nous écrivons ici, gate, push, nous obtenons ici cette erreur pétale, qui indique que la fonctionnalité de branche actuelle slash head to card n'a pas de branche en amont Il nous donne également des suggestions pour résoudre cette erreur. Cette commande définira cette branche en amont sur l'origine de notre dépôt distant. Mais attendez, qu'est-ce que cette branche en amont ? Que se passera-t-il si nous définissons une branche en amont ? Définir une branche en amont signifie établir une connexion entre notre branche locale et une branche du référentiel distant. Laissez-moi vous expliquer à l' aide d'un exemple. Il s'agit actuellement de notre branche dans notre dépôt local. Si nous montons notre succursale en amont, cela signifie que nous établissons une connexion avec, disons, une branche appelée Origin Slash Feature Slash Ed to card Ne vous inquiétez pas, ce n'est qu'un exemple. Si vous poussez votre branche, elle porte le même nom que celui que vous lui avez donné. Maintenant, ces deux branches sont connectées l'une à l' autre et nous pouvons également parler de branche amont également appelée branche de télésuivi. Vous pourriez dire que nous comprenons que définir une branche en amont consiste établir une connexion entre locale et une branche sur un référentiel distant. Mais pourquoi avons-nous besoin de cette connexion ? Quel est l'avantage de faire cela ? Le premier avantage de la configuration d'une branche en amont est que Git sait où publier les modifications depuis la branche locale. Donc, si nous transférons les modifications depuis la branche locale, cette connexion permet cette connexion permet de savoir où ces modifications seront ajoutées dans le référentiel distant, et il en va de même pour l' extraction des modifications. Si un membre de notre équipe envoie quelque chose à cette branche, alors si nous extrayons ces modifications, saurons d'où il doit récupérer les modifications Il récupérera donc les modifications à partir de cette fonction de barre oblique d'origine des succursales distantes, puis ajoutera à la carte à notre Dans l'ensemble, la configuration d' une branche en amont facilite le transfert et l'extraction des modifications entre le référentiel local et le référentiel distant dans notre flux et l'extraction des de travail. Voyons comment définir branche en amont pour notre branche locale. Et ici, Git nous apporte également une solution. Avant cela, voyons nos agences de suivi locales et à distance actuelles. En gros, nous voyons le nom de la branche en amont. Branche Git, V C, nous avons ici Min et sa branche amont est origins main. Mais pour ce qui est des fonctionnalités complètes, nous n'avons pas de branche en amont ou nous pouvons dire que nous n'avons pas de branche de suivi à distance. Si nous voulons voir la liste des branches de suivi à distance, nous pouvons également avoir une commande pour cela. Branche Git R pour le suivi à distance. voyez, actuellement, nous n'avons que ces deux pointeurs Origins Main et Origin Slash Head Définissons la branche amont ou branche de suivi à distance en utilisant git push, dat , upstream, ou ici, nous pouvons écrire un raccourci dU ou amont, ici nous écrivons notre nom de télécommande qui est origin. Ensuite, nous écrivons le nom de notre succursale locale, qui est feature slash head to cart N'oubliez pas que nous ne devons écrire cette commande que la première fois que nous poussons notre branche. C, la branche est poussée. Maintenant, si nous vérifions nos branches en amont, obtenons la branche V C. Maintenant, nous pouvons voir ici la branche en amont de notre branche locale, qui est la fonction d'origine, barre oblique sur carte De plus, si nous exécutons la branche git R, C, une branche de suivi à distance est ajoutée. Vérifions-le également sur GitHub. En gros, nous avons une branche, actualisez la page et voyez, ici nous avons deux branches. Nous pouvons maintenant commencer à travailler sur cette branche dédiée aux cartes, la même manière que nous travaillons sur notre branche principale. Lorsque nous voulons étendre nos gammas, nous pouvons les appliquer à cette branche et les autres membres de l'équipe peuvent voir ces modifications Si nous voulons supprimer ce lien entre la branche locale et la branche de suivi à distance, nous pouvons écrire une commande comme celle-ci en appuyant sur D pour la suppression. Ici, nous écrivons le nom de notre télécommande, qui est origine. Ensuite, nous écrivons le nom de notre succursale qui est feature slash head to card Nous supprimons donc maintenant la branche de suivi à distance. Si nous exécutons git branch, R, puis C, encore une fois, nous obtenons ces deux pointeurs Et si nous lançons git branch, VV, alors nous pouvons voir fonctionnalité d'origine slash head to card a disparu Supprimons également cette branche de notre dépôt local. Pour ce faire, nous devons d' abord revenir à la branche principale. Ici, nous écrivons la branche Git D, et ici nous écrivons notre fonction de nom de branche slash t sur la carte et c'est ainsi que nous pouvons publier la branche sur notre dépôt distant en définissant la branche amont Dans la leçon suivante, nous allons comprendre dans monde réel comment les membres de l'équipe travaillent avec Branch. 76. Scénario réel pour travailler avec Branch: Comprenons le travail avec les succursales en utilisant un scénario réel, vous pourrez comprendre plus clairement sans perdre de temps. Ce n'est pas un exemple, c'est une histoire vraie. Lorsque j'ai rejoint ma première entreprise, j'ai eu l'opportunité de travailler sur une fonctionnalité, savoir le design de la page d'accueil. Pour cette fonctionnalité, je dois travailler avec Unati et elle est l' employée actuelle de cette entreprise Nous devons concevoir la page d'accueil du site Web de l'entreprise. Cette société créait un site Web comme stackoverflow pour les problèmes Elle m'a dit qu'elle travaillait sur la conception des cartes de questions et que je devais travailler sur l'en-tête, pied de page et la section de la barre latérale Tout d'abord, elle a créé une nouvelle branche appelée feature Ss Home Page, et elle a commencé à travailler sur la conception de cartes Qi. Mais là, je n'en ai aucune idée. Que se passe-t-il ici ? Comment puis-je travailler avec Branch ? Je connais les bases de Git, mais je n'ai pas d'expérience réelle. Je clone d'abord le projet depuis Github et j'exécute d'abord la pull request pour obtenir les dernières modifications depuis le dépôt distant Je commence également à travailler sur la même fonctionnalité que la branche de page d'accueil Sless Nous travaillons tous les deux de manière indépendante sur la même branche. Maintenant qu'elle en a fini avec son design, elle s'est engagée à coder, puis à transférer les modifications vers le référentiel distant. Maintenant elle me dit qu' elle a poussé le code. Encore une fois, je fais une demande obtiens les dernières modifications et je les fusionne avec mon code. Maintenant, au bout d'un certain temps, je suis prête à créer mes créations, alors j'insiste sur les modifications et je l'en informe. Elle exécute git pull request et le fusionne avec son code. Après 5 heures passées à faire ce pull and push, nous en avons terminé avec la conception de la page d'accueil. Enfin, j'impose tous les changements et je le lui dis. Elle apporte toutes les modifications à la branche, et en cas de conflit , nous nous contactons pour résoudre le problème. Maintenant, ce code est testé et notre responsable passe en revue le code final. Si tout va bien, alors ce code est fusionné dans la branche principale ou rebase ou squash kms, quelle que soit la meilleure option Ensuite, cette fonctionnalité supprime branche de la page d'accueil depuis la télécommande Au fur et à mesure que nous supprimons la branche du référentiel local. C'est le scénario de la collaboration, ou vous pouvez voir comment nous pouvons travailler dans la même branche en équipe. 77. Vitrine pratique du travail avec une succursale: Voyons la démonstration pratique du travail avec les branches. Vous vous demandez peut-être pourquoi je me concentre autant sur le travail avec les succursales ? Parce que c'est le concept le plus utilisé et le moins déroutant pour les développeurs, et c'est pourquoi je vous le montre étape par étape. Après avoir terminé ce cours, vous maîtriserez le travail avec les branches. Pour simuler cela, je vais vous montrer les deux œuvres de la Colombie-Britannique. Je travaille sur mon PC et je partagerai également l'écran depuis un PC Nati. C'est un PC Nats. Maintenant, dans ce projet, C crée une nouvelle branche. Nous avons vu précédemment comment créer une branche à l'aide de commandes, mais nous pouvons également créer des branches à l'aide de Github Ou ouvrez cette branche, dans le menu déroulant, et à partir de là, nous pouvons créer une nouvelle branche. Disons concevoir la page d'accueil et sélectionner, créer une branche à partir de la page principale et c'est fait. Nous créons notre nouvelle succursale et voyons ici que cette branche est à jour avec la principale La branche se trouve sur le référentiel distant. Nous devons le récupérer dans notre dépôt local. Ici, dans ce terminal, nous écrivons git fetch pour récupérer cette branche Vous voyez, nous avons ici la nouvelle page d'accueil de Branch Design Slash. Maintenant, je vais te montrer quelque chose. Si nous écrivons une branche Git, vous voyez, ici nous n'obtenons pas la nouvelle branche, mais nous pouvons voir Git trouver cette branche dans notre dépôt distant. Ici, nous écrivons la branche Git R. Ensuite, nous avons cette branche de suivi à distance. Lorsque nous exécutons Git fetch, nous obtenons toujours la branche de suivi à distance Nous créons maintenant une nouvelle branche privée dans notre dépôt local , puis nous la lions à la branche de suivi à distance. Pour cela, nous l'écrivons switch, C ou create ici nous écrivons le nom de notre branche locale, quel que soit le nom que nous voulons appeler. Nous pouvons l'appeler comme vous le souhaitez, mais la plupart du temps, nous l'appelons de la même manière que le nom de la branche de télésuivi. Nous n'avons donc pas besoin de nous en souvenir. Page d'accueil du design. Ensuite, nous devons écrire le nom de notre branche de suivi à distance, que nous voulons lier, qui est la page d'accueil d'Origin Design. Nous obtenons le nom de la branche de suivi à distance ici. Maintenant, si nous écrivons la branche git VV, C, nous obtenons la branche, et elle est également liée à la page d' accueil de Origin Design Slash Lorsque quelqu'un d'autre crée une branche et la pousse sur le dépôt, nous devons d'abord exécuter la commande fetch Nous obtenons ainsi la branche de suivi à distance, puis nous devons créer une branche locale et la relier à notre branche de suivi à distance en utilisant Kit Switch, C, le nom de la succursale locale et le nom de la branche de suivi à distance. Maintenant, nous pouvons valider nos modifications et les transférer à notre origine. J'ouvre donc ce référentiel dans le code VS, et ici je crée un nouveau fichier appelé index point DML, et j'ajoute simplement du code standard ici. Enregistrez-le et organisez simplement les modifications et validez ces modifications. Gated M, crée et indexe DML à points pour la page d'accueil. Transférons également les modifications à la télécommande. Git push, c'est fait. Voyons maintenant comment je travaille sur mon écran. Ici, nous avons notre dépôt sur mon PC. Si ce n'est pas le cas, nous devons cloner notre projet. Voyons d'abord toutes les modifications en utilisant git fetch. Si nous consultons notre journal, voyons que nous avons ici une nouvelle branche. Maintenant, je passe à cette branche en utilisant page d'accueil de Kit switch Design Slash Maintenant, avant de commencer à travailler sur notre code, il est toujours préférable de récupérer les modifications depuis la télécommande. Mais ici, nous récupérons simplement les modifications pour ne pas en avoir besoin, afin que nous puissions directement commencer à travailler dessus Ici, je fais quelques modifications dans le fichier script point js, enregistre les modifications. Imaginons maintenant que j'ai terminé mon travail sur cette branche. Mettons en scène les modifications et validons le code avec un message de validation, terminons le travail sur le fichier script js, je publie les modifications, Gate push. Maintenant, comme je vous l'ai déjà dit, fermeture de cette agence est de la responsabilité de la NATI. Revenons aux spécifications de la NATI. Ici, voyez d'abord, importer mes modifications à l'aide de Git pull. Bien. Ici, nous allons vite procéder à notre fusion. Regardons notre historique. Nous arrivons ici aux engagements. Nous avons maintenant notre code de succursale prêt et notre pointeur de page d'accueil de conception est également en avance sur la branche principale. Ici, nous devons fusionner notre code dans la branche principale. Nous l'avons fait tellement de fois, ici, nous revenons d'abord à la branche principale. Après cela, nous écrivons gate, merge, concevons la page d'accueil. voyez, ici, nous procédons rapidement à notre fusion car nous avons des branches linéaires. Mais ici, il n'y a pas de conflits. Parce que ce n'est qu'une démo. Très probablement à chaque fois, vous aurez des conflits, et nous savons déjà comment les résoudre. Vous devez donc le résoudre avec les membres de votre équipe. Maintenant, voyons ici notre journal. Nous pouvons voir maintenant notre pointeur principal et notre pointeur de page d'accueil de conception sont sur le même point. Mais Origin Min est sur le précédent. Nous devons donc appliquer les modifications au dépôt distant et savoir comment nous pouvons le faire, correctement, en utilisant Git push. Revoyons maintenant notre historique. Maintenant, Origin Min suit la même démarche. Maintenant, vérifions-le également sur Github. Va voir les gamètes. notre dernier Camite , Merge Gamit Maintenant que notre branche de page d'accueil de conception est fusionnée dans la branche principale, nous pouvons supprimer cette branche de page d'accueil de conception. Dans le cas contraire, cela créera de la confusion. Alors, accédez à la page d'accueil de ph D Origin and Design. C, branche supprimée du dépôt distant. Mais si nous voyons les branches, C, nous avons toujours la branche de la page d'accueil, nous devons donc également la supprimer. Obtenez la page d'accueil de la succursale D Design. Maintenant, notre succursale locale est également supprimée. Maintenant, revenons à mon PC, je vais d'abord extraire les modifications pour obtenir le commit de fusion. Maintenant, nous avons tous les deux le même historique de validation. Commençons par vérifier la branche de suivi à distance à l'aide de Git BanchR. Tu vois, je reçois la branche d'origine du design slash home. Jusqu'à présent, en supprimant la branche de suivi à distance, qui n' est pas disponible dans Remote, nous avons écrit Git remote Prune origin. Cette commande supprimera toutes les branches de suivi à distance qui ne sont pas disponibles sur le référentiel distant. Maintenant, permettez-moi de vérifier les succursales locales. Tu vois, je suis toujours là, je dois aussi supprimer la succursale locale. Encore une fois, la page d'accueil de git branch D Design, et là nous obtenons une erreur, ne peut pas supprimer la page d'accueil de la branche Design Slash car nous sommes actuellement sur la page d'accueil de Design slash, nous passons à la branche principale Porte telle que l'utilisation de la commande git pull pour mettre à jour la branche locale. Ici, nous procédons rapidement à notre fusion, et si nous vérifions notre historique, voyons ici que nous avons toujours cette branche de page d'accueil dédiée au design. Nous lançons la page d'accueil de git branch D Design slash, et la branche est supprimée C'est ainsi que nous travaillons en équipe avec les succursales. Vous êtes un peu confus, alors ne vous inquiétez pas, laissez-moi récapituler cette partie abord, nous créons une nouvelle branche , puis pour la pousser , nous devons définir une branche en amont. Il sait donc quelle branche locale est connectée à la branche distante. Ensuite, nous pourrons commencer à travailler sur la succursale. Si nous voulons pousser quelque chose, validons d'abord , puis nous pouvons le pousser jusqu'à l'origine. Mais avant de faire un push, il est recommandé d'utiliser le pull. Nous obtenons les dernières modifications et une fois le travail sur la branche des validations terminé, nous la fusionnons avec la branche principale, puis supprimons la branche de suivi à distance ainsi que la branche locale. Si la branche de suivi à distance est déjà supprimée par un autre membre de l'équipe, nous devons exécuter git remote, Prune origin et c'est terminé. 78. Créer des pull requests sur Github: Supposons maintenant que vous travailliez sur une branche et que, entre les deux parties du code, vous souhaitiez obtenir des suggestions de la part des membres de l'équipe. Ensuite, sur Github, vous pouvez accepter des suggestions ou ouvrir une discussion sur le sujet spécifique Dans ce cas, nous pouvons créer une pull request pour une discussion d'ouverture sur notre code. Demandez des suggestions ou des commentaires aux autres membres de l'équipe. Laissez-moi vous le montrer de façon pratique. Voici le NathiPC. Créons une nouvelle branche et introduisons les modifications dans cette branche. Tout d'abord, nous écrivons la page de questions-réponses Git switch Design slash. Ouvrons ce code dans le code du visa. Ici, dans le point d'index SDMLFle dans le corps, j'ajoute la balise main À l'intérieur, j'y ajoute Du, un autre DU et ici H une balise. C'est la première question. Il ne s'agit que d'une démonstration. Enregistrez ceci, communiquons et publions ces modifications. Dans notre terminal, nous écrivons étroitement AM en ajoutant une carte Q. Un Bien. Nous devons maintenant transférer ces modifications vers notre dépôt distant. Et comment pouvons-nous le faire ? On peut écrire « gate », « push ». Mais voyez ici, nous avons une erreur fatale. Peux-tu me dire pourquoi ? Oui, car nous n'avons pas défini de branche en amont. Ou, en termes simples, nous ne relions pas notre succursale locale à la succursale distante. Ici, nous écrivons simplement Git push u origin, ici nous écrivons le nom de notre branche locale, qui est la page de questions-réponses Design Slash et Ici, nous appliquons nos modifications en configurant la branche Upstream. Permettez-moi d'ouvrir ce compte sur le site Web de GitHub. Sur la page d'accueil, nous avons ici Design SQ et page, H DSN push, et nous obtenons également D compare et pull request Ici, nous pouvons ouvrir une discussion pour cette branche de page de questions-réponses et contributeur peut faire des suggestions ou discuter du code Nous pouvons également créer une pull request à partir de cet onglet de pull request. Cliquez sur New Pull Request. Ici, nous pouvons sélectionner deux branches pour comparer les modifications. La plupart du temps, nous sélectionnons la branche principale comme branche de base, et nous sélectionnons ici la branche de notre page de questions-réponses Vous voyez, nous avons ici les commits sur cette branche. Nous avons un commit, une modification de fichier, et nous avons également un contributeur. Ici, nous obtenons une liste de validations et en dessous, nous pouvons voir les modifications apportées à nos fichiers. Ici, nous pouvons également sélectionner une vue divisée, afin de voir très clairement l'avant et l'après. Ouvrons maintenant la discussion pour cette branche. Cliquez sur Create Pull Request. Ici, nous pouvons écrire le titre de notre discussion. Remplaçons-les en suggestions pour le téléphone par carte de questions. Ci-dessous, nous pouvons décrire ce dont nous voulons discuter, ce que nous voulons corriger, etc. Disons que nous ajoutons d'abord suggestions de titres nécessaires, puis des puces, suggérons des balises sémantiques pour la carte et donnons un aperçu de ce corps de code Maintenant, nous pouvons simplement créer une pull request ou nous pouvons également la rédiger. Passons à Create pull request. Vous voyez que nous sommes dans la conversation et que ce statut de pull request est ouvert. Maintenant, comment les autres membres de l'équipe peuvent-ils savoir que nous avons ouvert cette discussion ? Pour cela, nous devons les ajouter dans les réviseurs. Cliquez sur cette icône en forme d'engrenage, et voici la liste des contributeurs, que nous avons ajoutée dans notre référentiel au début de cette section. Nous aimons ce compte. Maintenant, au moment où nous sélectionnons l'utilisateur, Github envoie un e-mail à cet utilisateur pour lui indiquer qu' il a une nouvelle discussion Maintenant, permettez-moi de changer de fenêtre et de vous montrer comment ce membre de l'équipe peut revoir notre code. Voici donc mon compte original. Nous passons à la pull request et voyons ici que nous avons cette discussion. Ouvre ça. Vous voyez en haut, ici que nous recevons ce message. Cet utilisateur a demandé votre avis sur cette pull request. Cliquez donc sur ajouter votre avis. Ici, nous avons une vue divisée de ce fichier modifié. Si vous voulez voir le fichier dans son intégralité, nous pouvons cliquer ici, Tout développer. Maintenant, j'ai quelques modifications que j'aimerais suggérer. abord, dans ce tag principal, nous pouvons passer comme un article de section, puis H un tag, pas le simple de. Je veux aussi le dire classe pour article de carte de questions afin que les développeurs sachent que c'est une carte de questions. Ici, nous pouvons voir qu'avant chaque ligne, nous obtenons ces icônes plus. Nous pouvons ainsi rédiger une critique pour chaque ligne. Mais actuellement, je veux juste indiquer la hiérarchie du texte et le nom de la classe. Je clique donc sur cette icône en forme de plus, et nous écrivons notre critique ici. J'ajoute donc d'abord un point, ajoute une balise sémantique, une section principale, un article et un H, puis j' ajoute class equals to question underscore card à la balise article Et lancez simplement l'évaluation. Ici, nous pouvons voir l'examen et les détails. Il est actuellement en attente, et nous terminons simplement cet examen. Ici, nous devons écrire une description de base pour notre examen. Nous pouvons donc écrire ce sont les suggestions pour ce code, apporter les modifications et les appliquer. Maintenant, en bas, nous avons trois options. Tout d'abord, nous pouvons le soumettre sous forme de commande. Nous pouvons définir l'approbation et demander les modifications. Actuellement, nous demandons deux modifications Nous pouvons donc les sélectionner et simplement soumettre l'évaluation. voyez, nous sommes sur l'onglet conversation de cette pull request, et à partir de là, pouvons voir ce qui se passe ici en bas, nous recevons notre avis, qui est simplement soumis de manière très systématique. Et en dessous, vous pouvez voir que nous avons une demande de modification. A Sur le côté droit, nous avons cette icône, qui informe cet utilisateur lorsqu' il demande des modifications. Passons maintenant au compte nadis à partir duquel j'ai entamé cette discussion Tout d'abord, nous avons fait l'aperçu depuis l'onglet de conversation. Ensuite, nous apportons des modifications à notre code. J'ouvre donc le point d'index SDMLFle. Tout d'abord, je change cela d'abord en raison de la section et ensuite du en article. Si vous vous demandez comment je modifie simultanément les balises d'ouverture et de fermeture, vous devez installer l'extension Autor nam tag dans votre code VS, ce qui est vivement recommandé Nous devons également ajouter ici la classe à la carte de soulignement des questions Enregistrez les modifications, puis validez ces modifications. Donc, les balises sémantiques de GTMtam et la mise à jour du nom de classe Je sais que c'est un mauvais message de validation, mais c'est juste pour Alors insistons également sur ce point. Comme nous l'avons fait pour nos modifications, nous devons demander à ce membre de consulter nos modifications et de les vérifier. Sur le côté droit, nous avons cette option de révision des demandes. Cliquez dessus. Cela enverra à nouveau un e-mail à cet utilisateur pour lui demander de voir les mises à jour. Je passe à nouveau à mon compte, et je peux voir ici que cet utilisateur a demandé votre avis sur cette pull request. Cliquez sur Ajouter votre avis. Vérifiez nos modifications et si nous ne sommes pas satisfaits, nous pourrons à nouveau rédiger un avis et le soumettre. Ici, nous sommes satisfaits des modifications, puis nous pouvons cliquer sur Afficher et simplement cliquer sur ces modifications. Ici, j'écris, parfait, c'est fusionné dans notre branche principale. À partir du bas, nous pouvons sélectionner, approuver et soumettre un avis. Vous voyez ici que les modifications sont approuvées, et cette discussion remplit son objectif. Nous pouvons voir en haut que nous avons le statut des modifications approuvées. Maintenant, en bas, nous avons des options pour fusionner cette demande de pool Voici maintenant un débat sur le rôle du développeur lorsqu'il s'agit de fermer une demande de pool. Demandez qui doit fusionner cette pull request ? Celui qui a lancé cette pull request ou certains réviseurs devraient fusionner la pull request Certains développeurs optent pour cette première option car ils pensent que la personne qui lance la pull request en sait plus à ce sujet. Donc, celui ou celle qui a créé cette pull request doit la fusionner. Certains développeurs disent donc que la personne qui contribue à MR est le réviseur, le réviseur doit fusionner. Honnêtement, tu n'as pas à t'inquiéter à ce sujet. Interrogez simplement les membres de votre équipe ou votre responsable à ce sujet car certaines entreprises suivent première option et d' autres la seconde. Faites donc ce que suggèrent les membres de votre équipe. Nous pouvons fusionner cette pull request à partir d' ici et nous avons trois options pour la fusion, la fusion simple, le squash et la fusion, et rebasage et la fusion Nous connaissons déjà cette option, alors passons à une fusion simple, confirmons la fusion. Vous voyez, nous obtenons une pull request fusionnée et fermée avec succès. Nous pouvons maintenant supprimer cette branche d'ici. Nous pouvons restaurer la branche. Maintenant, laissez-moi passer au commutateur NathiPCF pour revenir à la porte do principale, puis appuyez pour obtenir le commit de fusion voyez, nous procédons rapidement à notre fusion et si nous vérifions notre historique, vous voyez, nous avons ici page de questions-réponses et une branche de suivi à distance Vous devez supprimer cette branche du local et également supprimer la branche de suivi à distance. Cette branche est donc déjà supprimée du dépôt distant, et nous voulons la supprimer de notre dépôt local, et savoir comment nous pouvons le faire. Nous pouvons écrire git remote, prune origin. Supprimons maintenant également cette branche locale. Branche Git D, page de questions-réponses de Designs et c'est fait. Vous pouvez voir si nous utilisons des commandes Git deux ou trois fois, cela ne nous embrouille pas. Comme je vous l'ai dit, tout est une question de pratique. Je sais que cette leçon est un peu longue, vous pouvez donc faire une pause de cinq à dix minutes, prendre l'air frais, puis continuer ce cours. 79. Résoudre les conflits lors des pull requests: Auparavant, nous avions vu que lorsque nous effectuons une fusion dans une pull request, nous n'avions aucun conflit. Mais que se passera-t-il en cas de conflit ? L'une des solutions est d'utiliser le code VS, mais c'est un peu long. Si nous effectuons une fusion dans notre branche locale, nous devons utiliser le code VS. Mais nous pouvons également résoudre les conflits à l'aide de Github. Cela n'est utile que lorsque nous fusionnons une pull request. Disons ceci. Tout d'abord, je crée une nouvelle branche à partir d'Una sur ce PC, je fais une démarche et je pousse ce Kat Page d'accueil des fonctionnalités de Get Swish C. Ici, dans le point d'index SDMLFle, je change le titre de la démo en titre de la page d'accueil Et modifiez également la première ligne du fichier script point Gs. Il s'agit d'un script pour la page d'accueil. Enregistrez les modifications et validons cette fonctionnalité Gtms AM, Update title and script for home Maintenant, publions cette branche sur Github. Tu t'en souviens ? Bien, utilisez Git Push pour configurer la fonctionnalité d'origine de la branche Upstream Slash sur la page d'accueil Maintenant, pour créer un conflit, j'ouvre un compte Github depuis mon PC et j'ouvre simplement point d' index STMLFle, nous sélectionnons Modifier et nous changeons ce titre en titre dans la Validons les modifications et poursuivons cette validation. Créons maintenant un autre fichier de conflit dans le script js. Nous changeons donc à nouveau la première ligne du script par branche principale et arrivons aux échanges Permettez-moi maintenant de créer une pull request. Rendez-vous donc sur Github et nous passons à la section pull request Ici, nous créons une nouvelle pull request. Base est la branche principale, et nous la comparons à la page d'accueil de la fonctionnalité SLS Vous voyez, ici, nous ne pouvons pas fusionner automatiquement. Ne vous inquiétez pas, vous pouvez toujours créer une pull request. Créons une pull request. Ici, il sélectionne automatiquement le message de validation, et nous pouvons écrire une description pour la pull request, pull request pour la page d'accueil de la fonctionnalité slash et créer une pull request Vous voyez, nous voyons que cette branche a des conflits qui doivent être résolus. Ici, nous pouvons utiliser la ligne de commande pour résoudre les conflits. Nous pouvons également le faire en utilisant Github. Il suffit de cliquer sur Résoudre les conflits. Ici, sur le côté gauche, nous avons la liste des fichiers en conflit. Ici, nous pouvons voir le conflit. Nous avons déjà vu ces indications. Je souhaite conserver le titre de cette page d' accueil. Si le conflit a disparu de ce fichier cliquez sur Marquer comme résolu pour ce fichier. Maintenant, pour le fichier suivant, je garde ici ce code de branche principal. Tu vois, tous les conflits ont disparu. Nous pouvons également marquer ce fichier comme résolu et simplement valider la fusion. Et vous voyez, maintenant cette branche n'est plus en conflit avec la branche de base. De plus, si vous souhaitez ajouter des réviseurs, nous pouvons également le faire, comme nous l'avons fait dans la leçon précédente Nous pouvons maintenant fusionner la pull request et confirmer la fusion. C'est ainsi que nous pouvons résoudre les conflits lors de la création d'une demande de fusion. 80. Créer des problèmes dans Github: Maintenant, dans Github, comme nous avons une fonction de pull request, nous avons également une option de résolution des problèmes Encore une fois, il s'agit de la fonctionnalité de Github, et non de Git. Quels sont ces problèmes ? Issues est comme les nœuds persistants que nous utilisons dans notre livre. Les nœuds persistants sont utilisés pour écrire des nœuds, corriger quelque chose ou écrire des questions, etc. même, nous pouvons utiliser les problèmes pour suivre les tâches, les bogues, ou nous pouvons également discuter de notre projet. Laisse-moi te montrer ça. Cliquez donc sur Nouveau numéro. Ici, nous pouvons écrire le titre de notre numéro. Disons, une discussion sur les fonctionnalités des cartes. Et ici, nous écrivons notre description de ce problème. Discutons des fonctionnalités de la carte de questions pour ce projet. Ici, nous pouvons également attester l'image de démonstration du design de base de notre carte Les pièces jointes sont très utiles. Si nous créons des problèmes pour résoudre les bogues, nous pouvons attester de la capture d'écran ou de l'enregistrement d'écran pour montrer les bogues Sur le côté droit, nous pouvons attribuer le problème aux membres de notre équipe. Pour l'instant, je viens d'ajouter un autre compte. Ensuite, nous avons des étiquettes. Github possède de nombreuses étiquettes pertinentes pour presque tous les types de problèmes Vous trouverez ici de la documentation sur les bogues, des doublons, des améliorations, un bon premier problème, non valide, une question et un correctif Vance Nous pouvons également créer nos propres étiquettes. Modifions ces étiquettes. Et créez une nouvelle étiquette. Nous pouvons donner une discussion sur le nom. À partir de là, on peut changer de couleur. Alors laisse-moi essayer quelque chose. Ouais. J'aime celui-ci et je crée une étiquette. Revenons maintenant à notre page. Et je sélectionne ce nouveau label. Ici, nous pouvons également lier nos projets. De plus, actuellement, nous n'avons pas de jalons. Nous verrons les étapes importantes dans la prochaine leçon. Pour l'instant, ne t'inquiète pas pour ça. De plus, actuellement, nous n'avons pas de pull request, sinon nous pouvons également relier le problème à la pull request. Et lorsque nous fusionnons cette pull request, tous les problèmes connectés se fermeront automatiquement et nous soumettrons un nouveau problème. Voyez ici que nous ouvrons ce problème. Les assignateurs vont maintenant commenter ce problème discuter de ce qu'ils pensent et formuler leurs suggestions Maintenant, après avoir terminé toute la discussion, nous pouvons également clore ce problème. C'est ainsi que nous pouvons résoudre les problèmes liés à Github. C'est pourquoi les développeurs adorent Github. 81. Ajouter des étapes dans GitHub: Maintenant, parfois, dans notre projet, nous voulons créer un jalon. jalon peut être considéré comme Le jalon peut être considéré comme un objectif à court ou à long terme, que nous voulons atteindre à un moment donné. Par exemple, dans notre projet, nous voulons ajouter une fonctionnalité d' authentification utilisateur. Nous pouvons donc créer un jalon et fixer une date pour terminer ce jalon. À cette étape, nous pouvons ajouter divers types de problèmes, tels que la conception de la page de connexion, la conception de la page d'inscription, la planification des options de réinitialisation du mot de passe, etc. Supposons que je règle ce problème de page de connexion à la conception, afin que je puisse marquer ce problème comme étant clos, et que nous atteignions 33,3 % de progrès Lorsque tous les problèmes liés à cette étape sont résolus , notre étape se déroule automatiquement. C'est très utile pour planifier, organiser et suivre l'avancement de nos projets. Voyons comment créer un jalon dans Github. Nous en sommes ici à la section des problèmes. En haut, nous avons l'option jalon. Nous n' avons actuellement aucun jalon, créez-en un nouveau Ici, j'écris le titre de cette étape importante. Disons l'authentification des utilisateurs. Ici, nous pouvons sélectionner le moment approximatif où nous terminons ce jalon, et enfin, nous pouvons écrire description pour décrire ce Implémentez donc les fonctionnalités d'authentification des utilisateurs, y compris les fonctionnalités d'inscription, de connexion et de réinitialisation du mot de passe, et nous créons une étape importante Voici notre liste de jalons. Ici, nous avons des informations de base sur jalon et ici nous pouvons voir nos progrès. Maintenant, pour vous montrer les progrès réalisés, ajoutons un problème à ce jalon. Accédez aux numéros et créez un nouveau numéro. Ajoutez ici le titre, le design, la page de connexion, ajoutez un assignerPour que nous puissions également nous attribuer nous-mêmes. Je sélectionne l'étiquette à améliorer et à partir de là, nous pouvons sélectionner le jalon. Vous voyez, nous avons ici un jalon d'authentification utilisateur. C'est une autre façon d' ajouter des problèmes dans Milestone. Donc pour l'instant, je viens de soumettre un nouveau numéro. Revenons maintenant à la page des problèmes. Ici, nous sélectionnons nos problèmes parmi tous les numéros ouverts. Et nous avons ici l'option des jalons. Ici, nous sélectionnons le jalon d'authentification de l'utilisateur et voyons, ici, nous obtenons le nom de notre jalon. Voyons notre étape importante. Nous pouvons constater que nous avons un problème en suspens dans cette étape importante. Cliquez donc sur le jalon et une fois le problème terminé, nous pouvons le sélectionner et le marquer comme un problème clos. Et voyez ici que notre objectif est atteint à 100 %. C'est ainsi que nous pouvons utiliser les jalons dans Github. 82. Flux de travail de projet open source: Jusqu'à présent, nous voyons comment nous pouvons travailler sur notre projet avec les membres de notre équipe. Sur Gitub, nous pouvons également travailler sur des projets open source. Voyons le flux de travail d'un projet open source. Par exemple, voici un projet open source auquel vous souhaitez contribuer. Il s'agit du projet sur mon compte Gitub, mais vous ne pouvez pas commencer à travailler directement sur ce projet car vous n'êtes pas ajouté en tant que contributeur, et c'est pourquoi vous ne pouvez pas non plus transférer votre code sur ce Quelle est donc la solution ici ? Comment pouvons-nous commencer à travailler sur ce projet ? Tout d'abord, vous devez ajouter ce projet dans votre propre compte Github C'est ce qu'on appelle créer un Fork. Nous avons maintenant un accès complet à ce dépôt. Maintenant, lorsque vous avez terminé votre contribution, vous pouvez transférer vos modifications dans votre dépôt. Ensuite, vous pouvez créer une pull request pour fusionner votre code. Et dès que vous créez une pull request, Github, envoyez-moi un e-mail Quelqu'un a créé une pull request pour ce projet open source. Je vérifie ton code. Si je veux vous faire quelques suggestions, je vous les donnerai et lorsque je serai satisfait du code, je pourrai fusionner ce code dans mon projet directement à partir de votre demande de pool. Ici, vous ne pouvez pas fusionner les modifications dans mon dépôt car je suis le seul à pouvoir les transférer à mon projet. Pour résumer, nous trouvons d'abord les projets open source sur lesquels vous aimez travailler. Ensuite, nous formons ce dépôt. Cela ajoutera ce projet open source à votre compte Github Lorsque vous avez terminé vos modifications, vous pouvez les appliquer à votre projet pour examen final, vous pouvez créer une pull request. Maintenant, l'auteur de cette demande vérifie votre code, donne quelques commentaires sur votre code ou vous suggère d'apporter des modifications, puis simplement fusionner ce code dans son projet open source. C'est ainsi que nous pouvons travailler sur le projet open source. Dans la prochaine leçon, nous allons voir cela dans la pratique. 83. Comment travailler sur un projet Open Source: Ainsi, lorsque nous voulons contribuer à un projet, vous pouvez rechercher ici le référentiel. Supposons que je veuille travailler sur la fonctionnalité de recherche dans React. Je recherche donc ici React Search. Ici, nous obtenons la liste des référentiels, et c'est ainsi que nous pouvons trouver le référentiel Et dans ce référentiel, les développeurs ont ajouté des problèmes qu'ils soumettent à discussion ou à contribution. Vous pouvez travailler sur ce problème spécifique. Ici, je sélectionne mon propre projet, que j'ai créé il y a trois ans. Et ici, nous pouvons voir que j' ouvre également un numéro pour ce référentiel. Maintenant, ce dépôt est validé par mon ancien compte, pas par le compte Cod bless you. Et dans ce navigateur, je me suis connecté à Cod blessu afin de pouvoir contribuer à ce projet Maintenant, la première étape pour travailler sur projet open source est de bifurquer le référentiel dans notre compte. Donc, sur le côté droit, il suffit de cliquer sur cette icône en forme de brouillard. Ici, nous pouvons modifier ces détails si nous voulons et simplement cliquer sur créer Fog. voyez, ici, nous obtenons la copie de ce dépôt et nous pouvons voir brouiller par rapport au dépôt d'origine. Ici, nous pouvons voir que cette branche est à jour par rapport à notre branche de dépôt d'origine. Nous pouvons maintenant fermer ce dépôt notre machine et commencer à travailler dessus. Laissez-moi vous le montrer pour ne pas vous y perdre. Copiez ce lien vers le dépôt et ouvrez le terminal dans lequel vous souhaitez ajouter ce projet. Ici, nous écrivons Git clone et collons le lien du dépôt. Bien. Allons dans ce dossier et créons une nouvelle branche ici. Obtenez le switch en tant que C design Home et ouvrez-le dans le code VS. Ici, je fais un petit changement dans le fichier app point JS. Enregistrez les modifications, puis validez ces modifications. Alors, Git, arrive à 8 h 00. Mettez à jour le fichier F. Et pour développer cette branche, première fois que nous écrivons Git push U pour Upstream Origin Design Home. Bien. Maintenant, lorsque nous avons terminé nos mises à jour, nous revenons à notre référentiel, actualisons la page. Vous voyez, nous avons ici cette maison design Harris and Push. Nous pouvons donc comparer et extraire la demande, comme avant. Mais voici une petite différence. Nous comparons notre branche d'accueil de conception à notre référentiel fog, et nous la comparons avec cette branche principale du référentiel d'origine. Ici, nous pouvons écrire un titre pour la pull request, et nous pouvons également écrire une description. Pour l'instant, je sélectionne directement Create Pull Request. voyez, ici, nous avons créé une demande de pool, et dans ce cas, nous n' avons aucun conflit. Mais voici une chose. Nous ne pouvons pas fusionner cette demande de pool, seul le responsable ou le propriétaire peut la fusionner Ainsi, à partir de mon ancien compte, je peux accepter les modifications et implémenter dans ce référentiel principal. Voici mon ancien compte, qui est le propriétaire de ce dépôt, et ici nous pouvons voir une pull request. Ouvrez-le et nous pouvons voir ce lit depuis le bas, voir ici ce compte, get merge, pull request, so merge pull request, et confirmer la fusion. Cette modification est ajoutée dans le référentiel principal. C'est ainsi que nous contribuons à un projet open source. 84. Synchroniser local et fork avec le référentiel de base: Lorsque nous forgeons un dépôt, ce dépôt fog n'est pas vraiment connecté au référentiel de base. Ainsi, lorsque nous travaillons dans ce dépôt de brouillard sur ce référentiel de base, quelqu'un peut valider les modifications. À ce moment-là, nous devons synchroniser le brouillard avec ce référentiel de base. Mais comment pouvons-nous le faire ? C'est vraiment simple. Nous allons donc au référentiel Fog. Vous voyez, nous voyons que cette branche est deux branches en retard par rapport à la branche du référentiel de base, ce qui signifie qu'il y en a deux se produisent après notre code actuel. Donc, sur le côté droit, nous avons l'option sync fog. Ici, nous pouvons comparer ces modifications ou simplement mettre à jour la branche. Ensuite, nous avons une branche à jour ici. Nous pouvons donc simplement le récupérer dans notre dépôt local. Alors lancez git, fetch. Vous voyez, nous avons ici un nouveau commit. Maintenant, nous pouvons simplement le fusionner avec notre commit principal. Tout d'abord, nous allons passer à la branche master. Bien. Actuellement, nous sommes sur la branche Master, et nous écrivons git merge origin master. Et c'est fait. Nous avons toutes les modifications dans notre dépôt local ainsi que dans notre dépôt fog. C'est très simple et il s' agit de travailler sur un projet open source. n'y a pas de science farfelue pour cela, nous devons le pratiquer deux ou trois fois. 85. Outils de collaboration dans VS Code: Voyons maintenant quelques outils de collaboration dans le code VS. Donc, dans notre projet, nous pouvons voir ici que nous sommes actuellement dans la branche principale. Permettez-moi de passer à l'autre branche. Maintenant, laissez-moi vous montrer comment nous pouvons transférer le changement à notre télécommande. Donc, dans le fichier Read Me, je change ce titre, disons, en commençant avec VSCode Enregistrez ceci, et maintenant nous passons au contrôle de source. Rédigez un message de validation, mettez à jour Read me pour VSCode et Commit Maintenant, nous pouvons voir que nous obtenons l'option de synchronisation des modifications. Et si nous survolons cela, alors il est écrit «  push one commit to Origins Design slash home Donc, à partir de là, nous pouvons également pousser. De plus, si nous cliquons sur ces trois points, nous obtenons également l'option push. Avec cela, nous avons également accès à des options de pull, clonage, de paiement, de fetch et bien d'autres options intéressantes Par exemple, si nous passons aux CD, ici, nous pouvons effectuer un commit normal, valider uniquement les fichiers de stage, valider, annuler le dernier commit et aussi rebase Nous avons les options changes, pull, push, branch , remote, stairs, tags et presque toutes les options souvent utilisées dans git. Je ne veux pas vous ennuyer en vous montrant toutes les options. Nous avons déjà vu ces options en ligne de commande. Donc ici, je fais un simple push. Et c'est fait. Nous publions les modifications. J'utilise ces options lorsque je ne veux pas ouvrir le terminal. Sinon, j'aime utiliser ligne de commande car c'est plus clair pour moi et je n'aime pas non plus utiliser la souris lorsque je code. Je ne sais pas pourquoi. Si vous souhaitez utiliser ces options, c'est également très bien. Cela dépend vraiment de votre choix personnel. Je ne suis personne pour te dire d'utiliser ceci ou de ne pas l'utiliser. C'est à toi de choisir. Toujours dans le panneau de contrôle des sources en bas, nous pouvons voir nos comètes, nos branches, nos télécommandes, notre stase, nos tags, notre arbre de travail, et en bas, nous obtenons la liste des contributeurs de De plus, à partir de là, nous pouvons ajouter un contributeur. Si vous ne souhaitez pas utiliser le site Web Github. 86. Collaboration en utilisant Github Desktop: Voyons maintenant les options de collaboration dans l'application de bureau Github Ici, je change également le titre du fichier Read Me pour démarrer avec l'application de bureau Github Enregistrez ceci et laissez-moi le valider avec un message, mettre à jour, lire le fichier pour Github Dextop Bien. Passons maintenant à l'application de bureau Github Actuellement, notre projet de dépôt fog n' notre projet de dépôt fog ouvert dans l'application de bureau Github, je dois donc l'ouvrir Je vais donc au fichier, ajoute un référentiel local, je choisis le chemin de mon dossier et j' ajoute un référentiel. Voyez ici que nous obtenons directement l'option push origin. Vous pouvez également ouvrir ce projet sur Github en utilisant ce bouton. Outil très utile. Maintenant, en haut, nous avons le dépôt actuel. Après cela, nous avons la branche actuelle, puis nous pouvons voir que nous avons appuyé sur le bouton d'origine, et en dessous, nous avons des détails sur Fetch Dans le monde réel, lorsque nous sommes prêts à appliquer nos modifications, il est recommandé de commencer par les extraire de l'origine. Donc, sur le côté droit, nous avons un bouton. Vous voyez ici que nous obtenons l' origine du patch. Cliquez dessus. Et si nous avons des modifications, elles sont enregistrées dans notre dépôt. Et s'il y a un conflit, alors avant d'aller plus loin, nous pouvons le résoudre. Et ainsi, nous n'avons pas besoin d'appuyer à nouveau sur Merge kat. En utilisant cette pratique, nous pouvons nettoyer l'historique de notre chat. Maintenant, en haut, nous avons le menu du dépôt, dans lequel se trouvent de nombreuses options de base pour git, comme push, pull, fetch, remove, et en bas, nous obtenons les paramètres du dépôt J'aime cette option uniquement parce qu' ici nous pouvons facilement modifier notre dépôt distant. Ces options sont donc très similaires dans le code VS. amusant, c'est que le code VS a beaucoup plus d'options que l'application de bureau Github Et c'est pourquoi je vous dis bureau Github est une application simple, basique et conviviale pour les débutants Passons simplement à l'origine et c'est fait. Maintenant, nous pouvons voir ici que nous pouvons prévisualiser la pull request, et que nous pouvons également créer une pull request. Et lorsque nous créons une nouvelle pull request, nous pouvons la voir sur notre page de dépôt. Nous allons maintenant voir d'autres options dans la prochaine leçon utilisant le crack et l'application Git. 87. Collaboration avec GitKraken: Voyons maintenant les outils de collaboration utilisant Git Kraken. Tout d'abord, dans Git Kraken, nous devons ouvrir ce dépôt de brouillard car il n'est actuellement pas ouvert Accédez donc au fichier, OpenRPO ici, nous sélectionnons le référentiel Opener et sélectionnons notre dossier de référentiel Maintenant, nous pouvons voir que nous sommes actuellement sur la branche Design SLeSome Sur le côté gauche, nous pouvons voir le nom de la branche locale, les télécommandes, la pull request actuellement active, qui est zéro Nous pouvons également créer une pull request à partir d'ici. Après cela, nous avons des problèmes, sélectionnez ici Github, et nous avons les problèmes Ici, nous pouvons également créer un nouveau problème et après cela, nous avons beaucoup plus d'options. Maintenant, je vais te montrer quelque chose de vraiment cool. Nous avons ici des référentiels. Ensuite, nous avons la liste des branches que nous voyons déjà dans la section précédente. Maintenant, après cela, nous avons quelques boutons qui sont très utiles. Tout d'abord, nous obtenons l'option Annuler, qui permet d'annuler la dernière couche Si nous survolons ce bouton, nous pouvons voir ce que fait ce bouton Nous annulons donc le dernier milieu. Tu vois, c'est parti. Laisse-moi refaire ça Après cela, nous avons le bouton de traction, et ici, dans le pull, nous avons de nombreuses options. Récupérez tout, tirez s'il est possible d' avancer rapidement, uniquement d'avancer rapidement et de rebaser Maintenant, après cela, nous avons le bouton-poussoir et ce bouton de branche pour créer une branche à partir du commit actuellement sélectionné. Ici, nous cliquons sur le nom de cette branche. Nous pouvons voir que nous recevons également une pull request, push set en amont, que nous définissons pour le push de la branche pour la première fois. Toujours en bas, nous pouvons lancer une pull request pour cette branche et bien d'autres options. Ici, nous n'avons pas beaucoup d'options car nous travaillons sur le référentiel fog et nous ne pouvons pas directement accéder au référentiel de base. Commençons la pull request. Ici, nous pouvons sélectionner notre succursale à partir de nos deux origines. Depuis notre dépôt fog, branche Design Home et comparez-la avec la branche Master de notre dépôt de base. Maintenant, nous écrivons ici, pull request title, donc la mise à jour lisez-moi dans Design Home. Ici, nous pouvons également écrire une description, et à partir de là, nous pouvons simplement créer une Pull request. Nous avons également la possibilité de continuer à éditer sur Github et de voir ici que nous obtenons le site Web de Github Cliquez simplement sur Créer une demande de pool. Et c'est fait. Si nous avons un conflit , nous pouvons le résoudre ici. Ensuite, à partir du référentiel de base, nous pouvons fusionner ces modifications avec le référentiel de base. Nous l'avons déjà bien vu. Maintenant, depuis mon deuxième compte, qui est l'auteur de ce dépôt, nous passons à la pull request. Ici, nous n'avons aucun conflit, nous pouvons donc le fusionner avec la branche. Et c'est fait. C'est ainsi que nous pouvons travailler avec les outils de corabation de Kraken Mais voici mon opinion personnelle. Si nous savons ce que sont push, pull, setting upstream, merge, rebase et tous les termes, alors utiliser la ligne de commande git est beaucoup plus facile que l'utilisation de l'interface utilisateur graphique Dans les interfaces graphiques, nous pouvons clairement voir l'historique. Mais pour ces options, je pense personnellement que la ligne de commande est une bien meilleure option. Vous pouvez ouvrir notre feuille de chit à tout moment et écrire cette commande. C'est aussi simple que ça. Nous n'avons pas besoin de trouver d'options ou d'ouvrir l' application de bureau Git Kraken ou Github en arrière-plan Au lieu de cela, nous pouvons simplement utiliser Git Bash ou le terminal VS code Tout tourne donc autour de la collaboration dans Git. J'espère que cette section vous apprendra beaucoup de choses. Après cette leçon, j'ai ajouté résumé en PDF et vous pouvez l' ajouter à votre fiche technique 88. Section 06 Historique de nettoyage et d'organisation: Bienvenue dans la dernière section du cours d'informatique ultime. Dans cette section, nous verrons comment nettoyer et organiser les aides à la marche Nous verrons donc faire des validations, récompenser les enfants, récupérer des validations perdues, supprimer des validations, modifier le message de commande, scinder, écraser, et bien plus encore En termes simples, nous allons réécrire notre historique des validations. Commençons donc cette section. 89. Réécrire l'historique des engagements: Maintenant, vous pouvez vous demander pourquoi nous devons réécrire notre histoire Si nous écrivons l'historique ou stockons l'historique de notre projet, c'est parce que nous voulons voir comment notre application évolue au fil du temps. Par historique, nous pouvons voir à cette date quelles sont les fonctionnalités que nous lançons, quels sont les bogues que nous corrigeons, qui a contribué à quelle fonctionnalité, et bien d'autres choses encore. Maintenant, imaginez qu'au moment où nous lisons notre historique, nous voyions un mauvais message de validation. Parfois, nous apportons de petites modifications, ce qui peut être fait en validations uniques, ou nous avons fait très gros amides dans lesquels nous implémentons deux fonctionnalités ensemble, ce qui n'est pas une bonne chose Parfois, nous pouvons vouloir supprimer les validations indésirables, puis à ce moment-là, nous devons réécrire notre historique des validations C'est pourquoi cette section est utile pour rendre notre histoire propre et organisée, ce qui est le signe d' un développeur professionnel. Maintenant, vous vous demandez peut-être si nous devrions réécrire l'historique des commits de projets distants ? La réponse est non. Nous ne devons pas réécrire les commits que nous envoyons à distance, car cela gâcherait notre projet pour les autres et nous nous retrouverions avec de gros problèmes Dans de nombreuses entreprises, seule l'autorité supérieure réécrira l'histoire Mais d'abord, il ou elle organise une réunion ou informe tous les membres de l'équipe sur la réécriture de l'histoire Mais en tant que développeur, nous pouvons réécrire l'historique des validations, qui sont locales et ne sont pas transmises à la télécommande réécrivant l' histoire, nous pouvons la rendre plus propre et plus organisée Dans la leçon suivante, nous allons commencer par établir l'historique des validations. 90. Annuler l'engagement dans les détails (RESET): Donc, tout d'abord, pour cette section, j'ai conçu un projet informatique appelé Course cartwis Vous trouverez le projet dans le dossier de ressources que vous avez téléchargé au début de ce cours. Vous pouvez donc ouvrir ce dossier dans le Git Bash ou dans le terminal Regardons l'historique de ce projet. Vous voyez, nous avons ici la liste des Commits. Ici, nous voulons annuler le médium. Nous l'avons déjà vu dans les sections précédentes, mais je veux juste m'assurer que nous ne ratons aucun sujet. Comme nous le savons, pour annuler le amid, nous utilisons la commande git reset, et cette réinitialisation comporte trois options, LSD soft, LSD mix, qui est la valeur par défaut et hard Laissez-moi vous expliquer chacune des options une par une. Imaginez donc qu'il s'agit du code de notre répertoire de travail et que nous voulons stocker ce code dans notre historique Git. Tout d'abord, nous organisons nos modifications, puis nous procédons à la validation. Maintenant, après un certain temps, nous travaillons sur correction d'un bogue dans la conception de la mise en page. Nous organisons à nouveau les modifications et les validons. Maintenant, nous voulons annuler le commit B et revenir au commit A. Si nous écrivons git reset the soft head till one, Git annulera le commit dans l'historique de git. Ici, nous obtenons le commit A, mais il ne touchera pas notre code de répertoire de travail ni notre code de zone de transit. Ils resteront les mêmes qu'avant. Tu sais que la situation actuelle est de quelle condition ? Lorsque nous apportons des modifications au répertoire de travail et que nous les organisons, mais que nous ne les validons pas. Supposons maintenant qu'à la place du logiciel, nous écrivions mixé, puis cela annulera notre dernier commit en cours pour le remplacer par un, qui est un commit dans l'historique des validations. Il remplacera également notre code de zone de transit par un code Com A. Mais cela ne touchera pas le code du répertoire de travail. Savons-nous que cette condition est de quelle condition il s'agit ? C'est vrai. Lorsque nous apportons des modifications au répertoire de travail, mais que nous ne les mettons pas en scène, vous vous en sortez vraiment très bien. Maintenant, si nous écrivons Dash en dur, toutes les zones de la tête seront annulées jusqu'à une, c'est-à-dire une zone avant la validation de la tête, qui est A. Connaissez-vous cette condition ? C'est vrai. Lorsque nous faisons simplement le Commit A, tout notre code est dans l'état précédent. Voyons ces options en action. Supposons que nous voulions annuler notre dernière validation par rapport à la précédente. Voyons d'abord ce que nous avons fait dans ce commit. Get show Commit reference, qui est head. Voir ici dans ce commit, nous changeons le style du fichier CSS à points. Et nous ajoutons ici ces lignes de code. Donc d'abord, nous écrivons git reset, da di soft. Ici, nous écrivons notre comité has ou pointeur sur lequel nous voulons nous déplacer Donc, il, qui est le Camttll actuel, qui est un commit avant ce match Sachez que cela n'annulera que le commit dans l'historique des validations. Ne touchez pas à notre répertoire de travail et ne touchez pas non plus à la zone de transit. Notre zone de transit contient donc ces lignes, mais notre interface est rétablie à la version précédente Nous pouvons donc le constater en faisant la différence entre la zone de staging et le commit. Pour cela, nous avons la commande Git df das cast. Tu vois, ici, nous avons ces lignes. Maintenant, écrivons git reset, dd mixed, add till one. commande annulera la commande en cours jusqu'à une commande et annulera également les modifications Ici, à partir de cette commande, si nous supprimons ce test comme mixte, alors par défaut, nous utilisons le test comme mixte. Nous pouvons vérifier cela en observant la différence entre la zone de travail et la zone de transit. Nous pouvons utiliser Git status, ou nous pouvons également utiliser GTF. Tu vois, c'est là que nous voyons cette différence. Voyons maintenant la dernière option, qui est la réinitialisation, il y a cette tête dure jusqu'à un. Maintenant, tout le code sera réinitialisé à cette tête jusqu'à un. Maintenant, si nous voyons le DF voir, nous n'avons aucune différence ici car toute la zone est réinitialisée pour se diriger vers une comète. Ici, nos trois derniers commits ont disparu car nous exécutons la commande de réinitialisation trois fois. C'est ainsi que nous pouvons annuler le commit pour un commit spécifique. 91. Inverser les engagements: Dans la leçon précédente, nous verrons comment défaire le manteau. Voyons maintenant comment inverser les amides. Imaginez que nous ayons deux amides dans notre histoire, que nous avons publiés sur GitHub Maintenant, nous ne pouvons pas annuler ces amides et les pousser à nouveau. Il correspondra au code de tous les membres de notre équipe. Dans ce cas, nous utilisons la commande revert, ce qui signifie que nous pouvons annuler les modifications apportées en omettant B et créer un nouveau Revenir signifie revenir à la version précédente, mais sans emballer les amides précédents Voyez cela de façon pratique. Nous avons donc ici l'historique de nos validations, et je souhaite annuler les modifications apportées par cette troisième comète. Imaginaire, nous pensons que tout cela est envoyé à la télécommande, nous ne pouvons donc pas utiliser git reset. Nous utilisons donc ici Git reword et ici nous écrivons la référence Commit, modifications de validation que nous voulons annuler, c' est-à-dire cette tête de Camt à Si nous écrivons tête baissée, cela annulera les modifications apportées par le second Cate. Ici, nous pouvons également annuler plusieurs validations avec une seule comète. Si vous voulez annuler toutes les modifications apportées par cette gamme spécifique de comètes, nous pouvons écrire quelque chose comme ceci Tout d'abord, nous écrivons la référence du commit, un commit en dessous , soit il jusqu'à quatre. Double point, ici nous écrivons le dernier commit, qui est head. N'oubliez pas que quel que soit le commit que nous écrivons en premier, il faudra des commits après cette couche jusqu'au dernier commit. Cette commande annulera les modifications apportées par ces quatre validations et créera quatre nouvelles mises. Maintenant, Git demande un message de validation pour chaque nouvel amide de récompense. Je ne veux pas modifier le message de validation, donc je ferme simplement chaque fichier et c'est fait. Regardons maintenant notre historique. Tu vois, ici, nous obtenons quatre Camts en récompense. Maintenant, comme nous pouvons le constater, inverser plusieurs amides complique notre histoire Existe-t-il une autre solution pour nettoyer ce gâchis ? Oui, il y a une pause. Au lieu de créer ces quatre comètes de récompense individuellement, nous pouvons annuler ces modifications et les attribuer à une seule comète Alors d'abord, retirons ces quatre médicaments. Nous n'en voulons pas. Ici, nous pouvons utiliser la réinitialisation car ces quatre amides ne sont pas placés dans le dépôt distant Nous allons donc utiliser les réinitialisations de porte de manière intensive et indiquer où nous voulons déplacer la tête Bien, nous voulons déménager ici. Donc, lui, c'est la tête vers un, la tête vers deux, jusqu'à trois jusqu'à quatre. Alors dirigez-vous vers quatre heures. Regardons maintenant notre historique. Tu vois, ici on annule ces quatre ametes. Inversons à nouveau ces quatre comètes, mais nous ne créerons qu'un seul gamète Nous écrivons Git, revert, dn, das amet et ici nous écrivons notre référence Kameit Dirigez-vous vers quatre points doubles. Ici, nous n'obtenons rien, mais nous pouvons voir que nous sommes en train de revenir en arrière Actuellement, git annule toutes les modifications apportées à ces quatre commandes et les place dans la zone de préparation. Nous pouvons vérifier qu' en utilisant git status S. S, nous obtenons ici trois fichiers avec D, qui est supprimé, un avec modifié et également tamp qui n'est pas suivi Nous annulons les modifications apportées à la zone de transit. Si vous souhaitez suivre les modifications ou apporter d'autres modifications, nous pouvons le faire ici. Actuellement, nous ne voulons rien faire, nous pouvons donc écrire Get revert Ici, nous avons deux options. Il s'agit d'annuler le retour, ou nous pouvons continuer le retour, ce qui nous amènera à effectuer ce retour en un clin d'œil Nous continuons à recevoir un message de validation. Ici, nous n'avons que le dernier message de validation inverse. Nous pouvons écrire ici, revenir en dernier pour Coit pour la dégustation. Enregistrez ce fichier et fermez-le. De retour au terminal, voir retour en arrière effectué. Et dans l'histoire, nous ne recevons également qu'une seule reformulation à. Maintenant, comme vous pouvez le constater, nos trois dossiers ont disparu. Donc pour l'instant, nous l'avons à nouveau réinitialisé à parce que je voulais juste vous montrer la démo de Revert, mais nous aurons peut-être besoin de ces Camtes à l'avenir Alors réinitialisez-vous, il y a une tête dure jusqu'à ce que tout soit prêt. Dans la leçon suivante, nous allons voir p log. 92. Reflog pour récupérer les engagements perdus: Maintenant, imaginez que dans notre code, nous réinitialisions mystiquement notre code jusqu'à trois heures Ici, nous pouvons consulter l'historique de nos comètes. Tu vois, on a perdu nos trois premiers sets. Et si nous voulions récupérer ces amets ? Maintenant, vous pourriez dire que nous l'avons perdu à. Comment pouvons-nous le récupérer ? Dans Git, on ne perd vraiment rien. Stockez-les dans le dépôt et lorsque ces comètes perdues restent absentes pendant une longue période, seul Git les supprime Si nous réinitialisons notre code par deux étapes, Git ne supprimera pas immédiatement ces comètes Ici, nous exécutons Git Rf log, qui est la forme complète du journal de référence. Cette commande affichera la référence de notre pointeur principal par défaut. En gros, cela nous montrera comment notre pointeur se déplace au cours de notre histoire. Oh, qu'est-ce qu'on vient de voir ? Ressentez-vous autant de confusion ? Je plaisante, c'est tout. C' est vraiment simple. Laissez-moi vous expliquer cela. Cela montre simplement comment notre pointeur principal se déplace. Dans un premier temps, nous obtenons le commit a, puis nous obtenons l' identifiant de l'unité pour ce point, puis nous obtenons la description de cette action. Au tout début, j'ai prélevé dix gamètes en ligne droite À chaque gamète, notre tête bouge. Ensuite, dans la première leçon, nous exécutons cette commande git reset trois fois. Ensuite, nous avons fait marche arrière quatre fois, puis réinitialisé, Camt et Ce qui est bien, c' est que nous avons toutes les comètes ici. Et dans cette leçon, nous avons également réinitialisé Lee par erreur. Il suffit donc de déplacer notre pointeur principal vers cette référence précédente et nous avons retrouvé la comète perdue. Alors, réinitialisez-le, c'est dur. Ici, nous écrivons notre référence approximative au journal ou nous pouvons indiquer cet ID de validation, ou nous pouvons également utiliser cet ID de validation. Tête en calibres. Maintenant, si nous vérifions l'historique de nos validations, voyons que nous récupérons nos Cumms perdus Ce que nous en apprenons Lorsque nous exécutons la commande git reset, Git ne supprime pas réellement ces comètes Il suffit de déplacer Headpointer et placer ces validations quelque part dans l'historique Si pendant longtemps nous ne touchons pas à ces commandes, seul Git les supprimera. C'est ainsi que nous récupérons nos commandes perdues en utilisant f log. Maintenant, la seule question que me posent de nombreux étudiants est la suivante : pouvons-nous voir uniquement le journal de référence du pointeur ou nous pouvons voir n'importe quel journal de référence des pointeurs. Vous avez raison avec la commande Git flog, nous pouvons voir n'importe quel journal Vous avez raison avec la commande Git flog, de référence des pointeurs Actuellement, nous n' avons aucune succursale. Je vais vous montrer le log f de ce pointeur principal. Git flog show, et ici nous écrivons le nom de notre pointeur, qui est master Nous avons une branche appelée feature cart, puis nous écrivons ici feature s cart. Voyez ici que nous obtenons le journal de référence pour le pointeur principal. C'est la même chose que HeadPointer car ils évoluent ensemble au cours de cette histoire. Maintenant, nous voyons toutes les références ou nous pouvons voir l'historique complet. Et si nous voulions ne voir que les cinq derniers instants de notre pointeur principal ? Nous pouvons simplement écrire ici N espace. Ici, nous en écrivons cinq. voyez, ici, nous n'avons que cinq derniers instants de notre pointeur principal. C'est très utile, tout tourne autour du journal de référence. Dans la leçon suivante, nous verrons comment modifier les comi existants 93. Modifier l'engagement récent: Voyons maintenant la commande de modification. Modifier signifie donc corriger. Nous pouvons corriger notre commande récente sans créer de nouvelle commande. Laisse-moi te montrer. Donc, ici, dans le fichier index point ML, nous changeons simplement le titre en Cartwig Modern Ecommerce store Enregistrez les modifications moins ces modifications et validez cette modification avec un message de validation, mettant à jour le titre de l'application. Maintenant que nous avons terminé notre Commit, et dans notre titre, je trouve que nous devons mettre ce W en majuscule dans orthographe Cardi et que nous voulons également ajouter un trait d'union entre E et commerce Ici, nous ne voulons pas créer une nouvelle Camt pour ce petit changement Ici, nous pouvons utiliser la commande de modification. Nous apportons des modifications à notre titre, enregistrons ce fichier et enseignons ces modifications. Pour Gamat, nous écrivons Gate KamiTF amendé, nous ajoutons simplement amendé Nous écrivons ici notre nouveau message de validation. De plus, si vous souhaitez utiliser le même message de validation que le message de validation précédent, nous n'écrivons rien ici. Vous voyez, nous avons ici le message de validation précédent. Fermez ceci et c'est fait. Nous mettons à jour notre dernier commentaire. Si nous voulons vérifier ce que nous avons changé lors de notre dernier Commit, nous pouvons écrire Git show. Vous voyez, ici, nous avons le titre mis à jour. Maintenant, une chose que je veux clarifier c'est que get ne met pas vraiment à jour le dernier Commit. Crée officiellement une nouvelle commande car les validations Git sont immuables, ce qui signifie que si nous en créons une, Git ne peut pas la modifier Mais ici, cela montre qu'il modifie le dernier commit. Maintenant, que se passe-t-il si nous voulons ajouter un fichier dans le commit précédent ? Pour cela, nous devons suivre le même processus que celui que nous venons de faire . Ici, dans notre projet, nous créons un nouveau fichier, nous supprimons point js et à l'intérieur, nous y ajoutons simplement le journal point log de la console Il s'agit d'un fichier de script. Enregistrez ce fichier et revenez dans Git Pass où nous mettrons en scène nos modifications. Nous pouvons simplement utiliser Git commit, dd, amender. Ne changeons pas le message de validation. Maintenant, examinons notre dernier commit. Maintenant que nous ajoutons un nouveau fichier dans notre dernier commit, comment pouvons-nous supprimer le fichier ? C'est un peu délicat. Pour cela, nous utilisons d'abord la réinitialisation, et ici nous utilisons l'option mixte DDs parce que nous voulons juste réinitialiser notre historique de validation, et nous le réinitialisons depuis stage. Notre répertoire de travail restera le même qu'avant, zone d' enseignement et le commit seront réinitialisés Alors réinitialisez-vous, tout comme Mixed, dirigez-vous vers un. C, nous annulons les modifications, et dans le fichier STML à points d'index, nous obtenons notre titre Nous pouvons donc supprimer ce fichier temporaire et maintenant nous pouvons échelonner nos modifications Ensuite, au lieu d' utiliser Git commit, amend, nous utilisons un commit simple car nous réinitialisons notre dernier commit et lui donnons également un message, mettant à jour le titre de l'application créant un fichier script et c'est fait. C'est ainsi que fonctionne la commande d'amendement. Et si nous voulions modifier l'un de ces commits, et nous le verrons dans la prochaine leçon ? 94. Modifier n'importe quel engagement dans l'historique: Ainsi, dans la leçon précédente, nous verrons comment modifier notre dernière comète. Mais que se passe-t-il si nous voulons modifier un article précédent ? Disons cela dans les styles pour le corps STML de l'index. Dans ce contexte, nous voulons changer la couleur de fond de notre corps. Alors, comment pouvons-nous le faire ? C'est vraiment simple. Voyons d'abord ce que nous changeons dans ce manteau. Donc, Git show d35, CB 01. voyez, ici, nous pouvons voir que nous ajoutons du style au corps, mais je veux changer cette couleur d'arrière-plan. Ici, nous allons utiliser la commande rebase. Laissez-moi vous expliquer ce que font les commandes de base. Imaginons que nous ayons six validations A à F, et que nous voulions changer de commit, disons C. Nous devons rebaser en commit B car la base de commit C est une validation B. Donc, ici, nous apportons des modifications à notre commit C, et comme nous le savons, les commits Git sont immuables Git ne peut pas modifier le commit. Git crée un nouveau commit contenant nos modifications, puis le rebase avec le commit B. Vous vous demandez peut-être comment Git peut remplacer le commit C par le commit C ? Et qu'en est-il des commits D, E et F ? La réponse est que Git ne remplace pas le commit C par C. Au lieu de remplacer le commit C, ici, Git create un commit, identique à ce commit D, mais ce commit comporte également la modification que nous faisons sur les CD. Si Git supprime cette modification lors du prochain commit, quoi cela sert-il ? C'est pourquoi Git Pi est exactement le même commit que le commit D, mais avec des modifications. Il en va de même pour le commit E et le commit F. Git supprime cette branche précédente, et c'est ainsi qu' en utilisant git rebase, nous pouvons modifier n'importe quel commit de notre historique Mais assurez-vous de ne modifier que les commits qui ne sont pas envoyés car rebase réécrit clairement l'historique Voyons maintenant le rebasage en action. Voici donc quel engagement nous voulons changer. Écrivez celui-ci. Nous copions donc l' ID de validation de sa base, qui est son précédent commit. Rappelez-vous toujours que pour le rebase, nous devons prendre la référence de validation précédente Maintenant, pour rebase, nous écrivons git rebase I pour Interactive. En gros, nous voulons le dire à Git. Nous voulons interagir ou apporter des modifications à nos commits. Et ici, nous écrivons notre commit de base, qui est 4239 CEC Regardez ici, dans notre éditeur de code, que nous obtenons ce type d'interface. Pour l'instant, nous n'utilisons pas cette interface car elle vous embrouillerait. Nous verrons comment utiliser cette interface dans les prochaines leçons. Ici, à partir du bas, nous sommes passés à l'option texte. Nous obtenons ici ce type de lignes. Ne t'inquiète pas. Ce ne sont que des scripts que git va exécuter, et ce sont tous des médicaments de notre ancien ordre de validation au plus récent Ici, au début de chaque amet, nous avons l'option PC, ce qui signifie que Git choisit simplement ces comètes dans l'historique et les rebase Et si nous voulions changer cette méthode ? Donc, au bas du fichier, nous avons de nombreuses options et une explication. Donc, pour modifier à l'endroit du pic, nous écrivons edit. Maintenant, nous ne voulons pas modifier d'autres amides, mais si nous le voulons, nous pouvons également écrire ici, modifier, enregistrer ce fichier, joindre les deux voyez, nous nous arrêtons ici à ce Camt pour le modifier, et actuellement nous sommes en train de rebaser l'un des cinq, et nous pouvons voir que nous pouvons modifier ce commit Maintenant, nous pouvons changer ce que nous voulons changer dans ce manteau. Donc, dans le fichier CSS style point, je veux changer la couleur de fond en blanc. Et la couleur a 101010. Enregistrez les modifications et goûtons-les. Et aussi Gt ka mate, dash, dash, amend. Désolé, c'est une faute de frappe. Donc, manteau, tableau de bord, tableau de bord, amendement. Nous continuons avec le message d'omission. Alors ferme ça. Maintenant, à ce stade, voyons l'historique. voyez, comme je vous l'ai dit, Git lance une nouvelle branche, et c'est notre base à. Et ici, en haut, nous avons notre amendement Camt mis à jour Maintenant, lorsque nous poursuivons ce rebase, Git choisit ces amides et les place sur ce Camt, puis supprime ces Maintenant, pour continuer ce rebasage, nous écrivons git rebase Ou si nous voulons parler, alors nous pouvons écrire à ce sujet. Pour l'instant, continuons cette rebase et nous n' avons aucune autre modification, Git termine rapidement ce processus Regardons maintenant notre historique. Ici, nous pouvons voir que notre histoire est à nouveau linéaire. Si vous observez, vous réalisez que identifiant de toutes les comètes est différent de celui des comètes précédentes Il est donc confirmé que Git crée de nouvelles comètes. Mais comme nous le savons, c'est pour organiser l'histoire. Maintenant, si nous voyons dans notre code, nous obtenons également ces modifications dans notre fichier CSS à points de style. Les modifications que nous modifions en ce sens que Camt sont également disponibles sur l' ensemble de ces amides C'est ainsi que nous modifions n'importe quel camd en utilisant git rebase I. 95. Comment abandonner un engagement complet: Il est utile de laisser tomber un chapeau entier lorsque nous engageons par erreur notre travail Mais lorsque nous lâchons une caméra, nous devons garder à l'esprit que nous rejetons toutes les modifications que nous avons apportées à cette comète nous devons garder à l'esprit que nous rejetons toutes les modifications que nous avons apportées à cette Dans notre histoire, nous avons ce travail en cours, ce que j'ai fait bimstakalement Voyons ce que je m'engage là-dedans à Gait, montrez à AC un 49c C'est ce que nous pouvons voir dans le fichier ML à points d' index. Au lieu de ce texte, nous ajoutons cette balise, et dans un fichier CSS de style, nous ajoutons ce style pour une section. Maintenant, si nous abandonnons cette commande , ces modifications seront supprimées. Donc, pour le drop également, nous utiliserons rebase. Dans notre exemple précédent, nous avons six validations, et si nous voulons supprimer ce commit C, nous utilisons la porte rebase I, et ici nous commençons par la base qui est Commit B. Ensuite, nous supprimons ce commit C. Ici, encore une fois, créez un nouveau commit pour les commit D, E et F, puis remplacez-les par Commit B, c'est une simple suppression. Et si dans ce commit C, nous créions un fichier appelé page DML Dans chacun de ces trois validations, nous modifions quelque chose dans ce fichier. Ensuite, nous arrivons à un conflit car lorsque nous supprimons Commit C, notre fichier pg ML sera également supprimé. Et dans nos autres validations, nous apportons des modifications au fichier DML point S de cette page Ensuite, il y a un conflit. Ne vous inquiétez pas, nous allons le résoudre car il utilise l'outil Merge. C'est également très simple. Je vous dis juste qu'un conflit peut survenir si nous abandonnons notre engagement. Dans notre exemple, nous avons ici ces modifications. Supprimons ce commit et voyons si nous avons un conflit ou non. Qu'est-ce que tu en penses ? Voyons voir. Donc, d'abord, nous écrivons git rebase I et ici nous écrivons notre ancien identifiant de validation, qui est notre base Encore une fois, nous passons au passage au texte et nous obtenons ces scripts. Maintenant, nous voulons laisser tomber cette couche à l'endroit de ce pic, nous écrivons drop ou nous pouvons supprimer tout cela dans le script, enregistrer les modifications, fermer ces fichiers et voir ici notre rebase avec succès si nous vérifions notre historique, puis si nous constatons que Kate a disparu parce que nous n'avons pas de conflit Permettez-moi de vous montrer ce que nous devons faire en cas de conflit car cela pourrait vous embrouiller et je ne veux pas que vous soyez confus. Ici, dans le dossier des composants de notre projet , nous créons un nouveau fichier appelé myders point HTML Dans ce fichier, il suffit d' ajouter ici H une balise, et voici ma page de commande. Les changements et voyons ces changements. Obtenez également la page DML create my order point. Bien. Maintenant, encore une fois, nous changeons quelque chose dans ce fichier. Donc, dans le tag ST, disons que c'est la liste des commandes. Enregistrez les gènes, organisons-le et validons-le également avec les mises à jour des messages de validation pour la page Commandes. Voyons maintenant notre histoire. Supposons que nous voulions supprimer ce deuxième commit. Nous faisons donc git rebase I et l'ID de validation de notre base, qui est 9981 Assurez-vous d'écrire votre identifiant de validation. Ici, nous obtenons à nouveau des scripts dans notre éditeur de code. Nous voulons supprimer ce commit, afin de pouvoir le supprimer d'ici. Enregistrez ce fichier, et fermons-le également. Dans le Git Bash, vous voyez, il y a un conflit parce que nous abandonnons notre commit et que dans cette commande, nous supprimons toutes les modifications, c' est-à-dire que nous avons créé un fichier HTML à points Moder Nous avons supprimé mon point de commande SDMLFle et lors du prochain commit, nous apporterons des modifications à ce même fichier nous apporterons des modifications à ce même C'est pourquoi nous avons des conflits. La plupart du temps, nous ne sommes pas confrontés à cette situation. Mais si cela se produit parfois, nous pouvons faire comme ça. Nous pouvons vérifier notre statut en utilisant le statut Git sous la forme a, C, ici D et U, ce qui signifie suppression et mise à jour. Donc, pour les résoudre, nous écrivons simplement ici l'outil de fusion git. voyez, ici, nous obtenons un conflit de fusion supprimé pour les composants slash Moder point STML Local est supprimé et distant, ce qui indique d'autres validations Nous y avons des modifications. Donc, pour modifié, nous pouvons écrire A, pour supprimer, nous écrivons D, et pour Abort, nous pouvons écrire A. Ici, nous ne voulons pas supprimer notre fichier Nous optons pour Modify parce que nous voulons conserver cette page Moder dans notre Cmd Maintenant, si nous vérifions à nouveau notre statut, nous sommes ajoutés ici et nous obtenons ce point Moder sTML point ORIG, qui est le fichier temporaire créé par Gate pendant le Nous pouvons l'ignorer ou le supprimer de notre projet. Poursuivons maintenant notre processus de rebase en utilisant Rebased Allons-y avec le même message et c'est fait. Maintenant, si nous vérifions à nouveau notre historique, verrons que nos baisses moyennes ont été effectuées avec succès. C'est ainsi que nous laissons tomber notre cœur. Dans la leçon suivante, nous verrons comment nous pouvons uniquement modifier le message de validation. 96. Modifier le message d'engagement: Maintenant, dans notre histoire actuelle, supposons que je veuille modifier le message de validation de ce deuxième commit parce que le message n'est pas clair. Qu'entendez-vous par modifications de la stratégie indicielle ML, qui changent Et ce type de message de validation peut créer beaucoup de confusion. Il est donc toujours préférable de changer ces messages, afin que notre histoire ait un sens. Tout d'abord, laissez-moi voir ce que j'ai réellement fait dans ce commit. Je l'ai vraiment oublié. Obtenez le show D six, un 7d59 OK, j'ajoute ici cette section de liste de produits. Donc, pour modifier le message de validation, nous utilisons également ici rebase Obtenez rebase I, et nous écrivons ici notre identifiant de validation de base, qui est 61a8 Gardez simplement à l'esprit que le commit de base est toujours un commit qui précède le commit que nous voulons rebaser Encore une fois, nous avons ici un script. Maintenant, pour modifier le message de validation à l'endroit du pic, nous écrivons une récompense. Ici, nous pouvons également reformuler plusieurs commandes. Supposons cette dernière commande que nous voulons reformuler. Nous écrivons ici une reformulation. Maintenant, lorsque nous fermerons ce fichier, il nous demandera le message de validation mis à jour pour les commandes que nous ajouterons et reformulerons Laissez-moi vous montrer que vous les enregistrez et fermez ces fichiers. Tu vois, je demande un message de validation pour notre première commande. Ici, nous écrivons l'ajout d' section de liste de produits dans le fichier DML à points d'index Enregistrez ce fichier et fermez-le. Et encore une fois, nous pouvons écrire un message de validation pour notre dernier engagement pour lequel nous sommes récompensés. Je suis content de ce message. Alors allons-y et c'est fait. Maintenant, si nous vérifions notre historique, nous obtenons ici un message de validation mis à jour. Maintenant, je tiens à vous dire qu'au fur et à mesure que nous remboursons, nous créons à nouveau cette Camt et qu'au fur et à mesure que ce commit sera recréé, toutes les couches Il est donc très clair que nous sommes en train de réécrire l'histoire. Ce n'est pas grave si nous avons des gamètes dans notre référentiel local, mais nous ne devons pas modifier les gamètes qui sont déjà transférés sur le référentiel distant 97. Changer de position des engagements: Dans notre histoire, si nous voulons déplacer les validations vers le haut ou vers le bas, disons que cela met à jour le titre de l'application et crée le fichier de script Commit. Nous voulons déplacer ce commit sous nom de cette classe d'annonces dans le point d' index SDMLKit Nous recommençons donc à rebaser, obtenir rebasi . Ici, nous écrivons nom de la comète de base où nous voulons placer notre gamète Supposons que nous ayons dix comètes, nous voulons déplacer les six comètes après la troisième rencontre Dans cette situation, nous commençons le processus de rebasage à partir de la comète 2, car ce sera la Supposons maintenant que si nous voulons placer les six comètes après huit camètes, nous commencions à nous baser à partir des Pour modifier la position du référentiel, nous commençons toujours par le rebaser au point le plus bas C'est pourquoi nous commençons ici à nous rebaser à partir de cette position. Neuf E quatre, CD trois D. Donc, notre script de rebase contient tous ces kats Maintenant, ici, nous pouvons simplement déplacer les lignes dans quel ordre nous voulons réorganiser le dépôt Nous passons donc au titre de mise à jour et au fichier de script Cat et en maintenant simplement la touche Alt ou Option , les flèches haut et bas peuvent changer la position des couches dans l'historique, déplacer vers le haut de l'historique, enregistrer ce fichier et croiser ces fichiers. Vous voyez, nous obtenons ici un rebase réussi. Regardons notre historique. Voyez cela en allant vers le bas C'est ainsi que nous pouvons modifier la position de nos amets Dans la leçon suivante, nous verrons comment fusionner deux ou plusieurs amètes en un seul amet 98. Éliminer deux ou plusieurs engagements: Voyons maintenant comment combiner deux ou trois comètes. Donc, dans notre historique, nous pouvons voir l'ajout d'un nom de classe dans fichier SML à points d' index et l'ajout styles pour le corps de l'index DotLFle Ces deux codes peuvent être combinés en une seule comète car il s'agit du même processus. Nous allons donc les combiner ensemble. Ici, nous recommençons le processus de rebase à partir d'ici. Obtenez donc un rebase I six F EA trois F huit. Encore une fois, nous passons au texte. Nous voulons maintenant combiner ce deuxième commit dans notre premier commit. Donc, pour le second commit à l'endroit du pic, nous écrivons squash. Si nous voulons également combiner ce troisième commit dans les deux, nous pouvons également écrire ici squash. Pour l'instant, ce n'est pas ce que nous voulons, alors nous revenons à nouveau jeter un coup d'œil Enregistrez ce fichier, puis fermez-le. Git va maintenant nous demander le nouveau message de validation. Ici, nous obtenons tous les messages de validation , que nous écrasons. Donc, ici, je choisis ce premier message de validation et je supprime le second message. Nous pouvons également modifier ce message de validation pour ajouter des styles pour le point d'index STML Enregistrez ce fichier et fermez-le. Voyez ici que notre rebase s'est terminée avec succès. Voyons notre histoire. Tu vois, il n'y a qu'une seule coamate dans l'histoire de notre comté. Supposons maintenant que nous combinions maladroitement ces manteaux. Et si nous voulions annuler le dernier rebase ? Nous utilisons donc ici le journal de Gid Raf. Ici, nous pouvons voir en haut que nous avons une finition de rebase. Ensuite, nous avons le pic, pic, le pic, le squash et le rebase start Nous devons donc passer à cette Camt où nous terminons notre précédente rebase Copiez cet identifiant Cait, et passons au bas de la page Et ici, nous écrivons Git, réinitialise durement cette caméra. Regardons notre historique. Vous voyez, encore une fois, ces deux kamts séparés Maintenant, si nous annulons cette courge, c'est parce qu'il existe une autre façon de combiner nos amides Nous écrivons à nouveau, obtenons l'ID de base, notre base se met ici, nous obtenons un script de rebase Maintenant, au lieu d'écrire squash, nous pouvons écrire Fix up. Maintenant, vous vous demandez peut-être quelle est la différence entre squash et fix up ? Ils sont donc presque les mêmes. Mais comme nous le savons, lorsque nous utilisons squash, nous avons ensuite la possibilité d'écrire un message de validation pour cette validation combinée. Mais lorsque nous utilisons Fix up, nous n'avons pas la possibilité d'écrire un message de validation. Choisissez le premier message de validation comme message de validation combiné. Ici, notre premier commit de dépôt combiné est le suivant. Il choisira donc ce message de validation. Sauvegardez-le et fermez le fichier. Vous voyez, le kit termine automatiquement le processus de rebase sans demander de message de validation, et nous avons ce message dans notre historique Dans la leçon suivante, nous verrons comment diviser un seul commit en deux ou plusieurs validations. 99. Compromis de division: Passons maintenant au dernier sujet concernant la réécriture de l'historique des validations, qui consiste à diviser les grosses amètes en petites camètes Ici, dans cette Camt, nous créons une page CAT et également une page de profil utilisateur Cela peut être un gros Kummet. Nous pouvons diviser ce seul Camt en deux comètes, page CAT et l'autre pour la page de profil de l'utilisateur Ici, notre base Camt a également une comète d'avance sur elle. Permettez-moi de vous montrer une autre façon d'écrire le précédent. Ici, nous sélectionnons notre commit actuel et nous copions son identifiant. Maintenant, nous écrivons, git rebase, je passe cet identifiant de validation actuel, et en oubliant le commit précédent, nous utilisons ici le signe carat Cela signifie ce commit. Nous passons ici au texte. Maintenant, cette amit que nous voulons séparer. Donc ici on écrit, édite à l'endroit du pic. Ainsi, lorsque nous fermerons ce fichier, il restera à ce commit, puis en utilisant la commande de réinitialisation, nous pouvons séparer nos ammts Laissez-moi vous montrer de façon pratique. Enregistrez ce fichier et fermez-le. Vous voyez, nous sommes en train de rebaser. Voyons où nous en sommes exactement dans notre histoire. Git log, tu vois, actuellement nous sommes sur ce Camt parce que notre tête est là Maintenant, ce que nous voulons faire, c'est utiliser la commande reset pour supprimer notre code de comité actuel de la zone de transit et également de notre amet Ici, nous écrivons git reset, soft, mais cela ne fera que supprimer notre code de at. Vous souhaitez également supprimer le code de notre zone de transit. Car cela, nous l'écrivons ici, c'est mitigé. Nous réinitialisons maintenant le code de validation actuel selon quel code de validation Nous allons revenir à la comète précédente. Tête, Garret. Maintenant, dans notre répertoire de travail, nous avons tous les changements que nous avons effectués dans un tel contexte, mais ils ne sont ni progressifs ni instantanés. Permettez-moi de clarifier cela avec le statut de Git. Vous voyez, nous avons ici deux fichiers non suivis. Ici, nous pouvons donc faire autant de validations que nous le souhaitons. Commençons par valider pour la page du panier. Nous préparons donc le premier fichier de page du panier, Git ajoute des composants, slash cart point, SGml Nous nous engageons à changer les choses. Git commit, implémente la fonctionnalité cart. Regardons maintenant notre historique. voyez, nous avons ici une histoire diversifiée parce que notre base est celle-ci et ici nos anciennes côtes. Créons maintenant un autre commit pour le profil utilisateur. Nous mettons en scène ici les composants , le point SGML du profil utilisateur, et également le commit Maintenant, la raison pour laquelle nous n'utilisons pas here amend commit est que nous ne voulons pas modifier notre commit actuel. Ici, nous voulons créer un nouveau chat. Donc git dM, fonctionnalité Implémenter le profil utilisateur. Regardons maintenant notre historique. voyez en haut, nous avons deux comètes distinctes Ne vous inquiétez pas, nous sommes toujours dans le processus de rebase. Il ne s'agit pas du résultat final. Maintenant, lorsque nous poursuivons notre processus de réédition, Git va recréer ces autres comètes et les placer au-dessus de ces deux comètes, ce qui nous permet d'obtenir un historique Git va recréer ces autres comètes et les placer au-dessus de ces deux comètes, ce qui nous permet d'obtenir un historique linéaire. Git rebase continue. Bien, nous avons réussi à rebaser. Vérifions-le par l'histoire. Vous voyez ici, nous avons deux validations distinctes et notre plus gros commit a disparu de notre histoire. Pour récapituler rapidement, nous démarrons d'abord le processus de rebase, puis nous l'utilisons dans le script de rebase Ensuite, lorsque nous en sommes à ce gros commit, nous supprimons notre code actuel de la zone de préparation et de la zone de validation en utilisant git reset, mixed head carat. Head carat signifie que nous réinitialisons notre zone de transit et que le code de validation reprend le code de validation précédent. Ici, nous pouvons organiser les modifications et les valider, en valider une, puis à nouveau organiser les modifications, puis les valider, ce qui peut être Commit deux. Ensuite, nous pouvons continuer le processus de B et le terminer pour que S divise Commit et réécrive notre historique 100. Réécrire l'historique avec GitKraken: Voyons maintenant comment réécrire notre historique à l'aide de Git Kraken Ici, je reproduis le projet que je vous donne pour vous entraîner au début de cette section et ouvre simplement dans Gate Kraken Ici, nous avons tous de mauvais médicaments et nous voulons réécrire l' Maintenant, réécrire l'historique est très facile dans Gate Cracker et c'est également le même processus dans VS Code Maintenant, réécrire l'histoire signifie que nous devons nous rebaser. Ici, nous voulons démarrer le processus de rebase comme base de cela à Nous écrivons donc cliquez sur ce commit et sélectionnons simplement ici une rebase interactive à partir de ce commit En termes simples, le commit que nous sélectionnons sera défini comme base kommt Maintenant, nous obtenons simplement ce type de script de rebase. Nous avons déjà vu cette interface dans le code Vas. Ici, à partir de cette liste déroulante, nous pouvons modifier la commande. Pour le premier commit, je sélectionne « reformuler ». Ici, nous pouvons modifier notre message de validation. À l'endroit des modifications dans le point d'index SDML, nous écrivons Ajouter une liste de produits dans fichier SGML à points d' index et mettons à jour le message Maintenant, nous voulons également fusionner cette troisième commande dans cette deuxième commande, nous pouvons sélectionner ici squash et voir qu'en utilisant la flèche, nous obtenons un squash clair. Maintenant, nous voulons également supprimer cette couche de travail en cours. Si nous avons des conflits, alors Git kraken, demande de modification, de suppression et abandonne également Identique à Gitask dans notre Git Bash. Commençons par le rebasage, voyons, nous avons un conflit et nous pouvons voir les fichiers en conflit sur le côté droit Cliquez dessus et ici, nous prenons modifications de B et faisons simplement C. C, le conflit a disparu, et maintenant nous pouvons continuer cette rebase ou nous pouvons également l'abandonner. Passons à Continuer et voyons si toutes les modifications sont effectuées. C'est une base simple dans Git Kraken et Viscode. Mais voici une chose. Dans Git Kraken ou dans Vs code, nous pouvons modifier, valider ou diviser des comètes Pour cela, nous devons utiliser le terminal. C'est pourquoi je vous montre d'abord Git en ligne de commande , puis pour les outils GI. Maintenant, officiellement, nous avons abordé tous les sujets liés à la démarche. Qu'est-ce que tu en penses ? Qu'est-ce qui vous plaît le plus dans Git ? En l'utilisant dans un terminal ou en l'utilisant avec des outils d'interface utilisateur. J'aime utiliser la ligne de commande pour toutes les commandes et les outils GI pour regarder l'historique et rebaser Votre choix peut sembler différent, mais il s'agit d'un choix personnel. En fin de compte, vous devez travailler sur votre système. Peu importe ce que nous utilisons, notre travail doit être fait. 101. Section 07 Les commandes Git les plus utilisées: Bienvenue dans la section récapitulative du cours Git ultime. Dans cette section, nous verrons toutes les commandes les plus courantes dans la vie des développeurs. C'est comme une révision des concepts Git. Alors, retenez un peu d'eau et profitez de cette section. 102. Les bases et les commandes d'historique de Git: Commençons par les commandes de base de Git. Tout d'abord, pour initialiser notre projet, nous utilisons la commande Gain init Ou si nous avons déjà un projet sur le Cloud , nous utilisons Git clone et URL. Après avoir obtenu notre projet, nous pouvons apporter des modifications à notre code, puis nous pouvons organiser ces modifications à l'aide de Git add. Et ici, nous écrivons le nom de notre fichier. La planification des modifications signifie que ces modifications sont prêtes à être appliquées. C'est comme une salle d'attente. Maintenant, si vous voulez organiser toutes les modifications, nous écrivons ici Git add period. Donc, si vous voulez voir notre statut actuel, nous écrivons Git status ou git status pour un statut court. Maintenant, une fois que nous sommes satisfaits de nos modifications, nous nous engageons à les modifier pour stocker ce code dans notre historique de porte, pour stocker ce code dans notre historique de porte à l'aide de Git commit, et nous ajoutons ce message ici. Ici, assurez-vous d'écrire un message significatif. Si nous n'ajoutons aucun nouveau fichier, nous pouvons utiliser cette commande de raccourci, Git commit AM message. Par cette commande, nous pouvons préparer et valider notre code en une seule commande. Maintenant, si vous voulez voir la différence entre code de zone de travail et le code de zone intermédiaire, nous pouvons utiliser Git DF pour voir différence entre le code de zone de préparation et le code validé, puis nous pouvons utiliser Git dif, stage, ou nous pouvons utiliser Git Di dash cast , si nous voulons voir l'historique de nos validations, Ensuite, si nous voulons voir l'historique de nos validations, nous pouvons utiliser la commande Git log. Et si nous voulons voir l'historique sur une seule ligne, nous pouvons utiliser Git log, dash one line. Nous pouvons également ajouter d'autres options comme un graphique pour l'historique des graphes. Ensuite, si nous voulons voir ce que nous changeons dans Commit, nous pouvons utiliser Git, show et commit ID. Nous pouvons également utiliser son pointeur principal et si nous voulons voir un fichier spécifique, nous pouvons utiliser Git, show, commit reference et avec column, nous écrivons le chemin de notre fichier. Nous voulons donc parfois changer de code d'un commit à un autre. Ensuite, nous pouvons utiliser Git checkout, commit ID, ou nous pouvons également utiliser Git, switch, commit ID. Maintenant, si dans notre projet, quelqu'un écrit du très mauvais code, et pour vérifier l' auteur de chaque ligne, nous pouvons utiliser Git, blame et ici nous écrivons le chemin du fichier que nous voulons blâmer. Si nous voulons voir des lignes particulières, nous pouvons ajouter ici l'option L, et ici nous écrivons la ligne de départ par une virgule et le numéro de fin de ligne Ensuite, une autre commande la plus utilisée pour marquer les validations Git est git tag, tag name. Ensuite, nous écrivons notre identifiant de validation pour lequel nous voulons créer cette balise. Si nous voulons supprimer la balise, nous utilisons la balise Git, D, et ici nous écrivons le nom de notre balise et pour C, la liste des balises, nous utilisons simplement la commande Git tag. Voici les commandes importantes liées aux bases de Git et à la surveillance de l'historique des validations. 103. Commandes de branchement et de fusion: Récapitulons maintenant les branches. Lorsque vous souhaitez travailler sur une fonctionnalité distincte ou simplement travailler au sein de votre équipe, vous devez créer une nouvelle branche et travailler sur cette branche. Si nous voulons voir la liste de toutes les branches, nous avons la commande git branch. Et pour créer une nouvelle branche, nous utilisons la branche Git et le nom de la branche. Après avoir créé une nouvelle branche, nous devons passer à cette branche, et nous pouvons le faire en utilisant le nom de branche Git switch. Maintenant, si nous voulons créer une nouvelle branche et que nous voulons également basculer en une seule commande, nous écrivons Git switch, C et le nom de la branche. Maintenant, pour voir quelle est la différence entre une branche particulière et notre branche actuelle, nous pouvons écrire le nom de la branche Git Div. Nous pouvons également voir la différence entre deux branches utilisant Git, branche D un, point point la branche deux. Maintenant, si nous travaillons sur la première branche et que nous devons soudainement travailler sur la branche deux, au lieu de valider un demi-code, nous pouvons stocker ce code Les escaliers, c'est comme si vous gardiez ce code dans un coin, puis nous pouvons passer à une autre branche et compléter notre ou ensuite appliquer les escaliers de notre branche précédente. Pour créer les escaliers, nous utilisons Git stairs, push, et ici nous ajoutons un message S pour voir tous les escaliers, nous utilisons la liste des statistiques Git. Maintenant, si nous voulons appliquer les modifications depuis stairs dans notre répertoire de travail, nous pouvons utiliser Git, apply et stats ID. Après avoir appliqué les modifications apportées à cet escalier, nous pouvons le descendre en utilisant git stash, drop et stats ID Et si nous voulons supprimer tous les restes du projet, nous pouvons utiliser Git clear. Maintenant, après cela, si nous avons terminé avec notre branche, nous pouvons la fusionner avec notre branche principale. Et pour cela, nous pouvons passer à la branche principale, puis nous pouvons la fusionner en utilisant le nom de la branche git merge. Si nous avons un historique divergent, alors Git effectuera une fusion à trois voies, et si nous avons un historique linéaire, alors Git procédera à notre Après avoir fusionné notre branche dans la branche principale, nous pouvons supprimer cette branche en utilisant Git branch, D, branch name. Si nous voulons supprimer cette branche de force, nous pouvons utiliser Git branch, D, branch name Nous pouvons également réinitialiser le Kamed à l'ancienne version en utilisant git reset En réinitialisation, nous avons trois variantes. Git reset, Dash Dash Soft, Kate, qui réinitialise le code depuis Coat, Git Reset, Dads Mixed, qui réinitialise le code depuis un et depuis Camt Si nous utilisons Git reset ds hard, alors tout notre code régional est réinitialisé avec ce code de comité Maintenant, nous pouvons également inverser le milieu. La différence entre reset et mid est qu'avec revert, Git crée un nouveau met mais lors de la réinitialisation, Git ne crée pas de nouveau Apportera des modifications à la Camt actuelle. Pour revert, nous utilisons Git revert et si nous voulons revenir à la comète parent, qui est la précédente comète de notre branche actuelle, nous en écrivons une ici et ensuite, nous écrivons Comte, que nous voulons inverser, qui Enfin, si vous souhaitez copier un code Comite dans notre Camt actuel sans le fusionner, nous pouvons utiliser la référence de validation Git Cherry Peak Voici un aperçu des branchements et des fusions. 104. Travailler en équipes: Récapitulons maintenant le travail en équipe. Tout d'abord, lorsque nous travaillons en équipe, plupart des commandes que nous utilisons sont git fetch, qui est utilisée pour récupérer les modifications de toutes les branches de notre référentiel cloud , si nous voulons spécifiquement récupérer les modifications d'une seule branche, nous pouvons écrire git fetch Ensuite, si nous voulons spécifiquement récupérer les modifications d'une seule branche, nous pouvons écrire git fetch Nous écrivons ici l'origine de notre nom de télécommande, qui est le nom de télécommande et de branche le plus utilisé. Si nous voulons récupérer depuis master, nous pouvons écrire git fetch origin master ou nous pouvons écrire git fetch uniquement. Cela fonctionnera de la même manière. Maintenant, comme nous le savons, en utilisant la commande fetch, nous n'obtiendrons que des modifications dans notre historique Notre répertoire de travail reste le même qu'avant. Si nous voulons appliquer ces modifications directement à distance, alors à la place de git fetch, nous utilisons git pull Mais gardez à l'esprit que cela créera un nouveau commit. Maintenant, si nous en avons terminé avec nos modifications et que nous voulons les transférer vers le cloud. Nous devons écrire git push origin, master ou main, quel que soit le contenu de notre projet. Nous pouvons également utiliser ici la commande de raccourci, qui est Git push. Maintenant, nous pouvons également envoyer notre balise à la télécommande en utilisant git push, origin et tag name pour supprimer la balise d'origine, nous utilisons git push origin, dash delete, tag name. Maintenant, si nous créons une nouvelle branche et que nous voulons pousser cette branche vers l'origine, nous devons d'abord créer une branche en amont. Nous écrivons le nom de la branche d'origine git push. , si nous voulons à nouveau apporter des modifications à cette branche, Ensuite, si nous voulons à nouveau apporter des modifications à cette branche, nous pouvons utiliser un simple push de portail. Git appliquera les modifications à cette branche, c'est une question de travail en équipe. 105. Merci beaucoup: Alors félicitations. Vous venez terminer le cours ultime sur Git et Github Et je voulais juste te demander tu as appris le truc ? Ai-je pu expliquer les concepts qui vous aideront à comprendre Git ? Je l'espère sincèrement. Et dans cette vidéo, je voulais juste vous dire merci beaucoup d'avoir regardé ce cours Complete it et Github J'en suis vraiment très reconnaissante. Et s'il vous plaît, si vous souhaitez partager votre avis sur ce cours, vous pouvez voir en haut le bouton Bating, et ainsi, vous pouvez partager votre avis Quoi que tu veuilles dire, positif ou négatif, c'est très important pour moi. Ces commentaires ne prendront pas plus de 10 secondes, mais cela m'inspirera et me pour créer de meilleurs cours, et cela m' aidera également à toucher plus grand nombre d'étudiants désireux d' apprendre Git et Github comme vous Merci beaucoup d'avoir suivi ce cours et bonne chance dans votre parcours de développeur, et j'espère que tous vos rêves deviendront réalité.