Tutoriel Git pour les débutants

Le développement de logiciels est un travail collaboratif. En tant qu'ingénieur logiciel, vous devez partager votre travail avec les autres. Mais partager du code et collaborer peut devenir compliqué. Il est difficile de suivre les divers changements qui se produisent au cours du cycle de vie d'un logiciel. Les équipes de développement s'appuient donc sur des outils de contrôle de version pour faciliter le processus de collaboration logicielle. Git est l'un des outils de contrôle de version les plus importants de l'industrie du logiciel.

Conseil: Dans ce tutoriel, vous apprendrez à utiliser les bases de Git. Chaque section se termine par quelques questions. Vous pouvez lire les questions avant de commencer à lire la section. Cela vous aidera à comprendre et à prêter attention aux points importants.

Amusez-vous à apprendre Git!

Git : un bref aperçu

Git est un système de contrôle de version distribué. Il garde une trace de toutes les modifications que vous apportez à vos fichiers et dossiers. Il facilite la sauvegarde de votre travail en cours. S'il y a un problème, vous pouvez facilement vérifier une version antérieure du fichier ou du dossier. Si nécessaire, vous pouvez même restaurer l'intégralité de votre base de code vers une ancienne version.

Le développement de Git a commencé en 2005. Le groupe de noyau Linux utilisé pour maintenir leur code dans BitKeeper, un système de contrôle de version distribué propriétaire. Cependant, BitKeeper a retiré son utilisation gratuite du produit. Ainsi, Linus Torvalds, le créateur et développeur principal de Linux, a conçu un nouveau système de contrôle de version distribué open source qui répondrait aux exigences de la communauté de développement Linux. Et Git est né.

En tant que système de contrôle de version distribué, Git ne nécessite pas d'autorité centralisée pour garder une trace du code. Les anciens contrôles de version centralisés comme CVS, SVN ou Perforce nécessitent des serveurs centraux pour conserver l'historique des modifications. Git peut suivre tous les changements localement et travailler en peer-to-peer. Il est donc plus polyvalent que les systèmes centralisés.

Des questions:

Pourquoi devriez-vous utiliser Git?
Quel est l'avantage du contrôle de version distribué?

Installation de Git

Pour les systèmes Linux, l'installation de Git est simple. Si vous utilisez une distribution basée sur Debian comme Ubuntu, vous pouvez utiliser apt install :

$ sudo apt installer git-all

Pour Fedora, RHEL ou CentOS, vous pouvez utiliser :

$ sudo dnf installer git-all

Vous pouvez vérifier si Git a été installé à l'aide de la commande suivante :

$ git --version

Il devrait vous montrer la version du Git que vous avez installé, par exemple :

git version 2.17.0

Une fois que vous avez installé Git, il est temps de configurer votre nom d'utilisateur et votre e-mail :

$ git config --utilisateur global.nom "votre nom d'utilisateur"
$ git config --utilisateur global.email "[email protégé]"

Vous pouvez vérifier si les configurations ont été correctement définies à l'aide de la commande suivante :

$ git config --list
utilisateur.nom=votre nom d'utilisateur
utilisateur.email=votrenom d'[email protected]

Conseil: Il est important de définir l'utilisateur.nom et utilisateur.email car ces configurations sont utilisées pour suivre vos modifications.

Des questions

Quelle est la commande pour installer Git sur votre système Linux?
Pourquoi devriez-vous configurer l'utilisateur.nom et utilisateur.configuration de la messagerie? Comment les paramétrer?

Comprendre Git de manière conceptuelle

Pour utiliser Git, vous devez d'abord comprendre ces quatre concepts :

Directeur de travail
Zone de transit
Dépôt
Référentiel distant

Le répertoire de travail, la zone de transit et le référentiel sont locaux sur votre machine. Le référentiel distant peut être n'importe quel autre ordinateur ou serveur. Considérons ces concepts comme quatre boîtes pouvant contenir des papiers A1 standard.

Supposons que vous écriviez un document à la main sur un papier A1 à votre bureau. Vous gardez ce document dans la boîte du répertoire de travail. A un certain stade de votre travail, vous décidez que vous êtes prêt à conserver une copie du travail que vous avez déjà effectué. Vous faites donc une photocopie de votre papier actuel et le mettez dans la boîte de mise en scène.

La zone de transit est une zone temporaire. Si vous décidez de jeter la photocopie dans la boîte de mise en scène et de la mettre à jour avec une nouvelle copie du document du répertoire de travail, il n'y aura aucun enregistrement permanent de ce document mis en place.

Supposons que vous soyez à peu près sûr de vouloir conserver l'enregistrement permanent du document que vous avez dans la boîte de transfert. Ensuite, vous faites une photocopie du document de la boîte de transfert et le déplacez vers la boîte de référentiel.

Lorsque vous le déplacez vers la zone de référentiel, deux choses se produisent :

Un instantané du document est enregistré en permanence.
Une entrée de fichier journal est créée pour accompagner l'instantané.

L'entrée de journal vous aidera à trouver cet instantané particulier de votre document si vous en avez besoin à l'avenir.

Maintenant, dans la boîte de référentiel local, vous avez un instantané de votre travail et une entrée de journal. Mais il n'est disponible que pour toi. Vous faites donc une copie de votre document de référentiel local avec le fichier journal et le placez dans une boîte dans la salle d'approvisionnement de l'entreprise. Désormais, n'importe qui dans votre entreprise peut venir faire une copie de votre document et l'apporter à son bureau. La boîte dans la salle des fournitures serait le référentiel distant.

Le référentiel distant est un peu comme partager votre document à l'aide de Google Docs ou Dropbox.

Des questions:

Pouvez-vous définir le répertoire de travail, le staging, le référentiel et le référentiel distant?
Pouvez-vous dessiner comment les documents passent d'une étape à une autre?

Votre premier dépôt Git

Une fois Git installé, vous pouvez commencer à créer vos propres référentiels Git. Dans cette section, vous allez initialiser votre référentiel Git.

Supposons que vous travaillez sur un projet de développement Web. Créons un dossier appelé project_helloworld et changeons dans le répertoire :

$ mkdir project_helloworld
$ cd project_helloworld

Vous pouvez demander à Git de surveiller ce répertoire avec la commande suivante :

$ git init

Vous devriez voir une sortie comme celle-ci :

Dépôt Git vide initialisé dans /Users/zakh/_work/LearnGIT/git_tutorial/
project_helloworld/.git

Désormais, tous les fichiers et dossiers à l'intérieur de project_helloworld seront suivis par Git.

Des questions:

Comment initialiser un répertoire à suivre par Git?

Commandes Git de base : status, log, add et commit

La commande status affiche l'état actuel de votre répertoire de travail et la commande log affiche l'historique. Essayons la commande status :

$ git statut
Sur le maître de branche
Validation initiale
rien à valider (créer/copier des fichiers et utiliser "git add" pour suivre)

La sortie de la commande git status indique que vous êtes sur la branche master. C'est la branche par défaut que Git initialise. (Vous pouvez créer vos propres branches. Plus d'informations sur les succursales plus tard). De plus, la sortie dit qu'il n'y a rien à s'engager.

Essayons la commande log :

$ git log
fatal : votre branche 'master' actuelle n'a pas encore de commits

Alors, il est temps de créer du code. Créons un fichier appelé index.html :

Ma page Web

Bonjour le monde

Vous pouvez utiliser l'éditeur de texte pour créer le fichier. Une fois que vous avez enregistré le fichier, vérifiez à nouveau l'état :

$ git statut
Sur le maître de branche
Validation initiale
Fichiers non suivis :
(utilisez "git add …" à inclure dans ce qui sera engagé)
indice.html
rien d'ajouté à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour suivre)

Git vous dit que vous avez un fichier appelé index.html dans votre répertoire de travail qui n'est pas suivi.

Assurons-nous que l'index.html est suivi. Vous devrez utiliser la commande add :

$ git ajouter un index.html

Alternativement, vous pouvez utiliser le ".” Option pour tout ajouter dans le répertoire :

$ git ajouter .

Maintenant, vérifions à nouveau l'état :

$ git statut
Sur le maître de branche
Validation initiale
Modifications à valider :
(utilisez "git rm --cached … " pour désinstaller)
nouveau fichier : index.html

Le vert indique que l'index.le fichier html est suivi par Git.

Conseil: Comme mentionné dans les instructions ci-dessus, si vous utilisez la commande :

$ git rm --index en cache.html

Votre indice.html reviendra au statut non suivi. Vous devrez l'ajouter à nouveau pour le ramener à la mise en scène.]

Vérifions à nouveau le journal :

$ git log
fatal : votre branche 'master' actuelle n'a pas encore de commits

Donc, même si Git suit l'index.html, il n'y a encore rien dans le référentiel Git à propos du fichier. Validons nos modifications :

$ git commit -m "Index de validation.html"
La sortie devrait ressembler à ceci :
[master (root-commit) f136d22] Indice de validation.html
1 fichier modifié, 6 insertions (+)
créer le mode 100644 index.html

Le texte à l'intérieur des guillemets après le "-m" est un commentaire qui ira dans le fichier journal. Vous pouvez utiliser git commit sans "-m", mais Git ouvrira alors un éditeur de texte vous demandant d'écrire les commentaires. Il est plus facile de simplement mettre les commentaires directement sur la ligne de commande.

Vérifions maintenant notre fichier journal :

$ git log
commettre f136d22040ba81686c9522f4ff94961a68751af7
Auteur : Zak H
Date : Lun 4 juin 16:53:42 2018 -0700
Indice d'engagement.html

Vous pouvez voir qu'il affiche un commit. Vous avez validé avec succès vos modifications dans votre référentiel local. Si vous souhaitez voir le même journal de manière concise, vous pouvez utiliser la commande suivante :

$ git log --oneline
f136d22 Indice de validation.html

À l'avenir, nous utiliserons cette forme de commande log car elle permet de comprendre plus facilement ce qui se passe.

Commençons à éditer l'index.html. Ouvrir l'index.html dans un éditeur et remplacez la ligne « Hello world » par « Hello world! C'est moi!" et enregistrez-le. Si vous vérifiez à nouveau le statut, vous verrez que Git a remarqué que vous modifiez le fichier :

$ git statut
Sur le maître de branche
Modifications non préparées pour la validation :
(utilisez "git add …" pour mettre à jour ce qui sera engagé)
(utilisez "git checkout -- … " pour annuler les modifications dans le répertoire de travail)
modifié : index.html
aucun changement ajouté au commit (utilisez "git add" et/ou "git commit -a")

La modification est toujours dans votre répertoire de travail. Vous devez le pousser vers la zone de transit. Utilisez la commande add que vous avez utilisée auparavant :

$ git ajouter .

Vérifiez à nouveau l'état :

$ git statut
Sur le maître de branche
Modifications à valider :
(utilisez "git reset HEAD … " pour désinstaller)
modifié : index.html

Vos modifications sont maintenant dans la zone de transit. Vous pouvez le valider dans le référentiel pour une sauvegarde permanente :

$ git commit -m "Index modifié.html à un message plus heureux"
[master 0586662] Index modifié.html à un message plus heureux
1 fichier modifié, 1 insertion(+), 1 suppression(-)

Vous pouvez consulter le journal pour vos modifications permanentes :

$ git log --oneline
0586662 Indice modifié.html à un message plus heureux
f136d22 Indice de validation.html

Dans cette section, vous avez appris à utiliser les commandes status, log, add et commit pour garder une trace de vos documents dans Git.

Des questions:

A quoi sert le statut git?
Que fait git log?
Que fait git add?
Que fait git commit?

Revenir à des fichiers plus anciens à l'aide de Checkout

Lorsque vous validez un fichier dans Git, il crée un hachage unique pour chaque validation. Vous pouvez les utiliser comme identifiants pour revenir à une ancienne version.

Supposons que vous vouliez revenir à votre version précédente d'index.html. Tout d'abord, regardons l'index.html dans l'état actuel :

indice de chat $.html

Ma page Web

Bonjour le monde! C'est moi!

Vous pouvez voir que vous avez la nouvelle version ("Hello world! C'est moi!”). Vérifions le journal :

$ git log --oneline
0586662 Indice modifié.html à un message plus heureux
f136d22 Indice de validation.html

Le hachage pour la version précédente était f136d22 ("Hello world"). Vous pouvez utiliser la commande checkout pour accéder à cette version :

$ git caisse f136d22
Remarque : vérifier 'f136d22'.
Vous êtes dans l'état « TÊTE détachée ». Vous pouvez regarder autour de vous, faire des changements expérimentaux
et les valider, et vous pouvez supprimer tous les commits que vous faites dans cet état
sans impacter les succursales en effectuant une autre vérification.
Si vous souhaitez créer une nouvelle branche pour conserver les commits que vous créez, vous pouvez
faites-le (maintenant ou plus tard) en utilisant à nouveau -b avec la commande checkout. Exemple:
git checkout -b
HEAD est maintenant à f136d22… Indice de validation.html

Si vous regardez le contenu de l'index.html, vous verrez :

indice de chat $.html

Ma page Web

Bonjour le monde

Il n'a que "Hello world". Donc ton indice.html a changé pour l'ancienne version. Si vous vérifiez l'état :

$ git statut
TÊTE détachée à f136d22
rien à valider, répertoire de travail propre

Git vous dit essentiellement que le HEAD n'est pas au plus récent commit. Vous pouvez revenir au commit le plus récent en vérifiant la branche master à l'aide de la commande suivante :

$ git checkout maître
La position précédente de HEAD était f136d22… Indice de validation.html
Basculé vers la branche 'master'

Maintenant, si vous vérifiez le statut :

$ git statut
Sur le maître de branche
rien à valider, répertoire de travail propre

L'avertissement rouge est parti. Aussi, si vous vérifiez votre index.html, vous devriez revenir à la dernière version :

indice de chat $.html

Ma page Web

Bonjour le monde! C'est moi!

La commande de paiement vous permet d'accéder à différents états. Nous en apprendrons plus sur le paiement dans la section suivante.

Des questions:

Comment utiliser la commande git checkout pour accéder à une ancienne version d'un fichier?
Comment utilisez-vous git checkout pour revenir à la dernière version du fichier?

Extraction, branchement et fusion

Le branchement est l'une des meilleures fonctionnalités de Git. Cela vous aide à séparer votre travail et à expérimenter davantage. Dans d'autres systèmes de contrôle de version, le branchement était long et difficile. Git a facilité la création de branches et la fusion.

Comme vous l'avez remarqué dans la commande status, lorsque vous créez un nouveau référentiel Git, vous êtes dans la branche master.

$ git statut
Sur le maître de branche
rien à valider, répertoire de travail propre

Supposons que vous créez un site Web pour votre ami David. Vous souhaitez réutiliser le code de votre propre site web. La ramification est une excellente solution. Appelons la branche david_website.

Vous pouvez lancer la commande suivante :

$ git branch david_website

Vous pouvez utiliser la commande suivante pour voir toutes les branches :

$ git branch --list
david_site
* Maître

L'étoile (*) à côté de master signifie que vous êtes toujours dans la branche master. Vous pouvez consulter la branche david_website avec la commande suivante :

$ git checkout david_website
Basculé vers la branche 'david_website'

Maintenant, si vous vérifiez à nouveau la liste des branches, vous voyez :

$ git branch --list
* david_site web
Maître

Vous êtes donc sur la branche david_website.

Changeons l'index.html de "Bonjour tout le monde! C'est moi!" à "Bonjour tout le monde! C'est David!», puis le mettre en scène et le valider :

$ git ajouter .
$ git commit -m "Changement de site Web pour David"

Si vous vérifiez les journaux, vous devriez voir :

$ git log --oneline
345c0f4 Site Web modifié pour David
0586662 Indice modifié.html à un message plus heureux
f136d22 Indice de validation.html

Et votre fichier d'index devrait ressembler à ceci :

indice de chat $.html

Ma page Web

Bonjour le monde! C'est David!

Examinons à nouveau la branche master :

$ git checkout maître
Basculé vers la branche 'master'

Si vous vérifiez l'état et enregistrez :

$ git statut
Sur le maître de branche
rien à valider, répertoire de travail propre
$ git log --oneline
0586662 Indice modifié.html à un message plus heureux
f136d22 Indice de validation.html

Remarquez que vous n'avez pas votre troisième commit dans le maître. Parce que ce commit n'est maintenu que dans la branche david_website.

C'est ce qui s'est passé

Supposons qu'à ce stade vous décidez, vous ne voulez pas continuer votre site Web. Tu seras juste le développeur de David. Vous souhaitez donc fusionner les modifications de la branche david_website avec le maître. Depuis la branche master, il suffit de lancer les commandes suivantes (la commande status permet de vérifier si vous êtes au bon endroit) :

$ git statut
Sur le maître de branche
rien à valider, répertoire de travail propre

$ git merge david_website
Mise à jour 0586662… 345c0f4
Avance rapide
indice.html | 2 +-
1 fichier modifié, 1 insertion(+), 1 suppression(-)

Conseil: Vous transférez les modifications de david_website vers master. Il faut être sur le maître pour y parvenir.

Maintenant, si vous vérifiez le journal sur le maître, vous voyez que le troisième commit est là :

$ git log --oneline
345c0f4 Site Web modifié pour David
0586662 Indice modifié.html à un message plus heureux
f136d22 Indice de validation.html

Vous avez fusionné avec succès la branche david_website dans master. Et ton indice.html pour la branche master semble identique à la branche david_website :

indice de chat $.html

Ma page Web

Bonjour le monde! C'est David!

Vous pouvez conserver la branche david_website :

$ git branch --list
david_site
* Maître

Ou vous pouvez le supprimer :

$ git branch -d david_website
Branche supprimée david_website (anciennement 345c0f4).

Après la suppression, vous ne devriez plus voir la branche david_website :

$ git branch --list
* Maître

Conseil: Lors d'une fusion, si Git ne peut pas fusionner automatiquement, cela vous donnera des erreurs de conflit de fusion. Dans ce cas, vous devez résoudre manuellement les problèmes de fusion.

Des questions:

Pourquoi avez-vous besoin de branchement?
Comment créer des branches et fusionner des fichiers et des dossiers?

Référentiel distant

Jusqu'à présent, tout votre travail a été local. Vous avez validé vos modifications dans un référentiel local. Mais il est temps de partager votre travail avec le monde.

Le référentiel distant Git est essentiellement une autre copie de votre référentiel local accessible par d'autres. Vous pouvez configurer un serveur et en faire le référentiel distant. Mais la plupart des gens utilisent GitHub ou Bitbucket à cette fin. Vous pouvez y créer gratuitement des référentiels publics accessibles à tous.

Créons un dépôt distant sur GitHub.

Tout d'abord, vous devez créer un compte GitHub[]. Une fois que vous avez le compte, créez un nouveau référentiel en utilisant le bouton "Nouveau référentiel". Utilisez "project_website" comme nom de référentiel (vous pouvez choisir autre chose si vous le souhaitez).

Vous devriez voir un onglet Code avec des instructions comme celles-ci :

… ou créez un nouveau dépôt en ligne de commande

echo "# project_website" >> LISEZ-MOI.Maryland
git init
git add README.Maryland
git commit -m "premier commit"
git remote ajouter l'origine [email protected]:votrenom d'utilisateur/site_site_projet.git
git push -u maître d'origine

Copiez la commande « git remote add origin » suivante et exécutez-la dans votre répertoire de travail :

$ git remote ajouter l'origine [email protected]:votrenom d'utilisateur/site_site_projet.git

Remarque : Dans votre cas, votre nom d'utilisateur doit être celui que vous avez utilisé pour créer votre compte GitHub.

Dans la commande ci-dessus, vous avez indiqué à Git l'emplacement du référentiel distant. La commande indique à Git que « l'origine » de votre répertoire de travail project_helloworld sera « [email protected] : votre nom d'utilisateur/project_website.idiot".

Maintenant, poussez votre code de votre branche master vers origin (référentiel distant) :

$ git push origin master
Comptage d'objets : 9, terminé.
Compression delta utilisant jusqu'à 4 threads.
Compression d'objets : 100 % (6/6), terminé.
Objets d'écriture : 100 % (9/9), 803 octets | 0 octet/s, terminé.
Total 9 (delta 2), réutilisé 0 (delta 0)
à distance : Résolution des deltas : 100 % (2/2), terminé.
À [email protected]:votrenom d'utilisateur/site_site_projet.git
* [nouvelle branche] maître -> maître

Si vous actualisez votre navigateur dans GitHub, vous devriez voir que l'index.le fichier html est là-haut. Votre code est donc public et les autres développeurs peuvent extraire et modifier le code sur le référentiel distant.

En tant que développeur, vous travaillerez avec le code d'autres personnes. Cela vaut donc la peine d'essayer de récupérer le code de GitHub.

Allons dans un nouveau répertoire où vous n'avez rien. Sur le côté droit du référentiel GitHub, vous remarquerez le bouton « Cloner ou télécharger ». Si vous cliquez dessus, il devrait vous donner une adresse SSH. Exécutez la commande suivante avec l'adresse SSH :

$ git clone [email protected]:votrenom d'utilisateur/site_site_projet.git

La sortie devrait ressembler à ceci :

$ git clone [email protected]:votrenom d'utilisateur/site_site_projet.git
Clonage dans 'project_website'…
remote : Comptage d'objets : 9, terminé.
remote : Compression d'objets : 100 % (4/4), terminé.
distant : Total 9 (delta 2), réutilisé 9 (delta 2), pack-réutilisé 0
Réception d'objets : 100 % (9/9), fait.
Résolution des deltas : 100 % (2/2), terminé.
Vérification de la connectivité… terminé.

Il créera un project_website dans votre dossier propre. Si vous allez à l'intérieur, vous devriez voir l'index.html de votre project_helloworld.

Vous avez donc obtenu les résultats suivants :

Création et modification dans project_helloworld
Téléchargé le code sur GitHub dans project_website
J'ai téléchargé le code depuis GitHub

Prenons un autre fichier du nouveau répertoire de travail project_website :

$ touchez Lisez-moi.Maryland
$ git ajouter .
$ git commit -m "Ajout ReadMe.Maryland"
$ git push origin master

Si vous actualisez la page GitHub project_website, vous devriez voir le ReadMe.fichier md là-bas.

Remarque : lorsque vous téléchargez du code depuis GitHub, le répertoire de travail connaît automatiquement l'origine. Vous n'avez pas besoin de le définir avec la commande "git remote add origin".

Des questions:

Pourquoi avez-vous besoin d'utiliser des référentiels distants?
Comment configurer votre référentiel local actuel pour vous connecter au référentiel distant?
Comment cloner des référentiels distants sur votre ordinateur local?

Conclusion

Vous pouvez trouver plus d'informations sur toutes les commandes dans la documentation Git[]. Même s'il existe des outils d'interface utilisateur Git disponibles, la ligne de commande est le meilleur moyen de maîtriser Git. Cela vous donnera une base plus solide pour votre travail de développement.

Une étude plus approfondie:

https://git-scm.com/docs
https://git-scm.com/book/fr/v2
https://git-scm.com/vidéos