Hoorah pour la traduction-machine! Grace à cette
dernière, je me propose d'offir une traduction de l'excellent
exposé de Bryan Yu (Harvard) sur Git, un outil de gestion des
fichiers.
HTML and CSS - CS50's Web Programming with Python and JavaScript (harvard.edu)
* * *
[LECTURE DE MUSIQUE] BRYAN YU : D'accord. Bienvenue à tous dans la programmation Web avec Python et JavaScript. Ainsi, la dernière fois, nous avons examiné deux langages, HTML et CSS, qui peuvent tous deux être utilisés pour concevoir des pages Web. HTML, nous avons utilisé pour décrire la structure des pages Web, pour décider quel contenu nous voulions dans la mise en page de la page, puis CSS, nous avons utilisé pour décrire le style de la page, de quelle couleur nous voulions les choses, de combien d'espace nous voulions pour gérer les choses.
Aujourd'hui, nous allons porter notre attention sur un outil que nous pouvons utiliser lorsque nous commençons à développer ces applications Web, et en particulier, nous allons examiner un outil appelé Git ; et ce qu'est Git, c'est un outil de contrôle de version, pas nécessairement spécifique aux programmes Web, mais que nous allons utiliser au fur et à mesure que nous commencerons à développer des applications Web plus grandes et plus sophistiquées au cours de cette session.
Alors, qu'est-ce que Git va nous permettre de faire ? Eh bien, plusieurs choses. Tout d'abord, ce qu'est Git ; c'est un outil en ligne de commande qui va nous permettre, dans un premier temps, de garder un journal des modifications que nous apportons au code.
Donc, il était une fois, et ceci la première fois que je commençais à développer des applications Web, je me souviens avoir travaillé sur un fichier, puis quand je voulais apporter des modifications, j'aurais peut-être voulu enregistrer l'ancienne version, donc je dupliquerais le fichier pour apporter simplement des modifications au doublon, mais cela devint rapidement désordonné. Surtout si vous avez beaucoup de versions différentes de votre code à différentes étapes, leur suivi commence à devenir un cauchemar.
Donc, ce que Git va nous permettre de faire, c'est de garder une trace des modifications que nous apportons à notre code. Nous pouvons donc créer un fichier initialement, enregistrer cette version, mais au fil du temps, au fur et à mesure que nous apportons des modifications, y ajoutons, en supprimons des éléments, nous pouvons enregistrer, pour ainsi dire, des instantanés de différentes parties de notre code à différents instants donnés, de sorte que nous puissions rapidement et facilement référencer toutes les modifications que nous avons apportées à ce code.
Donc, il était une fois, alors la première fois que je commençais à développer des applications Web, je me souviens avoir travaillé sur un fichier, puis quand je voulais apporter des modifications, j'aurais peut-être voulu enregistrer l'ancienne version, donc je dupliquerais le fichier pour apporter simplement des modifications au doublon, mais cela devient rapidement désordonné. Surtout si vous avez beaucoup de versions différentes de votre code à différentes étapes, leur suivi commence à devenir un cauchemar.
Donc, ce que Git va nous permettre de faire, c'est de garder une trace des modifications que nous apportons à notre code. Nous pouvons donc créer un fichier initialement, enregistrer cette version, mais au fil du temps, au fur et à mesure que nous apportons des modifications, y ajoutons, en supprimons des éléments, nous pouvons enregistrer, pour ainsi dire, des instantanés de différentes parties de notre code à différents instants donnés, de sorte que nous puissions rapidement et facilement référencer toutes les modifications que nous avons apportées à ce code.
De plus, Git va nous permettre de synchroniser facilement le code entre différentes personnes. Dans les applications Web à plus grande échelle, c'est rarement une seule personne qui travaille sur l'ensemble de l'application. Habituellement, vous travaillez avec un collègue ou plusieurs collègues, tous dans la même application, et tous en même temps. Et une partie certainement délicate de ce processus consiste à trouver comment synchroniser votre travail entre différentes personnes. Si j'apporte une modification de ma part à l'application Web, je veux m'assurer que mes collègues sont également en mesure de voir ces modifications et d'avoir accès aux dernières modifications que j'ai apportées. Et puis, je veux pouvoir accéder aux derniers changements apportés par les personnes avec qui je travaille. Nous avons donc besoin d'un moyen de tout synchroniser et Git va nous permettre de le faire.
Ce que nous aurons effectivement, c'est une version du code stockée dans un dépöt de documents(repository) qui servira de référentiel quelque part en ligne, et moi et quelqu'un avec qui je travaille - un partenaire, par exemple - pourrions tous les deux être en mesure d'accéder à exactement ce même référentiel, les mêmes fichiers dans le même état. Et si jamais moi et l'autre personne apportons des modifications à ces fichiers, nous pouvons chacun apporter des modifications à ces fichiers, puis les synchroniser à nouveau, en les 'empilant' (push) vers le serveur, pour ainsi dire, afin que le serveur ait la version la plus récente et la plus à jour de ce code.
Ensuite, après que nous ayons tous les deux poussé nos modifications vers le serveur, nous pouvons tous les deux tirer les modifications du serveur, pour ainsi dire, afin d'avoir accès à la dernière version du code, de sorte que quoi qu'il arrive, tant que je travaille sur le même projet que mon partenaire, nous pouvons utiliser Git pour synchroniser notre travail, afin que j'aie accès aux modifications les plus récentes de mon collègue, et vice versa.
Git nous permet également de faire un certain nombre d'autres choses. Par exemple, Git nous permet de tester les modifications apportées à notre code sans supprimer l'accès à l'original. Ainsi, par exemple, vous pouvez imaginer que pendant que je travaille sur l'écriture d'un programme, je pourrais vouloir essayer d'apporter quelques changements, mais je ne suis pas sûr qu'ils fonctionnent vraiment. Je veux donc tester ces modifications, mais je ne veux pas perdre l'accès à ma version de travail d'origine du programme, juste au cas où quelque chose se passerait mal.
Donc, ce que Git nous permet de faire, c'est qu'il nous permet d'apporter des modifications au code sur une branche distincte, pour ainsi dire, de sorte que plus tard, une fois que nous sommes satisfaits et satisfaits des modifications, nous pouvons fusionner ces modifications dans la version originale de notre code, pouvoir tester ces changements avant d'être vraiment sûrs que ce sont ceux que nous voulons faire.
Et enfin, une fonctionnalité puissante à laquelle Git nous donne accès est la possibilité de revenir aux anciennes versions de notre code. Vous pouvez donc imaginer que dans la situation où j'ai travaillé sur du code, et je me rends compte qu'en fait, ce que je fais en ce moment n'est pas ce que je veux, Git nous permet de dire, vous savez quoi ? Ce changement le plus récent n'est pas quelque chose que je voulais. J'aimerais plutôt revenir à une version antérieure du code. Et Git permet de revenir très facilement à ces versions précédentes.
L'objectif d'aujourd'hui sera donc d'apprendre à utiliser cet outil, d'apprendre les différentes commandes Git qui sont assez populaires et assez courantes, au fur et à mesure que vous travaillerez sur des applications Web ou sur tout autre projet lié au code. , car le contrôle de version permet vraiment un certain nombre de fonctionnalités utiles qui sont pratiques lorsque vous commencez à travailler sur des projets de plus en plus volumineux.
Mais en fin de compte, lorsque nous commençons à travailler sur ces projets Git, ils doivent être stockés quelque part en ligne, de sorte que nous puissions les télécharger de n'importe où, de sorte que moi et un partenaire puissions tous les deux travailler sur les mêmes fichiers et le même code, et donc pour ce faire, nous devons héberger notre code Git quelque part.
Et il existe un certain nombre de sites Web différents qui peuvent le faire, mais l'un des plus populaires est un site Web connu sous le nom de GitHub. GitHub est un site Web qui stocke des référentiels Git, ce qui revient à un dossier contenant tout un tas de code et de fichiers liés à ce code. Nous allons donc héberger notre code en ligne sur un site Web appelé GitHub, puis sur notre ordinateur, nous pourrons accéder à plusieurs référentiels GitHub et manipuler ces référentiels en modifiant les fichiers qui s'y trouvent.
Alors allons-y et jetons un coup d'œil à GitHub et voyons comment nous pouvons aller de l'avant et créer notre tout premier référentiel GitHub. Si vous n'avez pas encore de compte GitHub, vous pouvez en créer un en vous rendant sur GitHub.com et en créant un compte gratuitement. Et je vais maintenant aller sur GitHub.com/new. GitHub.com/new est la page sur laquelle je vais si je veux créer un nouveau référentiel GitHub. Jetons donc un coup d'œil à ce que je dois faire pour créer un référentiel.
La première chose que je dois faire est de donner un nom à mon référentiel. Donc, dans ce cas, je vais juste appeler le dépôt bonjour. Vous pouvez lui donner n'importe quel nom, tant que ce nom n'entre pas en conflit avec d'autres noms de référentiel que vous avez déjà. GitHub me permet éventuellement de fournir une description de ce référentiel. J'ajouterai programmation Web avec Python et JavaScript.
Et puis GitHub me donne le choix, est-ce que je veux que ce soit un référentiel public, de sorte que tout le monde puisse voir le référentiel ? Tout le monde ne peut pas nécessairement y apporter des modifications, mais il est accessible en mode public si quelqu'un veut télécharger mon code et l'essayer. Public signifie que tout le monde peut y accéder. Ou privé, ce qui signifie, par défaut, que moi seul peux voir ce référentiel, mais je peux choisir si je souhaite que d'autres personnes puissent le voir également, et je peux sélectionner quelles personnes. Pour l'instant, je vais aller de l'avant et rendre ce référentiel public, et je vais descendre ici et cliquer sur le bouton vert Créer un référentiel afin de créer ce nouveau référentiel. Je clique donc sur le bouton Créer un référentiel.
Et voilà. Ceci est la page du référentiel de GitHub, et en ce moment, vous remarquerez qu'il y a beaucoup d'instructions ici, mais il n'y a pas de fichiers, car pour le moment, lorsque j'ai créé mon premier référentiel Git, j'ai un référentiel vide sans rien dedans . Donc, ce que j'aimerais faire maintenant, c'est télécharger ce référentiel sur mon propre ordinateur, de manière à pouvoir ajouter, par exemple, un fichier HTML contenant du code HTML dont je souhaite garder une trace à l'aide de Git.
Alors, comment vais-je faire ? Eh bien, pour ce faire, nous allons jeter un œil à la toute première commande Git qui sera impliquée avec Git, connue sous le nom de git clone. git clone est une commande que nous pouvons exécuter pour prendre un référentiel sur Internet et le télécharger sur notre propre ordinateur.
Vous aurez donc besoin d'avoir Git installé sur votre ordinateur. Vous pouvez l'installer sur n'importe quelle machine Mac ou PC ou Linux, et une fois que vous l'avez fait, ce que vous allez faire est, sur votre ordinateur dans le terminal, vous l'exécuterez git clone, suivi de l'URL du référentiel Git que vous essayez de télécharger. Vous pouvez donc imaginer que voici votre ordinateur ici, et ici se trouve un serveur où se trouve un référentiel Git. GitHub, par exemple, est l'un de ces serveurs, mais il y en a aussi d'autres. Et là-haut se trouve le référentiel qui contient potentiellement des fichiers ou peut-être d'autres dossiers avec d'autres fichiers contenant le contenu du référentiel que vous souhaitez télécharger.
Donc, si j'exécute git clone suivi de l'URL du référentiel que je veux, cela a pour effet que le référentiel et tout son contenu sont téléchargés sur mon ordinateur, de sorte que j'ai maintenant sur mon ordinateur une copie de tout ce qui était à l'origine à l'intérieur de ce référentiel Git.
Alors maintenant que nous savons comment cloner un dépôt, essayons-le. Nous venons de créer un référentiel à l'aide de GitHub, et laissez-moi maintenant accéder à mon terminal et essayer de cloner ce référentiel, afin que j'en ai une copie sur mon ordinateur et que je puisse commencer à y apporter quelques modifications.
Je vais donc aller dans mon terminal maintenant, et j'irai dans mon répertoire lecture1. Et la première chose dont j'aurai besoin, c'est l'URL du référentiel. Donc, si je retourne dans GitHub, ce que vous remarquerez, c'est qu'il me donne un lien HTTPS afin de télécharger mon dépôt Git.
Il y a donc plusieurs façons différentes que je peux utiliser pour cloner mon référentiel, des façons de m'authentifier. L'un utilise HTTPS, qui impliquera éventuellement un nom d'utilisateur et un mot de passe que je devrai saisir, afin de prouver à Git qu'il s'agit de mes informations d'identification GitHub. Sinon, si vous êtes familier avec SSH, il s'agit d'une autre méthode d'authentification. Vous pouvez également donner à GitHub votre clé SSH publique afin de vous authentifier, mais vous n'avez pas à vous en soucier si vous n'êtes pas aussi familier avec cette technologie.
La clé ici est que cette URL est l'URL GitHub qui correspond à mon référentiel. Je vais donc copier cette URL, puis à l'intérieur de mon terminal, je taperai git clone, et je collerai simplement l'URL que je souhaite cloner et qui contient ce référentiel. Je vais aller de l'avant et appuyer sur Retour. On me renvoie que je clone dans un répertoire appelé hello, ainsi que vous semblez avoir cloné un référentiel vide. Cela n'est un avertissement, mais ce n'est pas grave, car je sais que j'ai cloné un référentiel vide, car le référentiel est tout neuf.
Et maintenant, je peux taper la commande ls dans mon terminal. La commande ls dans le terminal signifie liste, et en réalité, ce qu'elle va faire est de répertorier tous les fichiers qui se trouvent actuellement dans ce répertoire, tous les fichiers et dossiers qui se trouvent dans mon répertoire lecture1, où je sais très bien que répertoire n'est qu'un signifiant pour dossier. Je vais donc taper ls, et je vois que, d'accord, j'ai maintenant un dossier appelé hello dans mon répertoire lecture1, que je n'avais pas auparavant.
Je vais aller de l'avant et me déplacer dans ce répertoire hello. Pour passer dans un répertoire ou un dossier, vous pouvez utiliser la commande cd. Cd signifie changement de répertoire. Et donc si je tape cd hello, je vais maintenant me déplacer dans le répertoire hello. Et si je tape ls, vous verrez qu'il n'y a rien dans ce répertoire hello pour le moment, car encore une fois, ce référentiel était vide. Je l'ai cloné et il n'y avait rien dedans.
Alors maintenant, j'aimerais mettre quelque chose dans ce référentiel. Le référentiel n'est utile que si je garde une trace de mon code et des modifications que j'apporte à ce code. Je vais donc continuer et essayer maintenant d'ajouter du code au référentiel.
La première chose que je vais faire est de créer un nouveau fichier. Et nous pourrions créer un nouveau fichier simplement en ouvrant un éditeur de texte, mais sur le terminal, il existe en fait une commande pour créer un nouveau fichier appelé touch. Donc, dans le terminal, je peux taper touch hello.html, et ce que cela va faire est de créer un nouveau fichier appelé hello.html. Et si je tape ls, je peux voir qu'en effet j'ai un fichier appelé hello.html.
Maintenant, à l'intérieur de mon répertoire hello, permettez-moi maintenant d'ouvrir ce répertoire dans le fichier hello.html à l'intérieur d'un éditeur de texte. Encore une fois, j'utilise VS Code. Et permettez-moi maintenant d'ajouter du texte à hello.html. Je vais juste ajouter une simple page HTML, la même chose que nous avons vue auparavant, où je lui donne un en-tête, le titre sera bonjour, et à l'intérieur du corps de la page sera "Hello, world!" La même page HTML que nous avons vue plusieurs fois maintenant, tout à l'heure à l'intérieur de ce référentiel.
Bien sûr, je n'ai pas encore fait de sauvegarde dans ce référentiel. Je n'ai pas dit que je voulais enregistrer ces modifications dans le référentiel. Et le référentiel ne garde pas la trace de chaque caractère que j'écris. Je dois dire à Git qu'il s'agit d'un état de mes fichiers actuels dont je voudrais garder une trace, quelque chose que je voudrais enregistrer. Et dans le monde de Git, nous appelons ces points de sauvegarde des commits. Quand je dis, je fais un commit, je veux dire que je voudrais enregistrer l'état actuel de tous les fichiers et dossiers et autres actifs qui existent à l'intérieur du référentiel et essentiellement prendre un instantané de leur position actuelle, de sorte que plus tard je pourrai peut-être m'y référer.
Mais pour ce faire, il y a en fait quelques étapes. La première étape à suivre est donc une commande supplémentaire. Nous avons donc vu que git clone était la commande que nous pouvions utiliser pour cloner un référentiel, prendre un référentiel et le télécharger sur notre propre ordinateur.
La prochaine commande que nous examinerons est une commande appelée git add. Et ce que git add va faire, c'est qu'il va nous permettre de dire à Git que j'aimerais ajouter un fichier en tant que fichier à suivre la prochaine fois que j'enregistre, la prochaine fois que je m'engage à dire que je voudrais prendre un instantané de tous ces fichiers, de manière à pouvoir m'y référer ultérieurement.
Et pour ce faire, je dois dire à Git de quels fichiers garder une trace. Donc, si, par exemple, je travaille sur ce fichier et que je souhaite dire à Git que je souhaite le suivre, je peux exécuter une commande comme git add, suivie du nom du fichier comme foo.py ou .html ou n'importe quel fichier. Et puis Git affichera un message disant que maintenant, nous avons ajouté foo.py. C'est maintenant un fichier qui sera enregistré la prochaine fois que je ferai un commit.
Alors pourquoi ces deux étapes sont-elles distinctes ? Eh bien, une des raisons que vous pouvez imaginer est que si je travaille sur beaucoup de fichiers différents, disons que je travaille sur 10 fichiers différents, et qu'il n'y en a que trois dont je suis satisfait, trois que je veux enregistrer, Je ne veux pas simplement dire enregistrer et que tout soit enregistré dans un commit. Je pourrais vouloir dire que vous savez quoi? Ce sont les trois seuls fichiers que je souhaite réellement enregistrer pour le moment, et les autres sont ceux sur lesquels je travaille toujours. Cela nous donne donc la possibilité d'avoir cette séparation pour dire, permettez-moi de dire explicitement que je veux suivre ce fichier la prochaine fois que j'enregistre, la prochaine fois que je fais un commit, et pas tous les fichiers, par exemple, bien qu'il y ait sont des raccourcis que nous pouvons utiliser si nous voulons ajouter tous les fichiers, et nous les verrons également dans un instant.
Alors allons-y et essayons ça. Nous allons revenir à notre référentiel où j'ai créé ce fichier hello.html, et maintenant ce que je voudrais faire, c'est dire que je voudrais ajouter le fichier hello.html à mon référentiel Git. Donc, à l'intérieur de mon terminal, je dirai maintenant - encore une fois, j'ai un fichier hello.html ici - je dirai git add, suivi de hello.html. Et vous remarquerez que jusqu'à présent, rien ne semble s'être passé, car jusqu'à présent, je n'ai encore rien sauvegarder. Je viens de dire que je voudrais ajouter hello.html en tant que fichier dont la prochaine fois que je dis enregistrer, la prochaine fois que je valide mon dépôt, il gardera une trace des modifications que j'ai maintenant apportées à hello.html .
Alors, comment puis-je réellement faire un commit? Comment puis-je dire, enregistrer l'état de ces fichiers ? Eh bien, ce sera une autre commande Git, connue sous le nom de git commit. Quand je dis, git commit, je vais dire à mon référentiel Git que je souhaite enregistrer un instantané de l'état actuel du référentiel, en gardant une trace de toutes les modifications apportées aux fichiers que j'ai ajoutés en utilisant git add.
Et la façon dont nous l'exécutons est d'exécuter git commit, suivi de -m, puis entre guillemets, un message. Et ce message est connu sous le nom de message de validation, et c'est une description en anglais, ou quelle que soit votre langue, des modifications que vous avez apportées dans cette validation la plus récente, car au fil du temps, vous travaillez sur un grand projet , vous allez probablement faire beaucoup de commits au fur et à mesure que vous apporterez de nombreuses modifications à votre programme. Vous vous engagez et recommencez après chaque nouvel ajout que vous apportez au projet. Et vous voudrez peut-être vous référer à un commit précédent, mais cela n'a de valeur que si vous pouvez identifier dans quel commit vous avez apporté une modification particulière, par exemple.
Donc, en fournissant un message en anglais - juste une note pour vous-même - de sorte que plus tard, vous puissiez vous référer à tous vos messages de validation et savoir que, d'accord, à ce stade, dans cette validation, c'est le changement que j'ai fait qui peut simplement faciliter le suivi de toutes les modifications que vousi avez apportées à un référentiel Git particulier.
Ainsi, lorsque vous tapez git commit suivi de -m, vous pouvez inclure un message, par exemple, "J'ai ajouté une nouvelle ligne". Et lorsque vous le faites, Git va enregistrer un nouvel instantané d'une version de votre code en ce moment, en gardant une trace de l'ancienne ou des anciennes versions qui existaient à l'intérieur du référentiel.
Essayons donc de faire un commit maintenant et voyons comment cela va fonctionner. Nous avons donc déjà ajouté le fichier, comme en exécutant git add, pour dire ajouter le fichier hello.html comme un fichier à suivre, mais maintenant, lorsque nous en sommes satisfaits et que nous pouvons apporter des modifications supplémentaires au fichier au besoin, je peux retourner dans le terminal et maintenant dire git commit puis -m, puis je peux spécifier le message de commit, une description en anglais de ce que j'ai fait dans ce commit le plus récent. Et ce que j'ai fait, c'est que j'ai ajouté le fichier hello.html. Donc je vais juste dire, j'ai ajouté le fichier hello.html. C'est le changement que j'ai fait dans ce commit le plus récent. Je vais aller de l'avant et appuyer sur Retour.
Et voici ce qu'il me dit. Cela me dit qu'un fichier a été modifié avec neuf insertions. Ainsi, Git garde une trace des modifications en termes de nombre de lignes ajoutées ou insérées et de nombre de lignes supprimées ou supprimées. Et dans ce cas, cela me dit qu'il y a eu neuf insertions dans un fichier, car auparavant, le fichier n'existait pas, et maintenant un fichier de neuf lignes existe. Et maintenant, j'ai enregistré hello.html dans ce référentiel Git.
Alors maintenant, vous pouvez imaginer que si je reviens à mon référentiel Git sur le site Web de GitHub et que je le rafraîchis, je verrai peut-être ce fichier hello.html, mais je rafraîchis et rien ne s'est passé, rien n'a changé. Je ne vois pas mon fichier hello.html.
Et c'est parce qu'il me manque une dernière étape avant que mes modifications ne soient reflétées en ligne. Rappelez-vous que lorsque j'ai exécuté l'étape git clone afin de cloner le référentiel à partir de GitHub, GitHub avait une version du référentiel, et j'ai exécuté git clone pour télécharger une copie de ce référentiel sur mon propre ordinateur, et lorsque j'ai exécuté git add pour ajouter le fichier hello.html, ou j'ai exécuté git commit pour dire, je voudrais enregistrer ces modifications, j'apportais toujours ces modifications uniquement à ma version locale du référentiel. Je n'ai jamais affecté quoi que ce soit sur qui était déjà sur GitHub. Les modifications que je faisais se produisaient uniquement sur mon propre ordinateur.
Si je veux pousser ces modifications vers GitHub, j'aurai besoin de commandes supplémentaires. Et en fait, nous pouvons voir ce qui se passe actuellement dans mon référentiel en utilisant une commande appelée git status. Et ce que git status fera, c'est qu'il nous dira ce qui se passe actuellement dans mon référentiel.
Ainsi, par exemple, si je devais, dans cet état actuel, exécuter la commande git status, alors Git va me faire un rapport et me dire que je suis actuellement sur branch master - plus sur les branches plus tard - mais alors ça dit, ma branche est en avance sur origin master d'un commit. C'est donc une longue façon de dire que ma version locale du référentiel - la version du référentiel sur mon ordinateur - est en avance sur la version d'origine du référentiel, la version du référentiel qui est sur GitHub d'un commit, que j'ai un commit que l'origine GitHub n'a pas. Et cela me dit utilement que je peux utiliser la commande git push pour publier nos commits locaux. obtenir push de la commande que je peux utiliser pour dire, je voudrais prendre mes modifications et les pousser vers le serveur, les pousser vers GitHub afin qu'ils s'y trouvent.
Donc, après avoir vérifié notre statut actuel avec git status, nous pouvons utiliser la commande git push pour dire que maintenant, quelles que soient les modifications que j'ai apportées, lorsque j'exécute git push, ces modifications sont transmises à GitHub, donc GitHub a accès à tous les engagements que j'ai maintenant pris. Essayons donc ces deux commandes maintenant - git status, pour voir ce qui se passe actuellement à l'intérieur de mon référentiel, puis git push, pour dire, je voudrais maintenant pousser ces modifications vers GitHub, afin que la version en ligne du référentiel ait le même contenu que la version locale sur mon propre ordinateur.
Très bien. Donc, dans mon terminal maintenant, je peux exécuter git status, et je vois que je suis sur branch master, comme auparavant. Et c'est un message légèrement différent, car il n'y a rien actuellement dans le référentiel, mais la clé ici est que maintenant je peux exécuter la commande git push pour, disons, prendre toutes les modifications que j'ai apportées à mon référentiel et continuer et les pousser vers GitHub. Je vais donc taper git push, et ce qui va se passer, c'est que ça va compresser toutes les informations, et ça va les 'pousser' vers GitHub vers cette URL.
Et maintenant, si je retourne sur le site Web de GitHub, GitHub.com/myrepository, et que je rafraîchis la page, je verrai que je vois maintenant quelque chose de différent. Et voilà à quoi ressemble l'interface utilisateur de GitHub. Cela me donne quelques informations. Cela me dit, par exemple, qu'il y a un commit actuellement effectué dans le référentiel -- c'est celui que je viens de faire -- c'est sur une branche, donc si je n'ai créé qu'une branche, celle par défaut, mais nous allons voir comment créer plus de branches plus tard. Et, en particulier, en bas, vous verrez les fichiers qui existent actuellement à l'intérieur de ce référentiel, que j'ai en ce moment ce fichier hello.html, qui est celui que j'ai poussé, et, en particulier, à côté de celui-ci est le message de validation, le message de la dernière fois que j'ai touché ce fichier,
Et si je devais maintenant cliquer sur hello.html pour voir ce qu'il contient, je verrais le même contenu que j'ai écrit dans le fichier auparavant. Je vois !DOCTYPE html, puis le message "Hello, world!" page que nous avons vue plusieurs fois maintenant. J'ai donc fait les changements sur mon propre ordinateur, et je les ai maintenant poussés vers GitHub, donc ils sont maintenant à l'intérieur de ce référentiel. C'est maintenant public, de sorte que n'importe qui d'autre, s'il voulait collaborer sur ce projet, pourrait prendre cette URL, la cloner sur son propre ordinateur et apporter ses propres modifications localement.
...21:34
Nous pouvons donc maintenant explorer comment nous pourrions également apporter des modifications supplémentaires à cette page Web. Donc, si, par exemple, je voulais ajouter un titre à cette page Web, par exemple, je pourrais dire en haut du body quelque chose comme, dans une balise h1, "Bienvenue sur mon site Web !" Et maintenant, si, juste pour faire bonne mesure, j'ouvre hello.html pour voir à quoi cela ressemble, voici à quoi ressemble ma page Web.
Et maintenant, j'ai apporté des modifications à mon fichier hello.html, des modifications qui n'ont pas encore été enregistrées, évident si j'exécute git status. git status est votre référence pour vous dire ce qui se passe actuellement dans votre référentiel. Nous voyons donc ici « Modifications non mises en scène (staged) pour la validation », ce qui est une façon élégante de dire les fichiers qui ont été modifiés, mais je n'ai pas dit que je voudrais en garder une trace lors de la prochaine validation. Cela me dit que j'ai modifié hello.html, mais ce n'est pas quelque chose dont Git va actuellement garder une trace la prochaine fois que je ferai une sauvegarde.
Donc, si je veux enregistrer hello.html lorsque je fais un commit pour la prochaine fois, je dois d'abord exécuter git add hello.html, puis je pourrais exécuter git commit. Mais il y a en fait un petit raccourci ici. Si vous souhaitez ajouter tous les fichiers qui ont été modifiés et exécuter un commit en même temps, le raccourci est git commit -am. Rappelez-vous, avant que nous n'utilisions -m pour dire, spécifiez un message. -am signifie que git commit tous les fichiers qui ont été modifiés - a pour tous(all) - et fournit également un message. Vous pouvez donc assimiler l'étape git add à l'étape git commit en une seule étape en disant, je voudrais valider tous les fichiers que j'ai modifiés, puis je fournirai un message. Qu'est-ce que j'ai changé exactement ? J'ai ajouté un titre. Je vais aller de l'avant et appuyer sur Retour. Git a gardé une trace du fait que j'ai maintenant modifié un fichier avec une seule insertion.
Et maintenant, si je lance git status, il va me dire, je suis sur branch master, et je suis en avance sur origin master -- origin master étant la version sur GitHub -- par un commit, car j'ai ici "Ajouter un header" commit, mais pour le moment, sur GitHub, si j'actualise cette page, l'ancienne version de cette page est toujours affichée. Afin de prendre mes modifications que j'ai apportées sur mon ordinateur et de m'assurer qu'elles sont mises à jour sur GitHub, je peux simplement exécuter git push pour dire, transmettre ces modifications à GitHub, et une fois cela fait, je peux maintenant actualiser sur GitHub, et je vais maintenant voir que GitHub dispose désormais de la dernière version de mon programme. Il a maintenant ce h1. On y voit: "Bienvenue sur mon site Web!"
C'est donc git push maintenant, la possibilité pour moi de dire que j'aimerais prendre les modifications que j'ai apportées à mon référentiel et les transmettre à un serveur distant, le serveur distant sur GitHub, par exemple. Mais on peut aussi faire le contraire. Vous pouvez imaginer que la version disponible sur GitHub est peut-être plus récente que la version que j'ai sur mon ordinateur, et dans ce cas, j'aimerais télécharger la dernière version du référentiel qui existe actuellement sur GitHub.
Et pour ce faire, nous pouvons utiliser une commande appelée git pull. Comment ça fonctionne? Eh bien, quand je lance git pull, ce qui va se passer est le contraire de ce que git push a fait. Alors que git push prenait mes modifications sur mon ordinateur et les transférait vers GitHub, git pull, nous verrons, prend les modifications qui existent actuellement sur GitHub, et va de l'avant et choisit les modifications les plus récentes, de sorte que moi et ma l version locale du référentiel ayont accès à la dernière version de tout le code actuellement sur GitHub.
Et nous pouvons le démontrer, par exemple, si je reviens sur le site Web de GitHub lui-même, car sur GitHub, j'ai en effet la possibilité de modifier des fichiers à l'aide de l'interface de GitHub. Je vais donc simuler quelqu'un d'autre travaillant sur ce projet, par exemple. Peut-être que quelqu'un d'autre a ajouté un deuxième titre, donc ils ajoutent un h2 qui dit simplement bonjour, par exemple. Et puis, ils peuvent fournir un message de validation. C'est en quelque sorte un équivalent graphique du -m, puis d'un message que nous avons fourni auparavant. Ils peuvent dire « Ajouté h2 », puis commit. C'est donc une autre façon de modifier un référentiel Git en le modifiant littéralement dans l'interface de GitHub. Ainsi, GitHub vous permet simplement de modifier un fichier, puis d'ajouter ou de modifier l'une des lignes qui s'y trouvent.
Alors maintenant, la version sur GitHub est en fait différente de la version que nous avons sur notre ordinateur, que si nous regardons hello.html ici, je ne vois que le h1, et je ne vois pas le h2 qui vient d'être ajouté, car c'est un commit plus récent auquel je n'ai pas encore accès. Mais si je veux télécharger ce commit, alors ce que je peux dire depuis mon terminal, je peux dire git pull pour le télécharger, et tout va bien. On aura mis à jour un fichier. On y a fait quelques changements. Et donc maintenant, si je reviens au fichier, vous remarquerez que j'ai automatiquement maintenant la dernière version du fichier. J'ai maintenant ce h2 qui dit "Bonjour!" parce que j'ai extrait la dernière version du fichier de GitHub. Donc, via la combinaison de get push et get pull, je peux apporter des modifications à mon code pour les pousser vers GitHub.
Mais en faisant cela, vous pourriez imaginer que nous pourrions rencontrer une sorte de
problème. En particulier, nous pourrions rencontrer un problème si j'ai apporté des modifications à mon code et que quelqu'un d'autre travaillant sur ce même projet a également apporté des modifications au code. Que se passe-t-il si nous apportons tous les deux des modifications à la même partie du code, puis essayons de synchroniser notre travail ensemble ? Qu'est-ce qui va se passer? Eh bien, nous allons nous heurter à une sorte de conflit, car j'ai apporté des modifications à cette même ligne où mon collègue a apporté des modifications, et ce type de conflit s'appelle un conflit de fusion, lorsque j'essaie de fusionner mon changement avec les changements que quelqu'un d'autre a apportés, nous nous retrouvons dans une situation où soudainement Git ne sait pas quoi faire. Ce sont deux ensembles de changements différents.
Voici donc ce qui va se passer. Si jamais nous rencontrons ce genre de conflit de fusion, cela se produira généralement si j'essaie d'intégrer ou de fusionner certaines modifications d'ailleurs. Supposons donc que je lance git pull, mais qu'il y ait un commit en conflit, quelque chose en ligne qui entre en conflit avec ma version actuelle du référentiel. Ce que je vais recevoir, c'est un message comme celui-ci. Certains conflits produisent un message que les conflits de fusion dans certains fichiers ont échoué. Vous devez résoudre les conflits, puis valider les résultats.
Alors à quoi pourraient ressembler ces conflits ? Eh bien, généralement, le fichier va ressembler à quelque chose comme ça. Git va automatiquement ajouter des métadonnées au fichier pour décrire les choses qu'il ne peut pas tout à fait comprendre, et c'est beaucoup d'informations cryptiques, mais nous pouvons les distiller en quelques parties clés. Tout ce qui se trouve entre ces flèches en haut et les signes égaux, voici vos modifications, les modifications que j'ai apportées à ma version du référentiel qui sont en quelque sorte en conflit avec d'autres modifications. Tout entre ces signes égaux et ces flèches vers le bas ici sont les changements à distance, les changements de GitHub que j'essaie d'intégrer et qui sont en quelque sorte en conflit avec ce sur quoi je travaille actuellement. Et puis cette séquence de chiffres et de caractères ici est le 'hach' de référence du commit en conflit. Ainsi, chaque commentaire reçoit un hachage, juste une séquence de nombres et de caractères qui est susceptible d'être unique qui aide à identifier un commit particulier, et Git générera automatiquement un hachage chaque fois que vous ferez un commentaire, et nous verrons dans un instant comment considérer tous ces commits possibles. Mais là encore, c'est juste pour nous dire utilement, c'est le commit qui cause le conflit, juste pour notre propre référence.
Afin de résoudre ce conflit de fusion, nous devons d'abord supprimer tous ces marqueurs de conflit de fusion qui existent dans le fichier texte et décider ce que nous voulons comme résolution du conflit. Alors peut-être que je veux garder ma version des changements ; peut-être que je veux conserver la version distante des modifications, les modifications qui étaient déjà sur GitHub, par exemple ; ou peut-être que je veux les combiner d'une manière raisonnée. Moi, le programmeur, je prends cette décision. Je peux regarder ma version et la version en conflit et décider comment je veux résoudre ce conflit. Je vais supprimer toutes les lignes vides, puis valider les modifications pour dire, voici à quoi je veux que la version fusionnée de ce programme ressemble.
Examinons maintenant un exemple de conflit de fusion en action, pour voir comment un conflit pourrait survenir et comment nous pourrions réellement gérer un conflit de fusion s'il devait se produire. Alors moi, sur mon ordinateur maintenant, je vais apporter une modification à cette page. Je vais dire, ajouter une deuxième exclamation. Un point d'exclamation ne suffisait pas. Je vais ajouter un deuxième point d'exclamation à ce h1, et je vais continuer et valider ces modifications. Je vais dire git commit -am "Ajouter un point d'exclamation" et je vais continuer et valider ces modifications. J'ai enregistré cette nouvelle version du programme.
Mais je ne vais pas encore pousser le code. Au lieu de cela, ce que je vais faire, c'est simuler quelqu'un d'autre travaillant sur le même fichier. Peut-être que quelqu'un d'autre sur GitHub a décidé, vous savez quoi ? Pour ce h1, ce que nous aimerions vraiment faire, c'est lui ajouter du style avec un style à la ligne en disant, donnons-lui une couleur de bleu, par exemple. Ils ont donc ajouté du CSS. Nous allons continuer et écrire un message de validation. Qu'ont-ils fait? Ils ont ajouté du style. Et nous allons valider ces changements.
Et maintenant, ce que nous avons créé, c'est ce qui va être un conflit de fusion, que quelqu'un d'autre sur GitHub a modifié cette ligne en changeant la couleur en bleu de cette balise h1 particulière, par exemple, et j'ai également fait une altération à la même ligne, en ajoutant un point d'exclamation. Et Git fonctionne entièrement en termes d'ajout et de suppression au niveau lignes. Étant donné que nous avons tous les deux apporté des modifications à la même ligne, Git aura beaucoup de mal à trouver quoi faire dans ce scénario.
Donc ici dans mon terminal, je vais continuer et lancer git pull, parce que je veux extraire ces dernières modifications, et quand je le ferai, je verrai que, d'accord, je reçois ce message. CONFLIT : Il y a eu un conflit de fusion dans hello.html. La fusion automatique a échoué, car normalement, Git essaiera de fusionner les fichiers automatiquement si possible, mais parfois ce n'est pas possible, alors je dois maintenant résoudre les conflits, puis valider les résultats.
Alors allons de l'avant et regardons ce qu'il y a à l'intérieur de hello.html, et ce que vous remarquerez, c'est tout un tas de ces marqueurs, et mon éditeur de texte trouve juste à les mettre en évidence pour moi, afin que je puisse les voir un peu plus clairement, mais ce n'est que la mise en évidence fournie par l'éditeur de texte. Cela ne fait pas vraiment partie du texte lui-même. Mais vous remarquerez toutes ces flèches, puis tous ces côtés égaux, et entre les deux, voici ma version de cette ligne de code, la ligne de code avec le point d'exclamation supplémentaire à la fin. En bas, voici la version conflictuelle à distance du même code, la version qui a été modifiée sur GitHub que j'essaie maintenant de récupérer. C'est la version qui dit, nous voulons la couleur de style bleu à l'intérieur du style à la ligne pour cet élément paritculier h1.
Et maintenant, ce que je dois faire, c'est trouver un moyen de fusionner ces deux éléments. Comment est-ce que je veux résoudre ce conflit ? Eh bien, dans ce cas particulier, j'aimerais peut-être résoudre ce conflit en prenant simplement le meilleur des deux mondes. Si la personne sur GitHub voulait ajouter un attribut de style à cet élément h1 et que je voulais le point d'exclamation supplémentaire, je peux faire les deux. Je peux aller de l'avant et simplement ajouter un point d'exclamation supplémentaire, puis me débarrasser de ma version, puis également me débarrasser de ces marqueurs de validation. Alors allez-y et supprimez-les. Je modifie essentiellement le fichier jusqu'à ce que j'en sois satisfait jusqu'à ce que je pense que, d'accord, c'est la façon dont je voulais résoudre le conflit. Une personne a ajouté de la couleur. Une personne a ensuite ajouté la ponctuation. La façon de le résoudre dans ce cas est simplement d'utiliser les deux.
Mais c'est ici qu'intervient une certaine intuition humaine. Le programmeur humain a besoin de regarder ce fichier et de comprendre, comment voulons-nous exactement résoudre ce conflit ? Comment voulons-nous comprendre comment prendre ces différents changements et les fusionner tous ensemble ?
Mais une fois que nous en sommes satisfaits, nous pouvons aller de l'avant et engager les résultats. Je peux dire git commit -am "Réparation du conflit de fusion", et d'accord, nous avons corrigé le conflit de fusion. Et maintenant, si je renvoie ces résultats à GitHub, lorsque cela est fait et que je rafraîchis la page, je vois maintenant la ligne de code mise à jour sur GitHub, avec le h1 qui a à la fois son nouveau style et la ponctuation supplémentaire, parce que je 'ai résolu le conflit de fusion, puis j'ai également renvoyé ces informations vers GitHub.
Alors maintenant, je vais vérifier à nouveau master. Et peut-être que je veux faire d'autres changements sur ma branche master. J'ai peut-être réalisé que je voulais supprimer cette ponctuation supplémentaire. Vous savez quoi? Deux points d'exclamation c'est trop. Nous allons supprimer-- maintenant nous n'en avons qu'un. Et maintenant, nous allons valider ces changements. Je vais dire git commit et "Supprimer la ponctuation". Et maintenant, j'ai supprimé la ponctuation uniquement de la branche master. Ainsi, cette branche principale n'a maintenant qu'un seul point d'exclamation ici, mais elle a toujours le style en ligne.
Alors maintenant, ce que j'aimerais faire, c'est fusionner les modifications que j'ai apportées à partir de l'autre branche. J'aimerais prendre ce sur quoi je travaillais dans la branche style et le fusionner dans cette version actuelle du référentiel sur ma branche master. Et pour ce faire, la commande que nous utiliserons s'appelle git merge. Alors git merge. Notez que je suis actuellement sur la branche master, mais si j'exécute git merge puis style, cela va prendre tout ce qui se trouve sur la branche style et tenter de le fusionner dans ma branche actuelle. Et ce que nous découvrirons, c'est que nous sommes capables d'y arriver la plupart du temps, mais il y a un conflit de fusion.
Maintenant, cela n'arrivera pas tout le temps lorsque vous fusionnerez. Parfois, Git sera suffisamment malin pour savoir que si une modification a été apportée à une partie d'un fichier et qu'une modification a été apportée à une autre partie d'un fichier, lorsque vous fusionnez ces modifications, Git résoudra ces conflits de fusion. automatiquement. Mais dans ce cas, ce n'était pas le cas, car ma branche style et ma branche master ont toutes deux apporté des modifications à la même ligne de code, et nous verrons pourquoi si je reviens ici.
Vous remarquerez que dans la version fusionnée, nous voyons cette balise de style en tête de page. Pas de problèmes, pas de conflit là-bas, car ce ne sont que des lignes qui ont été ajoutées à cette page, donc il n'y avait pas de conflit. Le conflit survient ici, c'est là que, dans ma version sur la branche master, j'ai supprimé ce signe de ponctuation, alors que dans la version sur la branche style, que l'on peut voir ici par le mot "style", on a supprimé le style à la ligne . Nous devons donc les résoudre d'une manière ou d'une autre. Et ce que je vais faire en fin de compte, c'est simplement me débarrasser de ces marqueurs de style ou des marqueurs de conflit, et dire, vous savez quoi ? J'aimerais que la version mise à jour n'ait pas non plus, n'ait pas de style à la ligne et n'ait pas la ponctuation supplémentaire. J'ai donc apporté ces modifications, j'ai résolu le conflit de fusion et je peux maintenant valider.
Et c'est là le flux de travail général de la façon dont la création de branches dans Git fonctionne finalement. Lorsque vous travaillez sur quelque chose de nouveau, vous pouvez bifurquer pour dire que vous aimeriez travailler sur une autre partie de cette application Web. Vous apporterez des modifications, effectuerez des commits, ajouterez des modifications à cette nouvelle branche, et lorsque vous serez satisfait de ces modifications, lorsqu'elles seront dans l'état que vous souhaitez qu'elles soient, vous pouvez alors dire les fusionner dans le version originale du référentiel. Parfois, vous devrez gérer des conflits de fusion, mais certainement pas toujours. Et si vous faites attention à l'endroit où vous apportez des modifications et essayez de faire attention à ne pas apporter de modifications à la même ligne de code à deux endroits différents, vous pouvez réduire la probabilité d'obtenir un conflit de fusion.
Et enfin, nous examinerons spécifiquement quelques fonctionnalités de GitHub qui peuvent être très utiles lorsque vous commencez à travailler sur des projets plus importants comportant de nombreuses pièces mobiles différentes, dont la première consiste à créer un référentiel GitHub. Allons donc dans un référentiel GitHub et regardons le référentiel GitHub pour Bootstrap, par exemple. Donc Bootstrap, qui est la bibliothèque CSS que nous avons examinée la dernière fois, est une bibliothèque qui nous donne un accès facile à tout un tas de fonctionnalités CSS différentes, et le tout est open-source, c'est-à-dire tout le code pour Bootstrap est accessible au public pour que tout le monde puisse le consulter, et plus important encore, pour que tout le monde puisse y contribuer, que ce n'est pas seulement une personne qui a travaillé sur tout Bootstrap, mais c'est un référentiel communautaire sur lequel de nombreuses personnes peuvent travailler, en ajoutant de nouvelles fonctionnalités.
Et donc, si vous trouvez un référentiel Git auquel vous aimeriez contribuer, ou si vous voulez que d'autres personnes puissent contribuer à votre référentiel, une chose que vous pouvez faire est de bifurquer ce référentiel, et par bifurquer (fork), nous voulons dire faire votre propre copie du référentiel d'origine. Et donc ici, dans le coin supérieur droit de la page GitHub, se trouve un bouton appelé Fork, et nous pouvons voir qu'à l'heure actuelle, environ 68 000 personnes ont déjà recréé le référentiel de Bootstrap, copié le référentiel dans leur propre compte GitHub. Et donc nous pourrions le forker nous-mêmes en cliquant simplement sur ce bouton appelé Fork, puis en obtenant notre propre version du référentiel que nous pouvons ensuite cloner et pousser et extraire également.
La raison pour laquelle nous pourrions le faire est que le référentiel de Bootstrap, bien qu'il soit public, ne permet à personne de simplement y accéder. Ce serait probablement dangereux si nèimporte qui dans le monde pouvait simplement mettre à jour le code principal de Bootstrap, mais ce que vous pouvez faire est de copier le code, d'en faire un fork, d'y apporter des modifications par vous-même, de le pousser et de l'extraire. Et puis, lorsque vous sentez que vous avez fait une contribution que vous souhaitez renvoyer à Bootstrap, vous pouvez ouvrir ce qu'on appelle une pull request, c'est-à-dire que vous demandez que votre code soit intégré au code de Bootstrap.
Et nous pouvons examiner, par exemple, l'onglet Pull Request de Bootstrap. Il semble qu'il y ait actuellement 71 demandes d'extraction ouvertes. Il y a 71 personnes qui ont apporté des correctifs ou des modifications au code de Bootstrap, et vous pouvez soumettre une pull request pour dire que vous souhaitez prendre ces modifications et les fusionner avec le code réel de Bootstrap, et les personnes qui tiennent à jour le code Bootstrap peuvent examiner ces demandes d'extraction, fournir des commentaires, demander des modifications supplémentaires, puis lorsque tout le monde est satisfait, ils peuvent fusionner ces modifications dans le code réel de Bootstrap.
Et c'est l'un des principaux avantages des logiciels open source, la possibilité pour plusieurs personnes de travailler sur le même morceau de code, et pour une communauté de pouvoir collaborer pour trouver des bogues afin de déterminer les changements à apporter, pour trouver comment améliorer un référentiel existant et le rendre meilleur à l'avenir.
Et une dernière chose à noter à propos de GitHub est une fonctionnalité supplémentaire connue sous le nom de pages GitHub. GitHub Pages est un moyen gratuit fourni par GitHub pour pouvoir rapidement prendre un site Web avec HTML et CSS, et peut-être même un peu de JavaScript, et le déployer sur Internet pour que tout le monde puisse le consulter. Et toute personne possédant un compte GitHub est autorisée à créer gratuitement un site Web GitHub Pages.
Et pour ce faire - nous pouvons le démontrer maintenant - tout ce que vous avez à faire dans GitHub est de créer un nouveau référentiel que nous appellerons - il devrait généralement être votre nom d'utilisateur, .github.io est le classique nom de votre site GitHub Pages, bien qu'il puisse avoir d'autres noms. Vous n'aurez qu'à activer manuellement les pages GitHub. Et nous allons continuer et créer ce référentiel maintenant. Si vous créez un référentiel de démarrage appelé votre nom d'utilisateur, .github.io, il prendra automatiquement en charge les pages GitHub, et cela signifie que je peux prendre cette URL et la cloner. Je peux donc dire git clone, suivi de cette URL. J'ai cloné un référentiel vide, mais je peux accéder à ce référentiel et y ajouter des fichiers. Je peux dire, ajoutons, par défaut, cela s'appelle un fichier index.html, et je vais créer un fichier HTML. C'est mon site. Et le corps de celui-ci dira simplement: "Ceci est mon site Web GitHub Pages." Donc quelque chose comme ça, quelque chose de simple.
Mais cela peut certainement être plus complexe si vous le souhaitez. Dans mon terminal, je vais git add ce fichier index.html et je ferai un commit. Et souvent, le premier commit, vous écrivez simplement, dans le message de commit, "First commit", afin que nous sachions qu'il s'agissait du premier commit, puis je transmettrai ces modifications à GitHub maintenant.
Donc, si vous transférez vos modifications vers un référentiel appelé votre nom d'utilisateur, .github.io, si vous jetez un œil aux paramètres et faites défiler vers le bas, vous verrez que les pages GitHub sont par défaut prêtes à être publiées. Et maintenant, si je clique sur cette URL, mon nom d'utilisateur, .github.io, vous le verrez déployé sur Internet, de sorte que tout le monde peut accéder à cette URL et la voir. Ils verront un gros titre indiquant « Ceci est le site Web de ma page GitHub », car c'est ainsi que le navigateur affiche le code HTML que j'ai poussé vers mon référentiel GitHub Pages.
Et l'avantage de faire cela, c'est qu'il est maintenant très facile de pouvoir mettre à jour rapidement mon site Web. Tout ce que j'ai à faire, c'est que si j'apporte une nouvelle modification, je peux valider cette modification, la transmettre à GitHub, et lorsque GitHub détecte que j'ai fait une transmission à mon référentiel GitHub Pages, alors il mettra à jour mon site Web que auquel tous dans le monde peuvent accéder en allant sur mon nom d'utilisateur, .github.io. Et cela vous permet d'exploiter toutes ces fonctionnalités de Git, la possibilité de créer des branches, la possibilité de travailler sur différentes fonctionnalités de votre page Web à différents moments et de revenir également à différentes versions du code.
Donc, dans l'ensemble, Git nous a fourni un certain nombre d'outils très puissants qui nous permettent désormais de suivre très rapidement et très facilement toutes les modifications que nous apportons au code, de savoir quand un morceau de code est mis à jour , et de revenir rapidement en arrière et d'examiner les anciennes versions de ce code si nécessaire, et en particulier, cela nous a donné la possibilité de prendre notre code et de travailler avec d'autres personnes , de sorte que nous pouvons travailler sur plusieurs parties d'un même projet, et quelqu'un d'autre travaillant sur le même projet peut également travailler sur plusieurs parties du même projet sur différentes branches, et il est alors très facile de synchroniser nos modifications afin de travailler ensemble.
Et donc Git est un outil très populaire utilisé, non seulement dans le monde de la programmation Web, mais surtout chaque fois qu'il s'agit de tout type de projet plus important, où plusieurs personnes peuvent travailler sur la même chose simultanément, Git nous permettra de développer plus facilement nos applications Web au cours de ce semestre.
.
