Git vs GitHub - Qu'est-ce que le contrôle de version et comment ça marche?

Avez-vous déjà été confus par le fonctionnement de Git et GitHub? Ne vous inquiétez pas, vous n'êtes pas seul. Git et GitHub peuvent parfois être délicats, mais à la fin de cet article, vous aurez une bonne compréhension des deux.

Au début, il peut être tentant de croire que Git et GitHub sont la même chose. Mais en réalité, ils ne le sont pas. En effet, il est possible d'utiliser Git sans GitHub! Et finalement, les deux existent à des fins différentes.

Cet article commencera par examiner attentivement les objectifs de Git et GitHub. Par la suite, nous découvrirons les principales différences entre ces deux technologies vitales.

Sans plus tarder, commençons avec Git.

Qu'est-ce que Git?

Git est un système de contrôle de version distribué (DVCS) utilisé pour enregistrer différentes versions d'un fichier (ou d'un ensemble de fichiers) afin que n'importe quelle version soit récupérable à volonté.

Git facilite également l'enregistrement et la comparaison de différentes versions de fichiers. Cela signifie que les détails sur ce qui a changé, qui a changé quoi ou qui a lancé un problème peuvent être consultés à tout moment.

Mais si Git est un système de contrôle de version distribué, que signifient exactement ces termes?

Que signifie «distribué»?

Le terme «distribué» signifie que chaque fois que vous demandez à Git de partager le répertoire d'un projet, Git ne partage pas seulement la dernière version du fichier. Au lieu de cela, il distribue toutes les versions enregistrées pour ce projet.

Ce système «distribué» contraste fortement avec les autres systèmes de contrôle de version. Ils ne partagent que la version unique qu'un utilisateur a explicitement extraite de la base de données centrale / locale.

D'accord, donc «distribué» signifie distribuer toutes les versions - pas seulement quelques-unes - des fichiers d'un projet que Git a enregistrés. Mais qu'est-ce qu'un système de contrôle de version exactement?

Qu'est-ce qu'un système de contrôle de version?

Un système de contrôle de version (VCS) fait référence à la méthode utilisée pour enregistrer les versions d'un fichier pour référence future.

Intuitivement, beaucoup de gens déjà le contrôle de version leurs projets en renommant les différentes versions du même fichier de diverses manières comme blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, et ainsi de suite. Mais cette approche est sujette aux erreurs et inefficace pour les projets d'équipe.

En outre, suivre ce qui a changé, qui l'a changé et pourquoi il a été changé est une tâche fastidieuse avec cette approche traditionnelle. Cela met en lumière l'importance d'un système de contrôle de version fiable et collaboratif comme Git.

Cependant, pour tirer le meilleur parti de Git, il est essentiel de comprendre comment Git gère vos fichiers.

États des fichiers dans Git

Dans Git, il y a trois états principaux (conditions) dans laquelle un fichier peut être: état modifié , l' état mis en scène , ou l' État engagé .

État modifié

Un fichier à l'état modifié est un fichier révisé - mais non validé (non enregistré).

En d'autres termes, les fichiers à l'état modifié sont des fichiers que vous avez modifiés mais que vous n'avez pas explicitement demandé à Git de surveiller.

État par étapes

Les fichiers à l'état intermédiaire sont des fichiers modifiés qui ont été sélectionnés - dans leur état actuel (version) - et sont en cours de préparation pour être enregistrés (validés) dans le .gitréférentiel lors du prochain instantané de validation.

Une fois qu'un fichier est mis en scène, cela implique que vous avez explicitement autorisé Git à surveiller la version de ce fichier.

État engagé

Les fichiers à l'état validé sont des fichiers correctement stockés dans le .gitréférentiel.

Ainsi, un fichier validé est un fichier dans lequel vous avez enregistré sa version intermédiaire dans le répertoire (dossier) Git.

Remarque: l'état d'un fichier détermine l'emplacement où Git le placera.

Emplacements des fichiers

Il y a trois endroits clés où les versions d'un fichier peuvent résider pendant le contrôle de version avec Git: le répertoire de travail , la zone de préparation ou le répertoire Git .

Directeur de travail

Le répertoire de travail est un dossier local pour les fichiers d'un projet. Cela signifie que tout dossier créé n'importe où sur un système est un répertoire de travail.

Remarque:

  • Les fichiers à l'état modifié résident dans le répertoire de travail.
  • Le répertoire de travail est différent du .gitrépertoire. Autrement dit, vous créez un répertoire de travail pendant que Git crée un .gitrépertoire.
  • Consultez cet article de comparaison pour plus de différences entre les deux référentiels.

Zone de transit

La zone de transfert - techniquement appelée «index» dans le jargon Git - est un fichier, généralement situé dans le .gitrépertoire, qui stocke des informations sur les fichiers suivants à valider dans le .gitrépertoire.

Remarque:

  • Les fichiers à l'état intermédiaire résident dans la zone intermédiaire.

Répertoire Git

Le .gitrépertoire est le dossier (également appelé «référentiel») que Git crée dans le répertoire de travail que vous lui avez demandé de suivre.

En outre, le .gitdossier est l'endroit où Git stocke les bases de données d'objets et les métadonnées du ou des fichiers que vous lui avez demandé de surveiller.

Remarque:

  • Le .gitrépertoire est la vie de Git - c'est l'élément copié lorsque vous clonez un référentiel à partir d'un autre ordinateur (ou d'une plateforme en ligne comme GitHub).
  • Les fichiers à l'état validé résident dans le répertoire Git.

Le workflow de base de Git

Travailler avec le système de contrôle de version Git ressemble à ceci:

Diagramme de flux de travail de base Git
  1. Modifiez les fichiers dans le répertoire de travail.

    Notez que tout fichier que vous modifiez devient un fichier à l' état modifié .

  2. Mettez en scène de manière sélective les fichiers que vous souhaitez valider dans le .gitrépertoire.

    Notez que tout fichier que vous placez (ajoutez) dans la zone intermédiaire devient un fichier à l' état intermédiaire .

    Sachez également que les fichiers intermédiaires ne sont pas encore dans la .gitbase de données.

    Le transfert signifie que les informations sur le fichier intermédiaire sont incluses dans un fichier (appelé «index») du .gitréférentiel.

  3. Validez le ou les fichiers que vous avez stockés dans le .gitrépertoire. Autrement dit, stockez en permanence un instantané du (des) fichier (s) intermédiaire (s) dans la .gitbase de données.

    Notez que toute version de fichier que vous validez dans le .gitrépertoire devient un fichier à l' état validé .

L'essentiel jusqu'à présent

Le long et court de toute la discussion jusqu'à présent est que Git est un système de contrôle de version brillant pour le contrôle de version, la gestion et la distribution compétents des fichiers. Consultez ce guide simple pour apprendre à utiliser Git efficacement.

Mais attendez une seconde, si Git aide à gérer et distribuer efficacement différentes versions du fichier d'un projet, quel est le but de GitHub?

GitHub démystifié

GitHub est une plate-forme Web sur laquelle les utilisateurs peuvent héberger des référentiels Git. Il vous aide à faciliter le partage et la collaboration sur des projets avec n'importe qui à tout moment.

GitHub encourage également une participation plus large aux projets open source en fournissant un moyen sécurisé de modifier des fichiers dans le référentiel d'un autre utilisateur.

Pour héberger (ou partager) un référentiel Git sur GitHub, suivez les étapes ci-dessous:

Étape 1: Inscrivez-vous pour un compte GitHub

La première étape pour commencer l'hébergement sur GitHub est de créer un compte personnel. Visitez la page d'inscription officielle pour vous inscrire.

Étape 2: créer un référentiel distant dans GitHub

Après vous être inscrit à un compte, créez un domicile (un référentiel) dans GitHub pour le référentiel Git que vous souhaitez partager.

Étape 3: connectez le répertoire Git du projet au référentiel distant

Une fois que vous avez créé un référentiel distant pour votre projet, liez le .gitrépertoire du projet - situé localement sur votre système - avec le référentiel distant sur GitHub.

Pour vous connecter au référentiel distant, allez dans le répertoire racine du projet que vous souhaitez partager via votre terminal local, et exécutez:

git remote add origin //github.com/yourusername/yourreponame.git

Remarque:

  • Remplacez yourusernamele code ci-dessus par votre nom d'utilisateur GitHub.

    De même, remplacez-le yourreponamepar le nom du référentiel distant auquel vous souhaitez vous connecter.

  • La commande ci-dessus implique que git doit ajouter l' URL spécifiée au projet local en tant que référence distante avec laquelle le .gitrépertoire local peut interagir.
  • L' originoption dans la commande ci-dessus est le nom par défaut (un nom court) que Git donne au serveur hébergeant votre référentiel distant.

    Autrement dit, au lieu de l'URL du serveur, Git utilise le nom court origin.

  • Il n'est pas obligatoire de conserver le nom par défaut du serveur. Si vous préférez un autre nom plutôt que origin, remplacez simplement le originnom dans la git remote addcommande ci-dessus par le nom que vous préférez.
  • Souvenez-vous toujours que le nom court d'un serveur (par exemple   origin) n'a rien de spécial! Il n'existe que localement pour vous aider à référencer facilement l'URL du serveur. Alors n'hésitez pas à le changer en un nom court que vous pouvez facilement référencer.
  • Pour renommer une URL distante existante, utilisez la git remote renamecommande comme suit:
git remote rename theCurrentURLName yourNewURLName
  • Chaque fois que vous clonez (téléchargez) un dépôt distant, Git nomme automatiquement l'URL de ce dépôt origin. Cependant, vous pouvez spécifier un nom différent avec la git clone -o yourPreferredNamecommande.
  • Pour voir l'URL exacte stockée pour les surnoms comme origin, exécutez la git remote -vcommande.

Étape 4: Confirmer la connexion

Une fois que vous avez connecté votre répertoire Git au référentiel distant, vérifiez si la connexion a réussi en exécutant git remote -vsur la ligne de commande.

Ensuite, vérifiez la sortie pour confirmer que l' URL affichée est la même que l' URL distante à laquelle vous souhaitez vous connecter.

Remarque:

  • Consultez l'article «Connexion avec SSH» si vous souhaitez vous connecter à l'aide de l'URL SSH au lieu de l'URL HTTPS.
  • Cependant, si vous n'êtes pas sûr de l'URL distante à utiliser, consultez la section "Quelle URL distante dois-je utiliser?" article.
  • Souhaitez-vous modifier votre URL distante? Changer l'URL d'une télécommande est un excellent guide.

Étape 5: Poussez un dépôt Git local vers le dépôt distant

Après avoir connecté avec succès votre répertoire local au référentiel distant, vous pouvez alors commencer à pousser (télécharger) votre projet local en amont.

Chaque fois que vous êtes prêt à partager votre projet ailleurs, sur n'importe quel .gitréférentiel distant, demandez simplement à Git de pousser tous vos commits, branches et fichiers de votre répertoire local vers le référentiel distant.

La syntaxe de code utilisée pour télécharger (pousser) un répertoire Git local vers un référentiel distant est git push -u remoteName branchName.

Autrement dit, pour pousser votre .gitrépertoire local , et en supposant que le nom court de l'URL distante est «origin», exécutez:

git push -u origin master

Remarque:

  • La commande ci-dessus implique que git devrait pousser votre branche principale locale vers la branche principale distante située à l'URL nommée origin .
  • Techniquement, vous pouvez remplacer l' originoption par l'URL du référentiel distant. N'oubliez pas que l' originoption n'est qu'un surnom de l'URL que vous avez enregistrée dans votre .gitrépertoire local .
  • L' -uindicateur (indicateur de référence amont / suivi) relie automatiquement la .gitbranche locale du répertoire à la branche distante. Cela vous permet d'utiliser git pullsans aucun argument.

Étape 6: Confirmer le téléchargement

Enfin, revenez à la page de votre référentiel GitHub pour confirmer que Git a correctement poussé votre répertoire Git local vers le référentiel distant.

Remarque:

  • Vous devrez peut-être actualiser la page du référentiel distant pour que les modifications soient reflétées.
  • GitHub dispose également d'une fonction facultative gratuite pour convertir votre référentiel distant en un site Web fonctionnel. Voyons «comment» ci-dessous.

Publiez votre site Web avec des pages GitHub

Après avoir poussé votre projet vers votre référentiel distant, vous pouvez facilement le publier sur le Web comme ceci:

  1. Assurez-vous que le nom du fichier HTML principal de votre projet est index.html.
  2. Sur la plate-forme du site Web de GitHub, accédez au référentiel du projet que vous souhaitez publier et cliquez sur l' onglet Paramètres du référentiel .
  3. Faites défiler jusqu'à la section Pages GitHub et changez la branche Source de none à master .
  4. Ensuite, une notification disant: "Votre site est publié à l' adresse //votre-nomdutilisateur.github.io/votre-github-repo-name/ " s'affichera.
  5. Vous pouvez maintenant afficher - et publier - votre projet à l'URL spécifiée.

Cette section n'a fait qu'effleurer la surface de publication de votre projet avec GitHub. Pour en savoir plus sur les pages GitHub, consultez cette documentation «Utilisation des pages GitHub».

En bref

GitHub est une plateforme en ligne pour l'hébergement (ou le partage) de référentiels Git. Il vous aide à créer une avenue pour collaborer facilement sur des projets avec n'importe qui, n'importe où, à tout moment.

Toujours dans le doute?

Êtes-vous toujours perplexe quant à la distinction entre Git et GitHub? Ne vous inquiétez pas, je vous ai couvert. Vous trouverez ci-dessous cinq différences clés entre Git et GitHub.

Différence 1: Git vs GitHub - Fonction principale

Git est un système de contrôle de version distribué qui enregistre différentes versions d'un fichier (ou d'un ensemble de fichiers). Il permet aux utilisateurs d'accéder, de comparer, de mettre à jour et de distribuer n'importe laquelle des versions enregistrées à tout moment.

Cependant, GitHub est principalement une plateforme d'hébergement pour l'hébergement de référentiels Git en ligne. Il permet aux utilisateurs de garder leur référentiel distant privé ou ouvert aux efforts de collaboration.

Différence 2: Git vs GitHub - Plateforme d'exploitation

Les utilisateurs installent et exploitent Git sur leurs machines locales. Cela signifie que la plupart des opérations de Git sont réalisables sans Internet.

GitHub, cependant, est un service Web qui fonctionne uniquement en ligne. Cela signifie que vous avez besoin d'Internet pour faire quoi que ce soit sur GitHub.

Différence 3: Git vs GitHub - Inventeurs

Linus Torvalds a commencé le développement de Git en avril 2005.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner et Scott Chacon ont fondé GitHub.com en février 2008.

Différence 4: Git vs GitHub - Maintainers

En juillet 2005, Linus Torvalds a confié la maintenance de Git à Junio ​​C. Hamano - qui en est le responsable depuis lors.

Et Microsoft a acquis GitHub en octobre 2018.

Différence 5: Git vs GitHub - Concurrents

Les alternatives populaires à Git sont Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion et IBM Rational ClearCase.

Les concurrents les plus proches de GitHub sont GitLab, Bitbucket, SourceForge, Cloud Source Repositories et AWS CodeCommit.

En tout

Git et GitHub sont deux entités différentes qui vous aident à gérer et à héberger des fichiers. En d'autres termes, Git sert à contrôler les versions de fichiers tandis que GitHub est une plate-forme pour l'hébergement de référentiels Git.

Ressource utile

  • Comment utiliser Git - Un guide étonnant avec des astuces géniales