Démarrer avec Git : un guide détaillé pour les débutants

Au lieu d'une introduction

Bonjour futur ingénieur logiciel senior. Aujourd'hui, nous allons parler du système de contrôle de version, à savoir Git (lu comme GIT, et non JIT, comme cela peut paraître d'après la grammaire anglaise). Oui, oui, je sais qu'il y a aussi Mercurial, SVN... Mais soyons honnêtes : leur temps est déjà révolu, et je ne vais pas vous faire perdre votre temps précieux avec eux. Pour que vous compreniez l’importance de connaître Git à notre époque, je dirai ceci : sans connaissance/compréhension de cela, vous n’avez rien à faire en programmation. Mais la beauté est que pour travailler constamment, vous n’avez pas besoin de garder toutes les commandes et possibilités en tête. 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 de gestion du travail. Nécessaire pour suivre les changements qui se produisent au fil du temps. Autrement dit, étape par étape, nous voyons quels fichiers ont été modifiés et comment. Ceci est particulièrement important lorsque l’on analyse ce qui a été fait au sein d’une tâche : cela permet de revenir en arrière. Imaginons une situation : il y avait un code fonctionnel, tout y était bon, mais nous avons décidé d'améliorer quelque chose, de le peaufiner ici, de le peaufiner là-bas. Tout allait bien, mais cette amélioration a cassé la moitié des fonctionnalités et rendu impossible le travail. Alors, quelle est la prochaine étape ? Sans la Gita, il faudrait rester assis pendant des heures et se rappeler comment tout se passait à l'origine. Et donc nous revenons simplement au commit et c'est tout. Ou que se passe-t-il si deux développeurs modifient leur code en même temps ? Sans Git, cela ressemble à ceci : ils ont copié le code de l’original et ont fait ce qu’ils devaient faire. Le moment arrive et tous deux veulent ajouter leurs modifications au dossier principal. Et que faire dans cette situation ?.. Je n’ose même pas estimer le temps nécessaire pour faire ce travail. Il n’y aura aucun problème de ce type si vous utilisez Git.

Installer Git

Installons Git sur votre ordinateur. Je comprends que tout le monde a un système d'exploitation différent, je vais donc essayer de décrire plusieurs cas.

Installation pour Windows

Comme d'habitude, vous devez télécharger le fichier exe et l'exécuter. Tout est simple ici : cliquez sur le premier lien Google , installez et c'est tout. Pour le travail, nous utiliserons la console bash qu'ils fournissent. Pour travailler sous Windows, vous devez exécuter Git Bash. Voici à quoi cela ressemble dans le menu Démarrer : Et c'est déjà une console dans laquelle vous pouvez travailler. Afin de ne pas accéder à chaque fois au dossier contenant le projet pour y ouvrir git, vous pouvez cliquer avec le bouton droit dans le dossier pour ouvrir la console avec le chemin dont nous avons besoin :

Installation pour Linux

Généralement, git est déjà installé et inclus dans les distributions Linux, puisqu'il s'agit d'un outil écrit à l'origine pour développer le noyau Linux. Mais il y a des situations où ce n’est pas le cas. Pour vérifier cela, vous devez ouvrir un terminal et taper : git --version. S’il y a une réponse claire, il n’est pas nécessaire d’installer quoi que ce soit. Ouvrez un terminal et installez. Je travaille sur Ubuntu, donc je peux vous dire quoi écrire dessus : sudo apt-get install git. Et c’est tout : vous pouvez désormais utiliser Git dans n’importe quel terminal.

Installation sur macOS

Ici aussi, vous devez d'abord vérifier si Git existe déjà (voir ci-dessus, comme sous Linux). Sinon, le plus simple est de télécharger la dernière version. Si XCode est installé, alors Git sera définitivement installé automatiquement.

Configuration de Git

Le git dispose d'un paramètre utilisateur à partir duquel le travail sera effectué. C'est une chose raisonnable et nécessaire, car lorsqu'un commit est créé, Git prend exactement ces informations pour le champ Auteur. Pour configurer un nom d'utilisateur et un mot de passe pour tous les projets, vous devez saisir les commandes suivantes :

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

S'il est nécessaire de changer l'auteur pour un projet spécifique (pour un projet personnel par exemple), vous pouvez supprimer --global, et cela fonctionnera :

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

Un peu de théorie...

Pour rester dans le sujet, il est conseillé d'ajouter quelques nouveaux mots et actions à votre message... Sinon il n'y aura plus rien à dire. Bien sûr, il s’agit d’un jargon et d’une copie de l’anglais, je vais donc ajouter des significations en anglais. Quels mots et quels actes ?

• dépôt git ;
• commettre (commettre);
• bifurquer;
• fusionner;
• conflits;
• tirer;
• pousser;
• comment ignorer certains fichiers (.gitignore).

Et ainsi de suite.

États dans Git

La Gita comporte plusieurs états qui doivent être compris et mémorisés :

• non suivi ;
• modifié;
• préparé (mis en scène);
• engagé.

Qu'est-ce que ça veut dire?

Ce sont les états dans lesquels se trouvent les fichiers de notre code. Autrement dit, leur chemin de vie ressemble généralement à ceci :

1. Un fichier créé et non ajouté au référentiel sera dans un état non suivi.
2. Nous apportons des modifications aux fichiers qui ont déjà été ajoutés au référentiel Git - ils sont à l'état modifié.
3. À partir des fichiers que nous avons modifiés, nous sélectionnons uniquement ceux (ou tous) dont nous avons besoin (par exemple, nous n'avons pas besoin de classes compilées), et ces classes avec des modifications tombent dans un état intermédiaire.
4. Un commit est créé à partir des fichiers préparés à partir de l'état intermédiaire et est transféré dans le référentiel Git. Après cela, l’état intermédiaire est vide. Mais modifié peut encore contenir quelque chose.

Cela ressemble à ceci (photo du document officiel, pour que vous puissiez vous y fier) :

Qu'est-ce qu'un commit

Un commit est l’objet principal du contrôle de version. Il contient toutes les modifications depuis cette validation. Les commits sont liés les uns aux autres comme une liste à lien unique. A savoir : Il y a le premier commit. Lorsqu'un deuxième commit est créé, il (le second) sait qu'il vient après le premier. Et de cette façon, vous pouvez suivre les informations. Le commit possède également ses propres informations, appelées métadonnées :

• un identifiant de commit unique grâce auquel vous pouvez le trouver ;
• le nom de l'auteur du commit qui l'a créé ;
• date de création du commit ;
• un commentaire qui décrit ce qui a été fait lors de ce commit.

Voici à quoi cela ressemble :

Qu'est-ce qu'une branche

Une branche est un pointeur vers un commit. Puisqu'un commit sait quel commit l'a précédé, lorsqu'une branche pointe vers un commit, toutes les précédentes y font également référence. Sur cette base, on peut dire qu’il peut y avoir autant de branches pointant vers le même commit. Le travail s'effectue sur les branches, donc lorsqu'un nouveau commit est créé, la branche déplace son pointeur vers le commit le plus récent.

Démarrer avec Git

Vous pouvez travailler uniquement avec un référentiel local ou avec un référentiel distant. Pour élaborer les commandes nécessaires, vous ne pouvez utiliser que le référentiel local. Il stocke toutes les informations uniquement localement dans le projet dans le dossier .git. Si nous parlons de distant, alors toutes les informations sont stockées quelque part sur un serveur distant : seule une copie du projet est stockée localement, dont les modifications peuvent être poussées (git push) vers le référentiel distant. Ici et plus loin, nous discuterons de l'utilisation de git dans la console. Bien sûr, vous pouvez utiliser certaines solutions graphiques (par exemple, dans Intellij IDEA), mais vous devez d'abord comprendre 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 toutes les étapes que j'ai suivies pendant que vous lisiez l'article. Cela améliorera votre compréhension et votre rétention du matériel. Alors bon appétit :) Pour créer un dépôt local, vous devez écrire :

git init

Cela créera un dossier .git à l'emplacement où se trouve la console. .git est un dossier qui stocke toutes les informations sur le référentiel Git. Il n'est pas nécessaire de le supprimer ;) Ensuite, les fichiers sont ajoutés à ce projet et leur statut devient Non suivi. Pour voir quel est votre statut de travail actuel, écrivez :

git status

Nous sommes dans la branche principale, et jusqu'à ce que nous passions à une autre, tout restera ainsi. De cette façon, vous pouvez voir quels fichiers ont été modifiés mais pas encore ajoutés à l'état intermédiaire. Pour les ajouter à l'état intermédiaire, vous devez écrire git add. Il peut y avoir plusieurs options ici, par exemple :

• git add -A - ajoute tous les fichiers de l'état intermédiaire ;
• git ajouter . — ajoutez tous les fichiers de ce dossier et tous les fichiers internes. Essentiellement le même que le précédent ;
• git add <filename> - ajoute uniquement un fichier spécifique. Ici, vous pouvez utiliser des expressions régulières pour ajouter selon un certain modèle. Par exemple, git add *.java : cela signifie qu'il vous suffit d'ajouter des fichiers avec l'extension java.

Il est clair que les deux premières options sont simples, mais avec l'ajout ce sera plus intéressant, alors on écrit :

git add *.txt

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

git status

À partir de là, nous pouvons voir que l'expression régulière a fonctionné correctement et que test_resource.txt est désormais dans un état intermédiaire. Et enfin, la dernière étape (avec un dépôt local, avec un dépôt distant il y en aura un de plus ;)) - valider et créer un nouveau commit :

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

Ensuite, il existe une excellente commande pour consulter l’historique des validations d’une branche. Utilisons-le :

git log

Ici, vous pouvez déjà voir que notre premier commit est apparu avec le texte que nous avons transféré. Il est très important de comprendre que le texte que nous transmettons doit définir le plus précisément possible ce qui a été fait lors de ce commit. Cela aidera plusieurs fois dans le futur. Un lecteur curieux qui ne s'est pas encore endormi pourra demander : qu'est-il arrivé au fichier GitTest.java ? Maintenant, nous allons le découvrir, utilisez pour cela :

git status

Comme nous pouvons le voir, il reste dans un état non suivi et attend dans les coulisses. Ou peut-être que nous ne voulons pas du tout l’ajouter au projet ? Des fois ça arrive. Ensuite, pour le rendre plus intéressant, essayons de modifier notre fichier texte test_resource.txt. Ajoutons-y du texte et vérifions le statut :

git status

Ici, vous pouvez clairement voir la différence entre les deux états – non suivi et modifié. GitTest.java est dans un état non suivi et test_resource.txt est dans un état modifié. Maintenant qu’il existe déjà des fichiers à l’état modifié, nous pouvons examiner les modifications qui leur ont été apportées. Cela peut être fait en utilisant la commande :

git diff

Autrement dit, vous pouvez clairement voir ici que j'ai ajouté Hello World ! à notre fichier texte. Ajoutez les modifications au fichier texte et validez :

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

Pour consulter tous les commits, écrivez :

git log

Comme vous pouvez le voir, il y a déjà deux commits. De la même manière, nous ajoutons GitTest.java. Maintenant, pas de commentaires, juste des commandes :

git add GitTest.java
git commit -m “added GitTest.java”
git status

Travailler avec .gitignore

Il est clair que nous souhaitons uniquement stocker le code source et rien d'autre dans le référentiel. Quoi d'autre cela pourrait-il être? Au minimum, des classes et/ou des fichiers compilés qui créent des environnements de développement. Pour que Git les ignore, un fichier spécial doit être créé. Nous faisons ceci : nous créons un fichier à la racine du projet appelé .gitignore, et dans ce fichier chaque ligne sera un modèle à ignorer. Dans cet exemple, git ignore ressemblerait à ceci :

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

Regardons maintenant :

• la première ligne consiste à ignorer tous les fichiers avec l'extension .class ;
• la deuxième ligne consiste à ignorer le dossier cible 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 avec un exemple. Pour voir comment cela fonctionne, ajoutez la classe GitTest.class compilée au projet et consultez l'état du projet :

git status

De toute évidence, nous ne voulons pas accidentellement (si nous utilisons git add -A) ajouter une classe compilée au projet. Pour ce faire, créez un fichier .gitignore et ajoutez tout ce qui a été décrit précédemment : Ajoutons maintenant git ignore au projet avec un nouveau commit :

git add .gitignore
git commit -m “added .gitignore file”

Et maintenant le moment de vérité : nous avons une classe GitTest.class compilée dans un état non suivi, que nous ne voulions pas ajouter au référentiel Git. C'est ici que git ignore devrait fonctionner :

git status

Tout est clair) Git ignorer +1)

Travailler avec des succursales et autres

Bien entendu, travailler dans une seule branche est peu pratique pour un seul et impossible lorsqu'il y a plus d'une personne dans l'équipe. Il existe une succursale pour cela. Comme je l'ai déjà dit, une branche est simplement un pointeur mobile vers des commits. Dans cette partie, nous verrons comment travailler 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 sur laquelle vous vous trouvez, vous devez écrire :

git branch -a

Vous pouvez voir que nous n’avons qu’une seule branche principale, et l’astérisque devant elle indique que nous y sommes. D’ailleurs, pour savoir sur quelle branche nous sommes, on peut aussi utiliser la vérification du statut (git status). Ensuite, il existe plusieurs options pour créer des branches (il y en a peut-être plus, j'utilise celles-ci) :

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

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

Nous nous appuierons sur l’identifiant unique du commit. Pour le trouver, nous écrivons :

git log

J'ai souligné le commit avec le commentaire "ajouté hello world...". Il a un identifiant unique - « 6c44e53d06228f888f2f454d3cb8c1c976dd73f8 ». Je souhaite créer une branche de développement à partir de ce commit. Pour cela j'écrirai :

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Une branche est créée qui contient uniquement les deux premiers commits de la branche principale. Pour tester cela, nous allons d'abord nous assurer que nous avons migré vers une autre branche et examiner le nombre de commits dessus :

git status
git log

Et c’est vrai : il s’est avéré que nous avions deux commits. Au fait, un point intéressant : il n'y a pas encore de fichier .gitignore dans cette branche, donc notre fichier compilé (GitTest.class) est désormais mis en évidence dans l'état non suivi. Nous pouvons maintenant réviser à nouveau nos branches en écrivant :

git branch -a

On peut voir qu'il y a deux branches - master et development - et nous passons maintenant au développement.

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

La deuxième façon de créer une branche est de s’appuyer sur une autre. Je souhaite créer une branche basée sur la branche principale, je dois donc d'abord y basculer, et l'étape suivante consiste à en créer une nouvelle. Regardons:

• git checkout master - passer à la branche master ;
• git status - vérifiez s'il est sur le maître.

Ici, vous pouvez voir que nous sommes passés à la branche master, que git ignore fonctionne déjà ici et que la classe compilée n'apparaît plus comme non suivie. Maintenant, nous créons une nouvelle branche basée sur la branche master :

git checkout -b feature/update-txt-files

Si vous avez des doutes sur le fait que cette branche ne sera pas la même que master, vous pouvez facilement le vérifier en écrivant git log et en examinant tous les commits. Il devrait y en avoir quatre.

Résoudre des conflits

Avant de comprendre ce qu'est un conflit, nous devons parler de fusion (fusion) d'une branche dans une autre. Cette image peut montrer le processus lorsqu'une branche est fusionnée dans une autre : c'est-à-dire qu'il existe une branche principale. À un moment donné, un secondaire en est créé, dans lequel des changements se produisent. Une fois le travail terminé, vous devez fusionner une branche dans une autre. Je ne décrirai pas diverses fonctionnalités : je souhaite transmettre uniquement une compréhension dans le cadre de cet article, et vous découvrirez vous-même les détails si nécessaire. Ainsi, dans notre exemple, nous avons créé la branche feature/update-txt-files. Comme c'est écrit dans le nom de la branche, nous mettrons à jour le texte. Vous devez maintenant créer un nouveau commit à ce sujet :

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

En conséquence, la branche master dispose désormais également d'un commit qui a été ajouté aux fichiers feature/update-txt. Cette fonctionnalité est ajoutée afin que vous puissiez supprimer la branche de fonctionnalité. Pour ce faire, nous écrivons :

git branch -D feature/update-txt-files

Pour l’instant c’est clair, non ? Compliquons la situation : disons maintenant que nous devons à nouveau modifier le fichier txt. Mais désormais, ce fichier sera également modifié dans l'assistant. Autrement dit, cela changera en parallèle et Git ne sera pas en mesure de comprendre ce qui doit être fait dans une situation où nous souhaitons fusionner un nouveau code dans la branche master. Aller! Nous créons une nouvelle branche basée sur master, apportons des modifications à text_resource.txt et créons un commit à ce sujet :

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

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

git checkout master
… обновor test_resource.txt

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

Et maintenant le moment le plus intéressant : vous devez fusionner les modifications de la branche feature/add-header vers master. Nous sommes sur la branche master, il suffit donc d'écrire :

git merge feature/add-header

Mais nous obtiendrons un résultat avec un conflit dans le fichier test_resource.txt : Et ici, nous pouvons voir que Git n'a pas pu décider indépendamment comment fusionner ce code et dit que nous devons d'abord résoudre le conflit, puis seulement effectuer un commit. Ok, ouvrons le fichier contenant le conflit dans un éditeur de texte et voyons : Pour comprendre ce que git a fait ici, vous devez vous rappeler ce que nous avons écrit où et comparer :

1. entre « <<<<<<< HEAD » et « ======= » se trouvent les modifications principales qui se trouvaient dans cette ligne dans la branche principale.
2. entre « ======= » et « >>>>>>> feature/add-header », il y a des changements qui se trouvaient dans la branche feature/add-header.

Ainsi, Git montre qu'à ce stade, il ne savait pas comment fusionner ce fichier, a divisé cette section en deux parties provenant de branches différentes et nous a suggéré de décider par nous-mêmes. Bon, avec une forte volonté je décide de tout supprimer, de ne laisser que le mot en-tête : Regardons l'état des modifications, la description sera légèrement différente. Il n'y aura pas d'état modifié, mais non fusionné. Nous pourrions donc ajouter en toute sécurité un cinquième état... Mais je pense que cela n'est pas nécessaire, voyons voir :

git status

Nous étions convaincus qu’il s’agissait d’un cas différent et inhabituel. Nous allons continuer:

git add *.txt

Dans la description, vous remarquerez qu'ils suggèrent uniquement d'écrire git commit. Nous écoutons et écrivons :

git commit

Et c'est tout : c'est comme ça que nous avons fait - nous avons résolu le conflit dans la console. Bien sûr, dans les environnements de développement, vous pouvez le faire un peu plus facilement, par exemple, dans Intellij IDEA, tout est si bien configuré que vous pouvez y effectuer toutes les actions nécessaires. Mais l’environnement de développement fait beaucoup de choses en coulisses, et souvent nous ne comprenons pas ce qui s’y est exactement passé. Et lorsqu’il n’y a pas de compréhension, des problèmes peuvent surgir.

Travailler avec des référentiels distants

La dernière étape consiste à comprendre quelques commandes supplémentaires nécessaires pour travailler avec un référentiel distant. Comme je l'ai déjà 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 ? Il existe des tonnes d'exemples :

• GitHub est le plus grand référentiel de référentiels et de développement collaboratif. Je l'ai déjà décrit dans des articles précédents.
  Abonnez-vous à mon compte Github . J'y expose souvent mon travail dans les domaines que j'étudie au cours de mon travail.

• GitLab est un outil de cycle de vie DevOps open source basé sur le Web qui fournit un système de gestion de référentiel de code pour Git avec son propre wiki, un système de suivi des problèmes , un pipeline CI/CD et d'autres fonctionnalités.
  Après l'annonce du rachat de GitHub par Microsoft, certains développeurs ont dupliqué leur travail 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 dans la mesure où il disposait de référentiels privés gratuits. L’année dernière, GitHub a également rendu cette fonctionnalité accessible à tous gratuitement.

• Et ainsi de suite…

La première chose que vous devez faire lorsque vous travaillez avec un référentiel distant est de cloner le projet dans votre projet local. Dans ce cas, j'ai exporté le projet que nous avons réalisé localement, et maintenant chacun peut le cloner lui-même en écrivant :

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

Il existe désormais une copie complète du projet localement. Pour être sûr que la dernière copie du projet se trouve localement, vous devez, comme on dit, vider les données en écrivant :

git pull

Dans notre cas, rien n’a changé à distance maintenant, la réponse est donc : déjà à jour. Mais si j'apporte des modifications au référentiel distant, le référentiel local sera mis à jour une fois que nous les aurons extraites. Et enfin, la dernière commande consiste à transmettre les données vers le référentiel distant. Lorsque nous avons fait quelque chose localement et que nous voulons le transférer vers un référentiel distant, nous devons d'abord créer un nouveau commit localement. Pour ce faire, ajoutons autre chose à notre fichier texte : Maintenant, c'est une chose courante pour nous - nous créons un commit à ce sujet :

git add test_resource.txt
git commit -m “prepated txt for pushing”

Et maintenant la commande pour transférer ceci vers le référentiel distant :

git push

C'est tout ce que je voulais te dire. Merci pour votre attention. Abonnez-vous à mon compte GitHub , où je publie différents exemples de projets intéressants issus de ce que j'étudie et utilise au travail.

Liens utiles

• Le document officiel sur Git est en russe . Je le recommande comme guide de référence.
• Git