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 d'autres. Mais le partage du code et la collaboration peuvent être compliqués. Il est difficile de suivre divers changements qui se produisent pendant le cycle de vie d'un logiciel. Les équipes de développement s'appuient donc sur les outils de contrôle de version pour aider au 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 principes fondamentaux 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 des modifications que vous apportez à vos fichiers et dossiers. Il est plus facile de sauvegarder 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 retourner votre base de code entière en une ancienne version.

Le développement de Git a commencé en 2005. Le groupe du noyau Linux avait utilisé leur code dans Bitkeeper, un système de contrôle de version distribué propriétaire. Cependant, Bitkeeper a retiré son utilisation libre du produit. Donc 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 une autorité centralisée pour garder une trace du code. Les commandes de version centralisée plus anciennes comme CVS, SVN ou Perforce nécessitent des serveurs centraux pour maintenir l'historique des changements. Git peut garder une trace de tous les changements localement et travailler entre pairs. C'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ée?

Installation de Git

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

$ sudo apt install git-all

Pour Fedora, Rhel ou Centos, vous pouvez utiliser:

$ sudo dnf installer git-all

Vous pouvez vérifier si Git a été installé, en utilisant 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 de globe.Nom "YourUsername"
$ git config - utilisateur de globe.Email "YourUserName @ Exemple.com "

Vous pouvez vérifier si les configurations ont été définies correctement en utilisant la commande suivante:

$ git config - liste
utilisateur.name = yourUsername
utilisateur.Email = YourUserName @ Exemple.com

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

Des questions

• Quelle est la commande d'installation de Git sur votre système Linux?
• Pourquoi devriez-vous configurer l'utilisateur.nom et utilisateur.configuration de l'e-mail? Comment les configurez-vous?

Comprendre Git conceptuellement

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

• Directeur de travail
• Zone de transit
• Dépôt
• Référentiel à distance

Le répertoire de travail, la zone de mise en scène et le référentiel sont locaux de votre machine. Le référentiel distant peut être n'importe quel autre ordinateur ou serveur. Pensons à ces concepts comme quatre boîtes qui peuvent contenir des articles A1 standard.

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

La boîte de mise en scène 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 de répertoire de travail, il n'y aura pas d'enregistrement permanent de ce document mis en scène.

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

Lorsque vous le déplacez dans la boîte du référentiel, deux choses se produisent:

1. Un instantané du document est enregistré en permanence.
2. Une entrée de fichier journal est faite pour aller avec l'instantané.

L'entrée du 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 est uniquement disponible. Vous faites donc une copie de votre document de référentiel local avec le fichier journal et le mettez dans une boîte dans la salle de fourniture de l'entreprise. Maintenant, toute personne dans votre entreprise peut venir faire une copie de votre document et l'emmener à son bureau. La boîte dans la salle d'approvisionnement 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, la mise en scène, le référentiel et le référentiel distant?
• Pouvez-vous exploiter comment les documents passent d'une étape à un autre?

Votre premier référentiel GIT

Une fois que vous avez installé Git, 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 travailliez sur un projet de développement Web. Créons un dossier appelé Project_Helloworld et passons en répertoire:

$ MKDIR PROJECT_HELOWLORLD
$ CD PROJECT_HELOWLORLD

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

$ git init

Vous devriez voir une sortie comme ceci:

Initialisé le référentiel git vide dans / utilisateurs / zakh / _Work / Learngit / git_tutorial /
project_heloworld /.git

Maintenant, 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: statut, journal, ajouter et valider

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

$ statut git
Sur Branch Master
Engagement initial
Rien à commettre (créer / copier des fichiers et utiliser "git ajouter" pour suivre)

La sortie de la commande Git Status dit que vous êtes sur la branche maîtresse. C'est la branche par défaut que Git initialise. (Vous pouvez créer vos propres branches. En savoir plus sur les branches plus tard). De plus, la sortie dit qu'il n'y a rien à commettre.

Essayons la commande de journal:

$ git journal
Fatal: votre branche actuelle «maître» n'a pas encore de validation

Il est donc temps de créer du code. Créons un fichier appelé index.HTML:

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:

$ statut git
Sur Branch Master
Engagement initial
Fichiers non suivis:
(Utilisez "Git Add…" pour inclure dans ce qui sera engagé)
indice.html
Rien n'a ajouté à des fichiers de validation mais non tracés (utilisez "git ajouter" à la piste)

Git vous dit que vous avez un fichier appelé index.HTML dans votre répertoire de travail non suivi.

Assurez-vous d'indexer.html est suivi. Vous devrez utiliser la commande ADD:

$ git ajouter l'index.html

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

$ git add .

Vérifions maintenant le statut:

$ statut git
Sur Branch Master
Engagement initial
Modifications à engager:
(Utilisez "Git RM - Cached…" pour unstager)
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 cache.html

Votre index.HTML reviendra à un statut non suivi. Vous devrez l'ajouter à nouveau pour le ramener à la mise en scène.]]

Vérifions à nouveau le journal:

$ git journal
Fatal: votre branche actuelle «maître» n'a pas encore de validation

Donc même si Git suit l'index.HTML, il n'y a rien dans le référentiel Git sur le fichier. Commençons nos changements:

$ git commit -m "Index de commission.html "
La sortie doit ressembler à ceci:
[Master (Root-Commit) F136D22] Index de mise en place.html
1 fichier modifié, 6 insertions (+)
Créer le mode 100644 Index.html

Le texte à l'intérieur des citations après le «-m» est un commentaire qui ira dans le fichier journal. Vous pouvez utiliser Git Commit sans «-m», mais alors Git ouvrira 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 journal
Commit F136D22040BA81686C9522F4FF94961A68751AF7
Auteur: Zak H
Date: lun 4 juin 16:53:42 2018 -0700
Index de commetting.html

Vous pouvez voir qu'il montre un engagement. Vous avez réussi à avoir commis vos modifications à votre référentiel local. Si vous souhaitez voir le même connexion de manière concise, vous pouvez utiliser la commande suivante:

$ Git Log --Oneline
F136D22 Index de mise en engagement.html

À l'avenir, nous utiliserons cette forme de la commande de journal car il est plus facile de comprendre ce qui se passe.

Commençons à modifier l'index.html. Ouvrez l'index.Fichier HTML dans un éditeur et changer la ligne «Hello World» en «Hello World! C'est moi!»Et enregistrez-le. Si vous vérifiez à nouveau l'état, vous verrez Git a remarqué que vous modifiez le fichier:

$ statut git
Sur Branch Master
Modifications non mises en scène pour engager:
(Utilisez "Git Add…" pour mettre à jour ce qui sera engagé)
(Utilisez "Git Checkout - ..." pour éliminer les modifications dans le répertoire de travail)
Modifié: index.html
Aucune modification ajoutée à Commit (utilisez "git add" et / ou "git commit -a")

Le changement est toujours dans votre répertoire de travail. Vous devez le pousser dans la zone de mise en scène. Utilisez la commande ADD que vous avez utilisée avant:

$ git add .

Vérifiez à nouveau l'état:

$ statut git
Sur Branch Master
Modifications à engager:
(Utilisez "Git Reset Head…" pour unstager)
Modifié: index.html

Maintenant, vos modifications sont dans la zone de mise en scène. Vous pouvez l'engager dans le référentiel pour la garde 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 vérifier le journal pour vos modifications permanentes:

$ Git Log --Oneline
0586662 Index modifié.html à un message plus heureux
F136D22 Index de mise en engagement.html

Dans cette section, vous avez appris à utiliser les commandes de statut, de connexion, d'ajout et de validation pour garder une trace de vos documents dans GIT.

Des questions:

• Que fait le statut Git?
• Que fait Git Log?
• Que fait git ajouter?
• Que fait git commet?

Revenir à des fichiers plus anciens à l'aide de la caisse

Lorsque vous commettez un fichier en git, il crée un hachage unique pour chaque engagement. Vous pouvez les utiliser comme identificateurs pour revenir à une ancienne version.

Supposons que vous souhaitiez revenir à votre version antérieure de l'index.html. Tout d'abord, regardons l'index.HTML dans la condition actuelle:

$ index de chat.html



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 Index modifié.html à un message plus heureux
F136D22 Index de mise en engagement.html

Le hachage de la version précédente était F136D22 («Hello World»). Vous pouvez utiliser la commande de caisse pour accéder à cette version:

$ Git Checkout F136D22
Remarque: Vérification de «F136D22».
Vous êtes dans l'état «tête détachée». Vous pouvez regarder autour de vous, apporter des modifications expérimentales
et les engager, et vous pouvez jeter tous les engins que vous faites dans cet état
sans impact sur aucune succursale en effectuant une autre caisse.
Si vous souhaitez créer une nouvelle branche pour conserver les engagements que vous créez, vous pouvez
Faites-le (maintenant ou plus tard) en utilisant -b avec la commande de paiement à nouveau. Exemple:
Git Checkout -B
La tête est maintenant à F136D22….html

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

$ index de chat.html



Bonjour le monde

Il n'a que "Hello World". Alors votre index.HTML a changé pour l'ancienne version. Si vous vérifiez l'état:

$ statut git
Tête détachée à F136D22
Rien à commettre, répertoire en activité propre

Git vous dit essentiellement que la tête n'est pas au plus récent engagement. Vous pouvez revenir à l'engagement le plus récent en consultant la branche maître à l'aide de la commande suivante:

$ maître de paiement
La position de tête précédente était F136D22….html
Changé de succursale «maître»

Maintenant, si vous vérifiez l'état:

$ statut git
Sur Branch Master
Rien à commettre, répertoire en activité propre

L'avertissement rouge a disparu. Aussi, si vous vérifiez votre index.HTML, vous devriez être de retour à la dernière version:

$ index de chat.html


Bonjour le monde! C'est moi!

La commande de paiement vous amène à divers états. Nous en apprendrons plus sur la caisse dans la section suivante.

Des questions:

• Comment utilisez-vous la commande Git Checkout pour accéder à une ancienne version d'un fichier?
• Comment utilisez-vous la caisse de Git pour revenir à la dernière version du fichier?

Découvrez, ramifiant et fusion

La branche 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, la branche a pris du temps et difficile. Git a rendu la ramification 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 maîtresse.

$ statut git
Sur Branch Master
Rien à commettre, répertoire en activité 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 branche est une excellente solution. Appelons la branche david_website.

Vous pouvez émettre la commande suivante:

$ git branche david_website

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

$ Git Branch - Liste
david_website
* maître

L'étoile (*) à côté du maître signifie que vous êtes toujours dans la branche maîtresse. Vous pouvez consulter la branche David_website avec la commande suivante:

$ git Checkout David_website
Changé de branche 'David_website'

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

$ Git Branch - Liste
* David_website
maître

Alors tu es sur la branche David_website.

Changeons l'index.HTML de «Hello World! C'est moi!«À« Hello World! C'est David!»Et puis mettez en scène et commettez-le:

$ git add .
$ git commit -m "Site Web modifié pour David"

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

$ Git Log --Oneline
345C0F4 Changé de site Web pour David
0586662 Index modifié.html à un message plus heureux
F136D22 Index de mise en engagement.html

Et votre fichier d'index devrait ressembler à ceci:

$ index de chat.html



Bonjour le monde! C'est David!

Voyons maintenant la branche principale:

$ maître de paiement
Changé de succursale «maître»

Si vous vérifiez l'état et le journal:

$ statut git
Sur Branch Master
Rien à commettre, répertoire en activité propre
$ Git Log --Oneline
0586662 Index modifié.html à un message plus heureux
F136D22 Index de mise en engagement.html

Remarquez que vous n'avez pas votre troisième engagement dans le maître. Parce que cet engagement n'est maintenu que dans la succursale David_website.

C'est ce qui s'est passé

Supposons à ce stade que vous décidez, vous ne voulez pas continuer votre site Web. Tu seras juste le développeur de David. Vous voulez donc fusionner les changements dans la branche David_website au maître. Depuis la branche maître, il vous suffit d'émettre les commandes suivantes (la commande d'état est utilisée pour vérifier si vous êtes au bon endroit):

$ statut git
Sur Branch Master
Rien à commettre, répertoire en activité propre
$ git fusiter david_website
Mise à jour du 0586662… 345C0F4
Avance rapide
indice.HTML | 2 +-
1 fichier modifié, 1 insertion (+), 1 suppression (-)

Conseil: Vous tirez des changements de David_website à Master. Vous devez ê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 Changé de site Web pour David
0586662 Index modifié.html à un message plus heureux
F136D22 Index de mise en engagement.html

Vous avez réussi à fusionner la branche David_website dans Master. Et votre index.HTML pour Master Branch semble identique à David_website Branch:

$ index de chat.html



Bonjour le monde! C'est David!

Vous pouvez garder la branche David_website:

$ Git Branch - Liste
david_website
* maître

Ou vous pouvez le supprimer:

$ Git Branch -d David_website
Branche supprimée david_website (était 345c0f4).

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

$ Git Branch - Liste
* maître

Conseil: Pendant 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 ramification?
• Comment branchez-vous et fusionnez-vous les fichiers et dossiers?

Référentiel à distance

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

Le référentiel à distance Git est essentiellement une autre copie de votre référentiel local qui peut être 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 à cet effet. Vous pouvez créer gratuitement des référentiels publics qui peuvent être accessibles par n'importe qui.

Créons un référentiel 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 à l'aide du 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 de code avec des instructions comme celles-ci:

… Ou créer un nouveau référentiel sur la ligne de commande

echo "# project_website" >> readme.Maryland
git init
git ajouter readme.Maryland
git commit -m "premier engagement"
git distote ajouter d'origine git @ github.com: yourUserName / project_website.git
git push -u origine maître

Copiez la commande «Git Remote Add Origin» et exécutez-la dans votre répertoire de travail:

$ git distote ajouter d'origine git @ github.com: yourUserName / project_website.git

Remarque: Dans votre cas, votre nom de serrage devrait être ce que vous avez utilisé pour créer votre compte GitHub.

Dans la commande ci-dessus, vous avez instruit Git l'emplacement du référentiel distant. La commande indique à Git que «l'origine» de votre répertoire de travail Project_Helloworld sera «git @ github.com: yourUserName / project_website.git ».

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

$ git push origin maître
Compter les objets: 9, fait.
Compression delta en utilisant jusqu'à 4 threads.
Comprimer des objets: 100% (6/6), fait.
Écriture d'objets: 100% (9/9), 803 octets | 0 octets / s, fait.
Total 9 (Delta 2), réutilisé 0 (Delta 0)
Remote: Résolution deltas: 100% (2/2), fait.
À git @ github.com: yourUserName / project_website.git
* [New Branch] Master -> Master

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

En tant que développeur, vous travaillerez avec le code des autres. Il vaut donc la peine d'essayer de vérifier le code de GitHub.

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

$ git clone git @ github.com: yourUserName / project_website.git

La sortie doit ressembler à ceci:

$ git clone git @ github.com: yourUserName / project_website.git
Clonage dans 'project_website'…
Remote: comptage des objets: 9, fait.
Remote: compression des objets: 100% (4/4), fait.
Remote: Total 9 (Delta 2), réutilisé 9 (Delta 2), pack-réutilisé 0
Recevoir des objets: 100% (9/9), fait.
Résolution deltas: 100% (2/2), fait.
Vérification de la connectivité… fait.

Il créera un projet_website dans votre dossier propre. Si vous entrez à l'intérieur, vous devriez voir l'index.HTML de votre projet_Helloworld.

Vous avez donc réalisé ce qui suit:

• Créé et apporté des modifications dans project_heloworld
• Téléchargé le code sur github dans project_website
• Téléchargé le code de github

Soyons un autre fichier du nouveau répertoire de travail Project_website:

$ tactile readme.Maryland
$ git add .
$ git commit -m "Ajout de Readme.Maryland"
$ git push origin maître

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 à 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 les référentiels distants de votre ordinateur local?

Conclusion

Vous pouvez trouver plus d'informations sur toutes les commandes dans les documents 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 / en / v2
• https: // git-scm.com / vidéos