Blog

TP : PRISE EN MAIN DE GIT ET GITLAB

maxresdefault
Développement web & mobile

TP : PRISE EN MAIN DE GIT ET GITLAB

Objectifs du TP : 

  • Enregistrer et retrouver les modifications avec les commits
  • Installer la solution de versioning Git
  • Envoyer le code sur une autre machine dite remote
  • Créer un repository Git
  • Enregistrer des commits
  • Repérer les fichiers à ignorer
  • Résoudre les conflits de branche
  • Expliquer les notions de commit, d’historique des validations et de branche

Installation de GIT

Mac

Téléchargez la dernière version de Git sur : http://git-scm.com/downloads 

Ouvrez le fichier ainsi téléchargé et suivez les instructions en laissant toutes les valeurs par défaut.

Linux

Téléchargez la dernière version de Git sur : http://git-scm.com/downloads 

Ouvrez le fichier ainsi téléchargé et suivez les instructions en laissant toutes les valeurs par défaut.

Ouvrez la console. Si vous ne savez pas utiliser cette console, allez jeter un œil au rappel au début de ce chapitre. 

Exécutez la commande suivante pour définir votre nom et l’email que vous utiliserez ensuite pour créer votre compte gratuit sur GitHub:

git config –global user.name « Votre nom ou pseudo »
git config –global user.email « Votre@email.com »

Pour vérifier que tout va bien, relancez votre console et tapez simplement ‘git’. Si l’installation a fonctionné, vous devriez voir du texte en anglais expliquant l’utilisation de Git.

Windows

Rendez-vous sur http://msysgit.github.io et téléchargez la dernière version disponible. Une fois le fichier récupéré, lancez-le et suivez les instructions. Vous pouvez laisser toutes les configurations par défaut. Cela va vous donner accès à Git ainsi qu’à une console émulant le comportement de Bash, la console sous Linux. Du coup, vous aurez accès aux mêmes commandes que tout le monde (ls, cd, mkdir…).

Maintenant vous allez pouvoir ouvrir l’application “git bash” qui se situe maintenant dans votre menu Démarrer. Si vous ne savez pas utiliser cette console, allez jeter un œil aux rappels du début de ce chapitre.

Exécutez la commande suivante pour définir votre nom et l’email que vous utiliserez ensuite pour créer un compte gratuit sur Github:

git config –global user.name « Votre nom ou pseudo »
git config –global user.email « votre@email.com »

Pour vérifier que tout va bien, relancez votre console et tapez simplement ‘git’. Si l’installation a fonctionné, vous devriez voir du texte en anglais expliquant l’utilisation de Git.

L’éditeur de texte

Mac ou windows & même sur linux

  • Visual Studio Code
  • Sublime Text
  • Notepad++
  • Etc.

Linux

  • Vim
  • Nano
  • Etc.

Faisons notre premier commit

Pour commencer, créez un nouveau dossier nommé Premier-Repo et positionnez vous dedans avec la console. 

Pour activer un dossier comme repository Git, il suffit de se placer dans ce dossier avec le Terminal puis d’utiliser la commande : 

git init

Cette commande crée dans le dossier un dossier caché .git permettant à Git de générer un index de tous les fichiers dont il doit faire le suivi plutard.

Nous pouvons initialiser le repository par un fichier readme.md que nous allons éditer avec un éditeur aux choix & y ajouter le texte suivant : 

“TP pour une bonne prise en main de GIT & GITLAB”

La commande git status peut-être exécuter pour voir s’il y a eu des changements dans le Repo

Lorsque vous créez un fichier dans un repository, vous devez donc l’ajouter à l’index Git à l’aide de la commande
git add nomDeVotreFichier.extension

Pour gagner du temps, vous pouvez ajouter tous les fichiers dans le répertoire courant en tapant

git add . dans la console. Évidemment, faites bien attention quand vous utilisez ce raccourci pour ne pas rajouter trop de fichiers à l’index.

Lorsque vous modifiez votre repository, vous devez demander à Git d’enregistrer vos modifications en faisant un git commit. L’option-m vous permet de lui envoyer un message décrivant les modifications effectuées, ce qui s’avèrera très utile pour vous par la suite, you’ll see!

Grâce à la commande  git log qui vous affiche la liste de tous les commits que vous avez réalisés ! 

Dans la liste de cet historique, chaque commit est répertorié avec :

  • son SHA  : son identifiant unique, qui se présente sous forme d’une longue chaîne de caractères et de nombres. Par exemple : 1a0c47fd0cd8ad5f6edd5ec93a9d9dd247fa79dd
  • son auteur
  • sa date
  • sa description : avec l’option  -m que nous avions utilisée dans le git commit

Astuces, nous pouvons condenser les deux commandes en une seule commande avec la commande : 

git commit -a -m “Initial commit rajoutant un fichier readme.md au repo”

Positionnez-vous sur un commit donné

Ajoutons un autre fichier index.php à notre projet & et reprenons le processus déjà effectué pour commiter le fichier

Pour annuler une commit & détacher le fichier ajouter à la commit, vous pouvez utiliser les commandes suivantes : 

git reflog

git reset --hard sha

On ne peut pas vraiment « supprimer » un commit, mais on a plusieurs options pour l’annuler. Cependant, ces options ont des limites et sont à utiliser avec prudence

Sinon, si vous voulez simplement modifier le message de votre dernier commit, vous pouvez utiliser la commande suivante :

git commit --amend -m “Votre nouveau message”

Une fois que vous avez travaillé sur votre code et effectuer vos commits, vous allez donc les envoyer sur un remote, c’est-à-dire une autre machine qui peut être : 

  • interne (si vous avez la chance d’avoir plusieurs ordinateurs ;) )
  • ou externe (grâce à des services comme GitLab ou GitHub ou encore BitBucket). Utiliser un remote externe va aussi vous permettre de travailler sur des projets à plusieurs, pour que tout le monde ait accès aux dernières modifications de chacun sur un remote partagé. 

GitLab est un service en ligne qui permet d’héberger ses repositories de code. Il est un outil gratuit pour héberger du code open source, et propose également des plans payants pour les projets de code privés.

Pour créer votre compte GitLAB, rendez-vous sur le site où vous pourrez entrer un nom d’utilisateur, un mot de passe, etc. Une fois votre compte créé, vous aurez accès à votre dashboard et découvrirez toutes les fonctionnalités de GitLAB. Vous allez pouvoir notamment : 

  • Communiquer avec d’autres développeurs et signaler des problèmes de code en déclarant des « issues » ;
  • Partager des morceaux de code en ligne ;
  • Proposer des modifications de code à d’autres repos en faisant des « pull requests » ;
  • Et même récupérer du code depuis un autre repository.

Créons notre premier repository

Il suffit de créer un nouveau projet dans GITLAB

Sur GitLab vous choisirez entre projet vide ou un projet à partir d’un modèle ou bien importer un projet depuis Github, Bitbucket, … ou tout simplement démarrer un CI/CD et ce dernier point nous intéressera dans l’intégration continue devops

Dans cette prise en main de GITLAB, nous allons créer un projet vide c’est-à-dire create blank project

  • un nom
  • une description (optionnelle)
  • le définir à public ou privé
  • Initialiser avec un readme si projet n’existe pas encore en local
  • Cliquer sur create project

… et en parlant de la commande git clone, notez que vous pouvez cloner votre repo avec deux options : (nous allons revenir sur cette commande)

  1. L’option HTTPS que je vous ai  invité à utiliser dans ce cours : c’est l’option la plus simple, qui demande de fournir vos identifiants GitLab (nom d’utilisateur et mot de passe) à chaque fois que vous faites un git clone
  2. L’option SSH qui est plus pratique car elle ne vous demande pas vos identifiants à chaque fois. Par contre, pour l’utiliser, il faut générer une clé SSH, ce qui est un peu plus compliqué pour ce cours d’initiation. Mais une fois que vous vous sentez plus à l’aise, je vous invite à consulter l’édition de votre profil GitLab et à utiliser cette option SSH.  

Envoyez votre code sur GitHub

git init

git remote add origin git@gitlab.com:senyr9/premier-repo.git

git add .

git commit -m "Initial commit"

git push -u origin master

Maintenant si vous actualiser le repos vous remarquerez que les fichiers y sont

La branche master est la branche qui contient le code courant de votre repo GitLab. Ne vous préoccupez pas trop du terme « branche », on y reviendra par la suite. (remote origin par défaut)

Lorsque vous lancez la commande git push, il est possible que l’on vous demande vos identifiants GitHub. Renseignez-les dans le terminal !

git push permet d’envoyer vers le dépôt distant

git pull permet de récupérer les modifications faites sur le dépôt distant c’est-à-dire depuis GitLab

Ajoutons un fichier contact.php depuis GitLab & récupérons le en local

Par défaut, c’est la branche master mais néanmoins nous pouvons préciser la branche avec la commande git pull origin master

Pensez à synchroniser régulièrement votre code local avec vos repos en ligne à l’aide des commandes git push et pull. C’est particulièrement important lorsque vous travaillez à plusieurs sur un projet, pour que tout le monde avance sur la même base !

Récupérez du code d’un autre repository

Nous pouvons aussi récupérer un projet public ou même privé si nous sommes invité en local avec la commande git clone via ssh ou https

Créez des branches

Les branches permettent de travailler sur des versions de code qui divergent de la branche principale contenant votre code courant. 

Travailler sur plusieurs branches est très utile lorsque vous souhaitez tester une expérimentation sur votre projet, ou encore pour vous concentrer sur le développement d’une fonctionnalité spécifique.

Nous pouvons créer des branches en ligne de commandes ou depuis l’interface GitLab

D’abords en ligne de commande avec la commande suivante : 

git branch nouvelle-branche

git branch pour voir les branches crées

Pour switcher entre les branches, nous utilisons la commande 

git checkout ma-branche

Petite astuce pour manipuler vos branches : vous pouvez utiliser la commande ‘git checkout -b‘ pour créer une branche et vous y positionner. Ainsi, au lieu de taper la commande suivante pour créer votre branche :

git branch ma-branche

, puis une deuxième commande pour vous y positionner :

git checkout ma-branche

, vous pouvez regrouper ces deux opérations en une seule commande : 

git checkout -b ma-branche

Fusionnez des branches

Lorsque vous travaillez sur plusieurs branches, il va souvent vous arriver de vouloir ajouter  dans une branche A les mises à jour que vous avez faites dans une autre branche B. Pour cela, on se place dans la branche A :

git checkout branche-A

Puis on utilise la commande git merge : 

git merge branche-B

Fusionner des branches est une pratique courante lorsque vous travaillez sur un projet : vous devez toujours chercher à remettre les modifications faites sur vos différentes branches dans la branche principale master.  

Modifions le fichier contact.php de la branch DevOps

d’abord un git checkout & git branch pour s’assurer que nous sommes dans la bonne branche

git status pour voir les modifications 

git commit -am “formulaire de contact” pour commiter les changer, ici comme le fichier est déjà indexé, nous pouvons utiliser le raccourci -am

git checkout master pour basculer à nouveau sur le master

git status ou git log pour voir que les modifications apportées sur l’autre branch (Devops) ne sont pas présentent ici

git merge devops pour fusionner les deux branches

Résolvez un conflit

Nous allons simuler un conflit essayer de voir comment le résoudre de différente manière

Nous avons utilisé un exemple assez simple où tout s’est bien passé. Mais il arrive très souvent qu’il y ait des conflits entre les deux branches qui empêchent de les fusionner, par exemple lorsque plusieurs personnes travaillent en même temps sur un même fichier.

Nous allons switcher dans les deux branches & modifier le titre principal de la page contact.php

Revenons à la branche devops & modifions aussi le fichier contact.php

Essayons maintenant de fusionner de merger la branche devops à la branche master

Git va reconnaître qu’il existe un conflit entre les deux branches

Vous allez donc devoir ouvrir le fichier contact.php dans votre éditeur de texte. 

Vous allez alors voir les différences de contenu du fichier contact.php entre les deux branches, et vous pouvez choisir quel contenu garder pour la branche master

Maintenant que vous avez résolu le conflit, il vous reste à le dire à Git ! Car pour l’instant, si vous faites un git status, git vous dira que vous avez des branches non fusionnées (« unmerged paths »). Pour cela, ajouter à nouveau le fichier contact.php avec git add et faites un commit sans message : git commit

Vous pouvez  alors personnaliser le message du commit si vous le souhaitez. Dans notre cas, la résolution étant assez simple, nous allons garder le message proposé par défaut et le sauvegarder en tapant :x

Git va alors vous confirmer que vos branches ont été fusionnées, et si vous consulter l’historique des commits avec git log, vous verrez apparaître le dernier commit de résolution du conflit avec le message

Pour retrouver qui a modifié une ligne précise de code dans un projet, faire une recherche avec git log peut s’avérer compliqué, surtout si le projet contient beaucoup de commits. Il existe un autre moyen plus direct de retrouver qui a fait une modification particulière dans un fichier : la commande git blame.

Pour retrouver pourquoi cette modification a été faite, vous avez deux possibilités : 

  1. Faire un git log et rechercher le commit dont le sha commence par d311ef2a. 
  2. Utiliser la commande git show qui vous renvoie directement les détails du commit recherché en saisissant le début de son sha : 

On en revient à un point essentiel : pensez à écrire des messages clairs et précis lorsque vous faites vos commits. Cela vous facilitera la vie lorsque vous reviendrez dessus plus tard, et la vie de vos collaborateurs ! Et si vous tombez sur une modification pour laquelle le message de commit n’est pas assez explicite, gardez en tête que vous pouvez contacter l’auteur du commit pour en savoir plus. 

Pour des raisons de sécurité et de clarté, il est important d’ignorer certains fichiers dans Git, tels que :

  • Tous les fichiers de configuration (config.xml, databases.yml, .env…)
  • Les fichiers et dossiers temporaires (tmp, temp/…)
  • Les fichiers inutiles comme ceux créés par votre IDE ou votre OS (.DS_Store, .project…)

Créons à présent deux nouveaux fichiers config.php pour la configuration de nos variables globales et password.txt pour garder là bas les mots de passe de notre base de données par exemple.

Créez le fichier .gitignore pour y lister les fichiers que vous ne voulez pas versionné dans Git (les fichiers comportant les variables de configuration, les clés d’APIs et autres clés secrètes, les mots de passe, etc.). Listez ces fichiers ligne par ligne dans .gitignore en indiquant leurs chemins complets.

Maintenant envoyons tous vers notre dépôt GitLab pour voir

Un des aspects passionnants lorsque vous faites du développement, c’est que vous pouvez apporter votre pierre à plein d’édifices en contribuant à des projets open-source. :magicien:

Nous allons voir ici comment proposer une modification à un projet hébergé sur GitLab ou GitHub.  On appelle ça faire une pull request (PR).

Le premier réflexe à avoir est de regarder dans la documentation du projet si des recommandations sont précisées sur comment faire une pull request. Certains peuvent demander d’utiliser un format spécifique pour les messages de commit et de PR, d’ajouter des tests, etc. En général, vous trouverez ces recommandations dans le fichier README, avec un intitulé « Contributing » ou « Pull requests ».

Ensuite, clonez votre copie depuis GitLab ou GitHub sur votre machine

git clone https://gitlab.com/public.hardcode.kz/action-log.git

 git checkout -b nouvelle-branch pour créer une nouvelle branche où faire ses modifications et se placer dedans

Faire des modifications dans la nouvelle branche et « committer » les dans Git en veillant à rédiger des messages de commit clairs, par exemple :

git commit -m “Added feature allowing users to comment on the blog articles”

Envoyer vos modifications sur GitLab ou GitHub en faisant un git push de votre nouvelle branche

git push origin nouvelle-branch

Notez que nous ne faisons pas un « git push origin master » : ce n’est pas votre branche principale « master » mais bien votre nouvelle branche

Une fois vos modifications envoyées sur votre fork GitHub, il vous reste à transmettre votre demande de modifications en faisant un pull request. Pour cela, placez-vous sur votre fork GitHub, sur votre nouvelle branche, et cliquez sur « Compare & pull request ».

Vous allez alors être amenés à rédiger un message pour présenter votre proposition de modifications à l’auteur du projet.

Vous remarquerez que sous votre message, GitHub propose un comparatif détaillé de vos modifications par rapport au projet auquel vous souhaitez contribuer. 

Une fois votre pull request envoyé, l’auteur du projet consultera vos propositions, et vous recevrez une notification par GitHub lorsqu’il/elle les aura intégrées ou refusées. Il se peut aussi qu’il/elle vous contacte pour vous demander des précisions avant d’accepter ou non votre PR. 

Bonus

Laissez votre pensée ici

Select the fields to be shown. Others will be hidden. Drag and drop to rearrange the order.
  • Image
  • SKU
  • Rating
  • Price
  • Stock
  • Availability
  • Add to cart
  • Description
  • Content
  • Weight
  • Dimensions
  • Additional information
Click outside to hide the comparison bar
Compare