Premiers pas avec Git : un guide complet pour les débutants

Au lieu d'une introduction

Bonjour! Aujourd'hui, nous allons parler d'un système de contrôle de version, à savoir Git. Vous n'avez rien à voir avec la programmation si vous ne connaissez/comprenez pas Git. Mais la beauté est que vous n'avez pas besoin de garder toutes les commandes et fonctionnalités de Git dans votre tête pour être continuellement employé. Vous devez connaître un ensemble de commandes qui vous aideront à comprendre tout ce qui se passe.

Les bases de Git

Git est un système de contrôle de version distribué pour notre code. Pourquoi en avons-nous besoin? Les équipes distribuées ont besoin d'une sorte de système pour gérer leur travail. Il est nécessaire pour suivre les changements qui se produisent au fil du temps. Autrement dit, nous devons être en mesure de voir étape par étape quels fichiers ont changé et comment. Ceci est particulièrement important lorsque vous recherchez ce qui a changé dans le contexte d'une seule tâche, ce qui permet d'annuler les modifications.

Installer Git

Installons Java sur votre ordinateur.

Installation sous Windows

Comme d'habitude, vous devez télécharger et exécuter un fichier exe. Tout est simple ici : cliquez sur le premier lien Google , effectuez l'installation, et le tour est joué. Pour ce faire, nous allons utiliser la console bash fournie par Windows. Sous Windows, vous devez exécuter Git Bash. Voici à quoi cela ressemble dans le menu Démarrer : Il s'agit maintenant d'une invite de commande avec laquelle vous pouvez travailler. Pour éviter d'avoir à aller dans le dossier avec le projet à chaque fois pour y ouvrir Git, vous pouvez ouvrir l'invite de commande dans le dossier du projet avec le bouton droit de la souris avec le chemin dont nous avons besoin :

Installation sous Linux

Habituellement, Git fait partie des distributions Linux et est déjà installé, car il s'agit d'un outil initialement écrit pour le développement du noyau Linux. Mais il y a des situations où ce n'est pas le cas. Pour vérifier, vous devez ouvrir un terminal et écrire : git --version. Si vous obtenez une réponse intelligible, rien ne doit être installé. Ouvrez un terminal et installez Git sur Ubuntu . Je travaille sur Ubuntu, donc je peux vous dire ce qu'il faut écrire : sudo apt-get install git.

Installation sur macOS

Ici aussi, vous devez d'abord vérifier si Git est déjà là. Si vous ne l'avez pas, le moyen le plus simple de l'obtenir est de télécharger la dernière version ici . Si Xcode est installé, alors Git sera définitivement installé automatiquement.

Paramètres Git

Git a des paramètres utilisateur pour l'utilisateur qui soumettra le travail. Cela a du sens et est nécessaire, car Git prend ces informations pour le champ Auteur lorsqu'un commit est créé. Configurez un nom d'utilisateur et un mot de passe pour tous vos projets en exécutant les commandes suivantes :

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Si vous avez besoin de changer l'auteur d'un projet spécifique, vous pouvez supprimer "--global". Cela nous donnera ceci :

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Un peu de théorie...

Pour plonger dans le sujet, nous devrions vous présenter quelques nouveaux mots et actions...

• référentiel git
• commettre
• bifurquer
• fusionner
• conflits
• tirer
• pousser
• comment ignorer certains fichiers (.gitignore)

Et ainsi de suite.

Statuts dans Git

Git a plusieurs statues qui doivent être comprises et mémorisées :

• non suivi
• modifié
• mise en scène
• engagé

Comment devriez-vous comprendre cela?

Voici les statuts qui s'appliquent aux fichiers contenant notre code :

1. Un fichier qui est créé mais pas encore ajouté au référentiel a le statut "non suivi".
2. Lorsque nous apportons des modifications à des fichiers qui ont déjà été ajoutés au référentiel Git, leur statut est "modifié".
3. Parmi les fichiers que nous avons modifiés, nous sélectionnons ceux dont nous avons besoin, et ces classes passent au statut "stage".
4. Un commit est créé à partir de fichiers préparés à l'état intermédiaire et est placé dans le référentiel Git. Après cela, il n'y a plus de fichiers avec le statut "stage". Mais il peut encore y avoir des fichiers dont le statut est "modifié".

Voici à quoi ça ressemble :

Qu'est-ce qu'un engagement ?

Un commit est l'événement principal en matière de contrôle de version. Il contient toutes les modifications apportées depuis le début de la validation. Les commits sont liés entre eux comme une liste à liens simples. Plus précisément : il y a un premier commit. Lorsque le deuxième commit est créé, il sait ce qui vient après le premier. Et de cette manière, les informations peuvent être suivies. Un commit possède également ses propres informations, appelées métadonnées :

• l'identifiant unique du commit, qui peut être utilisé pour le trouver
• le nom de l'auteur du commit, qui l'a créé
• la date de création du commit
• un commentaire qui décrit ce qui a été fait pendant le commit

Voici à quoi ça ressemble :

Qu'est-ce qu'une succursale ?

Une branche est un pointeur vers un commit. Parce qu'un commit sait quel commit le précède, lorsqu'une branche pointe vers un commit, tous ces commits précédents s'appliquent également à lui. En conséquence, nous pourrions dire que vous pouvez avoir autant de branches que vous le souhaitez pointant vers le même commit. Le travail se passe dans les branches, donc lorsqu'un nouveau commit est créé, la branche déplace son pointeur vers le commit le plus récent.

Premiers pas avec Git

Vous pouvez travailler avec un référentiel local seul ou avec un référentiel distant. Pour pratiquer les commandes requises, vous pouvez vous limiter au référentiel local. Il stocke uniquement toutes les informations du projet localement dans le dossier .git. Si nous parlons du référentiel distant, alors toutes les informations sont stockées quelque part sur le serveur distant : seule une copie du projet est stockée localement. Les modifications apportées à votre copie locale peuvent être poussées (git push) vers le référentiel distant. Dans notre discussion ici et ci-dessous, nous parlons de travailler avec Git dans la console. Bien sûr, vous pouvez utiliser une sorte de solution basée sur une interface graphique (par exemple, IntelliJ IDEA), mais vous devez d'abord déterminer quelles commandes sont exécutées et ce qu'elles signifient.

Travailler avec Git dans un dépôt local

Ensuite, je vous suggère de suivre et d'effectuer toutes les étapes que j'ai suivies en lisant l'article. Cela améliorera votre compréhension et votre maîtrise de la matière. Eh bien, bon appétit ! :) Pour créer un dépôt local, vous devez écrire :

git init

Cela créera un dossier .git dans le répertoire actuel de la console. Le dossier .git stocke toutes les informations sur le référentiel Git. Ne le supprimez pas ;) Ensuite, les fichiers sont ajoutés au projet et le statut "Untracked" leur est attribué. Pour vérifier l'état actuel de votre travail, écrivez ceci :

git status

Nous sommes dans la branche master, et nous y resterons jusqu'à ce que nous passions à une autre branche. Cela montre quels fichiers ont été modifiés mais n'ont pas encore été ajoutés au statut "mis en scène". Pour les ajouter au statut "staged", vous devez écrire "git add". Nous avons quelques options ici, par exemple :

• git add -A — ajoute tous les fichiers au statut "staged"
• git add . — ajouter tous les fichiers de ce dossier et de tous les sous-dossiers. En gros, c'est le même que le précédent
• git add <file name> — ajoute un fichier spécifique. Ici, vous pouvez utiliser des expressions régulières pour ajouter des fichiers selon un modèle. Par exemple, git add *.java : Cela signifie que vous souhaitez uniquement ajouter des fichiers avec l'extension java.

Les deux premières options sont clairement simples. Les choses deviennent plus intéressantes avec le dernier ajout, alors écrivons :

git add *.txt

Pour vérifier l'état, nous utilisons la commande déjà connue de nous :

git status

Ici, vous pouvez voir que l'expression régulière a fonctionné correctement : test_resource.txt a maintenant le statut "staged". Et enfin, la dernière étape pour travailler avec un référentiel local (il y en a une de plus lorsque vous travaillez avec le référentiel distant ;)) — création d'un nouveau commit :

git commit -m "all txt files were added to the project"

La prochaine étape est une excellente commande pour consulter l'historique des commits sur une branche. Profitons-en :

git log

Ici, vous pouvez voir que nous avons créé notre premier commit et qu'il inclut le texte que nous avons fourni sur la ligne de commande. Il est très important de comprendre que ce texte doit expliquer le plus précisément possible ce qui a été fait lors de ce commit. Cela nous aidera plusieurs fois à l'avenir. Un lecteur curieux qui ne s'est pas encore endormi peut se demander ce qui est arrivé au fichier GitTest.java. Découvrons dès maintenant. Pour ce faire, nous utilisons :

git status

Comme vous pouvez le voir, il est toujours "non suivi" et attend dans les coulisses. Mais que se passe-t-il si nous ne voulons pas du tout l'ajouter au projet ? Cela arrive parfois. Pour rendre les choses plus intéressantes, essayons maintenant de modifier notre fichier test_resource.txt. Ajoutons du texte ici et vérifions l'état :

git status

Ici, vous pouvez clairement voir la différence entre les statuts "non suivi" et "modifié". GitTest.java est "non suivi", tandis que test_resource.txt est "modifié". Maintenant que nous avons des fichiers à l'état modifié, nous pouvons examiner les modifications qui leur ont été apportées. Cela peut être fait en utilisant la commande suivante :

git diff

C'est-à-dire que vous pouvez clairement voir ici ce que j'ai ajouté à notre fichier texte : hello world ! Ajoutons nos modifications au fichier texte et créons un commit :

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

Pour voir tous les commits, écrivez :

git log

Comme vous pouvez le voir, nous avons maintenant deux commits. Nous ajouterons GitTest.java de la même manière. Pas de commentaires ici, juste des commandes :

git add GitTest.java
git commit -m "added GitTest.java"
git status

Travailler avec .gitignore

De toute évidence, nous ne voulons conserver que le code source, et rien d'autre, dans le référentiel. Alors que pourrait-il y avoir d'autre ? Au minimum, des classes compilées et/ou des fichiers générés par des environnements de développement. Pour dire à Git de les ignorer, nous devons créer un fichier spécial. Faites ceci : créez un fichier appelé .gitignore à la racine du projet. Chaque ligne de ce fichier représente un motif à ignorer. Dans cet exemple, le fichier .gitignore ressemblera à ceci :

```
*.class
target/
*.iml
.idea/
```

Nous allons jeter un coup d'oeil:

• La première ligne consiste à ignorer tous les fichiers avec l'extension .class
• La deuxième ligne consiste à ignorer le dossier "target" et tout ce qu'il contient
• La troisième ligne consiste à ignorer tous les fichiers avec l'extension .iml
• La quatrième ligne consiste à ignorer le dossier .idea

Essayons d'utiliser un exemple. Pour voir comment cela fonctionne, ajoutons la classe GitTest.class compilée au projet et vérifions l'état du projet :

git status

De toute évidence, nous ne voulons pas ajouter accidentellement la classe compilée au projet (en utilisant git add -A). Pour ce faire, créez un fichier .gitignore et ajoutez tout ce qui a été décrit précédemment : Utilisons maintenant un commit pour ajouter le fichier .gitignore au projet :

git add .gitignore
git commit -m "added .gitignore file"

Et maintenant le moment de vérité : nous avons une classe compilée GitTest.class qui est "untracked", que nous ne voulions pas ajouter au dépôt Git. Nous devrions maintenant voir les effets du fichier .gitignore :

git status

Parfait! .gitignore +1 :)

Travailler avec des succursales et autres

Naturellement, travailler dans une seule branche n'est pas pratique pour les développeurs solitaires, et c'est impossible lorsqu'il y a plus d'une personne dans une équipe. C'est pourquoi nous avons des succursales. Comme je l'ai dit plus tôt, une branche n'est qu'un pointeur mobile vers des commits. Dans cette partie, nous explorerons le travail dans différentes branches : comment fusionner les modifications d'une branche à une autre, quels conflits peuvent survenir, et bien plus encore. Pour voir une liste de toutes les branches du référentiel et comprendre dans laquelle vous vous trouvez, vous devez écrire :

git branch -a

Vous pouvez voir que nous n'avons qu'une seule branche master. L'astérisque devant indique que nous y sommes. Au fait, vous pouvez également utiliser la commande "git status" pour savoir dans quelle branche nous nous trouvons. Ensuite, il existe plusieurs options pour créer des branches (il peut y en avoir plus — ce sont celles que j'utilise) :

• créer une nouvelle succursale basée sur celle dans laquelle nous nous trouvons (99% des cas)
• créer une branche basée sur un commit spécifique (1% des cas)

Créons une branche basée sur un commit spécifique

Nous nous baserons sur l'identifiant unique du commit. Pour le trouver, on écrit :

git log

J'ai mis en évidence le commit avec le commentaire "ajouté hello world..." Son identifiant unique est 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Je veux créer une branche "développement" qui commence à partir de ce commit. Pour ce faire, j'écris :

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Une branche est créée avec uniquement les deux premiers commits de la branche master. Pour vérifier cela, nous nous assurons d'abord de basculer vers une branche différente et de regarder le nombre de commits là-bas :

git status
git log

Et comme prévu, nous avons deux commits. Au fait, voici un point intéressant : il n'y a pas encore de fichier .gitignore dans cette branche, donc notre fichier compilé (GitTest.class) est maintenant mis en surbrillance avec le statut "non suivi". Nous pouvons maintenant revoir nos branches en écrivant ceci :

git branch -a

Vous pouvez voir qu'il y a deux branches : "master" et "development". Nous sommes actuellement en développement.

Créons une branche basée sur la branche actuelle

La deuxième façon de créer une branche est de la créer à partir d'une autre. Je souhaite créer une branche basée sur la branche master. Tout d'abord, je dois y passer, et l'étape suivante consiste à en créer un nouveau. Nous allons jeter un coup d'oeil:

• git checkout master — passer à la branche master
• git status — vérifie que nous sommes bien dans la branche master

Ici, vous pouvez voir que nous sommes passés à la branche master, le fichier .gitignore est en vigueur et la classe compilée n'est plus mise en surbrillance comme "non suivie". Nous créons maintenant une nouvelle branche basée sur la branche master :

git checkout -b feature/update-txt-files

Si vous ne savez pas si cette branche est la même que "master", vous pouvez facilement vérifier en exécutant "git log" et en regardant tous les commits. Il devrait y en avoir quatre.

Résolution de conflit

Avant d'explorer ce qu'est un conflit, nous devons parler de la fusion d'une branche dans une autre. Cette image illustre le processus de fusion d'une branche dans une autre : Ici, nous avons une branche principale. À un moment donné, une branche secondaire est créée à partir de la branche principale, puis modifiée. Une fois le travail terminé, nous devons fusionner une branche dans l'autre. Je ne décrirai pas les différentes fonctionnalités : dans cet article, je veux seulement transmettre une compréhension générale. Si vous avez besoin des détails, vous pouvez les rechercher vous-même. Dans notre exemple, nous avons créé la branche feature/update-txt-files. Comme indiqué par le nom de la succursale, nous mettons à jour le texte. Nous devons maintenant créer un nouveau commit pour ce travail :

git add *.txt 
git commit -m "updated txt files"
git log

Maintenant, si nous voulons fusionner la branche feature/update-txt-files dans master, nous devons aller dans master et écrire "git merge feature/update-txt-files":

git checkout master
git merge feature/update-txt-files
git log

Par conséquent, la branche master inclut désormais également le commit qui a été ajouté à feature/update-txt-files. Cette fonctionnalité a été ajoutée, vous pouvez donc supprimer une branche de fonctionnalité. Pour ce faire, nous écrivons :

git branch -D feature/update-txt-files

Tout est clair jusqu'à présent, n'est-ce pas ? Compliquons la situation : disons maintenant que vous devez à nouveau modifier le fichier txt. Mais maintenant, ce fichier sera également modifié dans la branche master. En d'autres termes, il changera en parallèle. Git ne pourra pas savoir quoi faire lorsque nous voulons fusionner notre nouveau code dans la branche master. Allons-y! Nous allons créer une nouvelle branche basée sur master, apporter des modifications à text_resource.txt et créer un commit pour ce travail :

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Allez dans la branche master et mettez également à jour ce fichier texte sur la même ligne que dans la branche feature :

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

Et maintenant, le point le plus intéressant : nous devons fusionner les modifications de la branche feature/add-header vers master. Nous sommes dans la branche master, il suffit donc d'écrire :

git merge feature/add-header

Mais le résultat sera un conflit dans le fichier test_resource.txt : Ici on voit que Git n'a pas pu décider tout seul comment fusionner ce code. Cela nous indique que nous devons d'abord résoudre le conflit, puis effectuer la validation. D'ACCORD. Nous ouvrons le fichier avec le conflit dans un éditeur de texte et voyons : Pour comprendre ce que Git a fait ici, nous devons nous souvenir des modifications que nous avons apportées et où, puis comparer :

1. Les modifications qui se trouvaient sur cette ligne dans la branche master se trouvent entre "<<<<<<< HEAD" et "=======".
2. Les modifications qui se trouvaient dans la branche feature/add-header se trouvent entre "=======" et ">>>>>>> feature/add-header".

C'est ainsi que Git nous dit qu'il n'a pas pu comprendre comment effectuer la fusion à cet endroit du fichier. Il a divisé cette section en deux parties à partir des différentes branches et nous invite à résoudre nous-mêmes le conflit de fusion. Assez juste. Je décide hardiment de tout supprimer, ne laissant que le mot "en-tête": Regardons l'état des modifications. La description sera légèrement différente. Plutôt qu'un statut "modifié", nous avons "non fusionné". Alors aurions-nous pu mentionner un cinquième statut ? Je ne pense pas que ce soit nécessaire. Voyons:

git status

Nous pouvons nous convaincre qu'il s'agit d'un cas particulier et inhabituel. Nous allons continuer:

git add *.txt

Vous remarquerez peut-être que la description suggère d'écrire uniquement "git commit". Essayons d'écrire ça :

git commit

Et juste comme ça, nous l'avons fait - nous avons résolu le conflit dans la console. Bien sûr, cela peut être fait un peu plus facilement dans les environnements de développement intégrés. Par exemple, dans IntelliJ IDEA, tout est si bien configuré que vous pouvez effectuer toutes les actions nécessaires directement à l'intérieur. Mais les IDE font beaucoup de choses "sous le capot", et nous ne comprenons souvent pas exactement ce qui s'y passe. Et quand il n'y a pas de compréhension, des problèmes peuvent survenir.

Travailler avec des référentiels distants

La dernière étape consiste à déterminer quelques commandes supplémentaires nécessaires pour travailler avec le référentiel distant. Comme je l'ai dit, un référentiel distant est un endroit où le référentiel est stocké et à partir duquel vous pouvez le cloner. Quels types de référentiels distants existe-t-il ? Exemples:

• GitHub est la plus grande plate-forme de stockage pour les référentiels et le développement collaboratif. Je l'ai déjà décrit dans des articles précédents.
  Suivez-moi sur GitHub . J'y expose souvent mon travail dans les domaines que j'étudie pour le travail.

• GitLab est un outil Web pour le cycle de vie DevOps avec open source . Il s'agit d'un système basé sur Git pour gérer les référentiels de code avec son propre wiki, son système de suivi des bogues , son pipeline CI/CD et d'autres fonctions.
  Après l'annonce de l'achat de GitHub par Microsoft, certains développeurs ont dupliqué leurs projets dans GitLab.

• BitBucket est un service web d'hébergement de projets et de développement collaboratif basé sur les systèmes de contrôle de version Mercurial et Git. À une certaine époque, il avait un gros avantage sur GitHub en ce sens qu'il offrait des référentiels privés gratuits. L'année dernière, GitHub a également présenté cette fonctionnalité à tout le monde gratuitement.

• Et ainsi de suite…

Lorsque vous travaillez avec un référentiel distant, la première chose à faire est de cloner le projet dans votre référentiel local. Pour cela, j'ai exporté le projet que nous avons fait localement, et maintenant chacun peut le cloner pour lui-même en écrivant :

git clone https://github.com/romankh3/git-demo

Il existe maintenant une copie locale complète du projet. Pour être sûr que la copie locale du projet est la plus récente, vous devez extraire le projet en écrivant :

git pull

Dans notre cas, rien n'a changé dans le référentiel distant pour le moment, la réponse est donc : déjà à jour. Mais si j'apporte des modifications au référentiel distant, le référentiel local est mis à jour après leur extraction. Et enfin, la dernière commande consiste à pousser les données vers le référentiel distant. Lorsque nous avons fait quelque chose localement et que nous voulons l'envoyer au référentiel distant, nous devons d'abord créer un nouveau commit localement. Pour illustrer cela, ajoutons quelque chose d'autre à notre fichier texte : Maintenant, quelque chose d'assez courant pour nous — nous créons un commit pour ce travail :

git add test_resource.txt
git commit -m "prepared txt for pushing"

La commande pour pousser ceci vers le référentiel distant est :

git push

Eh bien, c'est tout ce que je voulais dire. Merci de votre attention. Suivez-moi sur GitHub , où je publie divers exemples de projets intéressants liés à mes études et à mon travail personnels.

Lien utile

• Documentation officielle de Git . Je le recommande comme référence.