Qui n’a jamais rêvé de pouvoir retourner dans le temps afin de retrouver une autre version de soi-même. Un fantasme de pouvoir manipuler le temps à sa guise qui a été rendu possible de deux manières différentes : la machine à voyager dans le temps et Git.
Malheureusement le premier procédé a été détruit en 1985, il nous reste git, le système de gestion de version par excellence !
Alors git qu’est-ce que c’est exactement ?
Déjà bonne nouvelle, il n’est pas nécessaire de lui fournir 2,21 gigowatts de puissance, git est un outil ultra efficace et ultra léger, élémentaire !
Git a été inventé en 2005 par Linus Torvalds, le créateur du noyau Linux, durant un projet où suite à une mésentente commerciale avec le propriétaire du système de gestion de version qu’il utilisait à l’époque, il a décidé de créer son propre système, qui deviendra le plus utilisé dans son genre, soit plus de douze millions de personnes dont l’équipe technique d'(agence) BASH.
Git permet de conserver chaque étape de travail lors du développement et ce selon un journal défini par le développeur. En plus de conserver différentes versions, il permet de créer des branches de travail fusionnables entre elles afin de regrouper les fonctionnalités du projet. Il est important de définir au préalable ses versions que l’on enregistre en guise de checkpoints. C’est grâce à ces derniers qu’il sera possible de voyager à travers les différentes étapes du projet. Les branches quant à elles, permettent de travailler en parallèle de sa branche principale jusqu’au moment où l’on décide de rassembler l’ensemble de son travail.
Git peut être intégré à n’importe quel projet. En l’état, chaque projet débute sous la forme d’un répertoire de travail où chaque fichier est enregistré localement sur notre machine. C’est la première étape de notre arborescence de fichiers. La seconde étape consiste à ajouter nos fichiers dans un index qui constitue une zone tampon servant à préparer le prochain commit. Ce dernier est l’instantané permettant de sauvegarder le travail sur la branche courante, dernière étape de l’arborescence. L’historique des versions et donc de chaque commit, sera basé sur cette dernière étape. Les commits sont basés sur les fichiers ajoutés à l’index par l’utilisateur.
Un outil de gestion de version afin de manipuler l’historique de son travail c’est super, la possibilité de pouvoir partager son code avec d’autres utilisateurs c’est encore mieux, c’est là que Github entre en jeu.
Github est une plateforme permettant d’héberger le code source d’un projet. Cela offre la possibilité de partager son travail avec d’autres utilisateurs, en particulier des collaborateurs dans le cadre d’un projet d’équipe. La plateforme est également un client git, elle permet de réceptionner les commits émis depuis le dépôt local d’un utilisateur afin de les rendre visibles sur le dépôt distant.
Par conséquent, chaque utilisateur a la possibilité d’envoyer son travail sur la plateforme distante qui accueillera le code commun du projet. C’est une excellente solution pour organiser un travail collaboratif.
Pour résumer, Git permet d’organiser les différentes phases de développement à travers la sauvegarde à des points définis ainsi que de maquetter une fonctionnalité avant de décider de l’intégrer au projet. Github quant à lui offre une plateforme distante permettant d’héberger le projet afin de le rendre accessible aux autres collaborateurs pour que chacun puisse apporter une pierre à l’édifice.
Mise en place
Git n’est pas nécessairement présent par défaut sur votre machine, voici les différentes étapes pour l’installer en fonction de l’environnement que vous utilisez.
Mac OS
Ouvrez votre terminal et entrez cette commande :
git --version |
Ici le terminal nous donne la version de git installée, sauf si ce dernier n’est pas présent sur notre machine.
git version 2.32.0 |
Si git n’est pas installé, vous pouvez utiliser l’installateur téléchargeable depuis le site web de git.
Si Homebrew, le gestionnaire de package pour Mac, est installé sur votre machine, vous pouvez directement utiliser la commande suivante :
brew install git |
Linux
Ouvrez votre terminal et entrez cette commande :
git --version |
Si git n’est pas installé, vous pouvez utiliser l’outil de gestion de paquet dépendant de votre distribution.
Pour Debian/Ubuntu :
sudo apt install git-all |
Pour Fedora :
sudo dnf install git-all |
Vous pouvez consulter le site de git-scm pour plus d’informations sur les différentes méthodes d’installation en fonction de votre version de Linux.
Windows
Ouvrez l’invite de commande (Windows+X) et entrez la commande suivante :
git --version |
Si git n’est pas installé, vous pouvez utiliser l’installation disponible sur le site web de git.
Initialisation de git
Dans le cas de l’utilisation de la plateforme Github, certains éléments de configuration sont nécessaires à une bonne utilisation de git.
Rendez-vous sur github.com, créez votre compte et ajoutez un nouveau répertoire avec le bouton New.
Donnez un nom de répertoire dans le champ Repository name. Vous pouvez choisir de le rendre public ou privé si vous décidez de choisir qui pour avoir accès à ce répertoire. Dans tous les cas, vous choisissez qui peut enrichir et modifier les éléments de votre projet.
N’ajoutez pas de fichier README.md, il sera préférable de le créer soit-même localement.
Github va vous indiquer l’adresse du répertoire distant à utiliser.
Cas n°1 : je possède déjà localement un répertoire de travail pour mon projet
Afin de pouvoir utiliser git sur votre répertoire de projet, il est nécessaire d’y créer un fichier .git. Pour ce faire, ouvrez un terminal au sein du projet (pour Windows, utilisez le terminal git bash installé avec git) et entrez la commande suivante :
git init |
Voici la liste des commandes à exécuter :
git remote add origin <adresse HTTPS de votre répertoire Github> |
Votre dépôt distant est désormais synchronisé et connecté à votre dépôt local.
Cas n°2 : je souhaite créer un nouveau projet
Dans le cas où vous créez votre projet sur Github et qu’il n’existe pas localement, commencez par cloner le dépôt distant sur votre machine. Placez-vous dans le terminal dans le dossier destiné à accueillir le répertoire du projet et entrez la commande suivante :
git clone <adresse HTTPS de votre répertoire Github> |
Cela va avoir pour effet d’importer le dépôt distant, à savoir qu’un message du terminal va vous indiquer que le répertoire est vide, cela est normal étant donné que le dépôt distant est vide lui aussi.
Dans le répertoire du projet, créez le fichier README.md qui sera destiné à accueillir les informations présentant votre projet et qui sera lu en guise de page d’accueil sur l’interface web de votre dépôt Github. Entrez la commande suivante :
echo "readme" >> README.md |
Nous allons effectuer ici notre premier ajout de fichier local à l’index git :
git add README.md |
Ici nous avons choisis d’ajouter le fichier README.md à l’intex.
Il est temps de préparer notre premier commit ! Que d’émotions… Rappelez-vous, il s’agit de l’étape permettant de sauvegarder dans l’historique (HEAD) git l’étape de notre projet en guise de checkpoint. Allez c’est parti !
git commit -m "first commit" |
Le commit est présent localement, mais l’intérêt de Github c’est qu’il le soit aussi sur le dépôt distant ! Pour ce faire entrez la commande suivante :
git push -u origin main |
Bravo, vous avez récupéré localement le dépôt distant et vous y avez même ajouté votre README.
Afin de pouvoir vous connecter à votre répertoire distant, il est conseillé de paramétrer sur votre machine les éléments d’authentification. Sans cette étape, votre terminal vous demandera votre identifiant et mot de passe Github à chaque fois que vous souhaiterez interagir avec le dépôt distant afin que Github s’assure que vous avez bien les droits sur ce dépôt et également de donner une identité derrière chaque modification faîte. Afin d’éviter la redondance des commandes d’authentification, nous vous conseillons de réaliser cette configuration.
Dans le cadre d’une authentification HTTPS, entrez la commande suivante au sein de votre répertoire
git config credential.helper store |
A la prochaine commande d’interaction entre votre projet local et le dépôt distant, le terminal vous demandera vos identifiants, ces derniers seront sauvegardés dans le fichier .git-credentials afin de ne plus vous demander de vous identifier à la prochaine commande.
Git & Github : voyages et mondes parallèles !
Désormais, nous avons toutes les cartes en main pour travailler avec l’outil puissant git en collaboration avec la plateforme Github. Désormais, nous allons voir comment utiliser ces cartes à bon escient, faites vos jeux !
Les branches
Être développeur web c’est être branché et ça tombe bien parce qu’avec git il est possible de travailler à travers un système de branches, voici un schéma explicatif pour s’échauffer :
- Branche principale (main) : cette branche, c’est la version finale de notre projet ! Dans une bonne pratique, les éléments apportés à cette branche sont ceux que l’on considère comme terminés et prêts à être déployés, par conséquent, on ne code pas directement sur cette branche, on y ajoute les éléments de la branche suivante (branche enfant) qui auront été validés.
- Branche de développement (develop) : branche enfant de main, c’est ici que l’on va pouvoir travailler les différentes fonctionnalités de notre projet mais encore une fois et dans une bonne pratique, les fonctionnalités seront codées également dans différentes branches enfants.
- Branche de fonctionnalité (feature) : dernière branche de notre arborescence, c’est sur cette branche que nous allons coder notre fonctionnalité.
Les phases clés pour travailler dans de bonnes conditions
Nous débutons sur une seule et unique branche, la branche main. La première étape consiste à créer notre branche develop avec la commande suivante :
git checkout -b develop |
checkout indique à git que nous souhaitons changer de branche (ici en partant de main)
-b indique à git de créer la branche de destination
develop est ici notre branche de destination que nous venons de créer
Nous arrivons donc sur la branche develop créée à partir de la branche main.
Désormais, nous souhaitons créer notre première branche de développement qui va accueillir notre fonctionnalité.
Nous sommes sur la branche develop mais en cas de doute il est possible de connaître la branche sur laquelle nous nous situons avec la commande suivante :
git branch |
Il est temps de créer notre branche feature :
git checkout -b feature/nomdelafonctionnalité |
Une bonne pratique consiste à indiquer le type (feature/) afin de donner de la lisibilité sur le type de branche créée.
Nous pouvons à partir de là entrer dans le vif du sujet et coder notre fonctionnalité en toute sécurité.
En effet, tout ce qui sera fait ici n’impactera pas notre branche develop tant que l’on ne l’aura pas décidé.
Commit, Merge et Pull Request
Chaque étape de notre fonctionnalité nécessitera une sauvegarde de nos données, pour ajouter à l’index (zone tampon) nos fichiers modifiés, effectuez la commande suivante :
git add . |
Ici le “.” permet d’ajouter à l’index tous les fichiers que l’on aura modifiés, il est possible de cibler un fichier en particulier en remplaçant le point par le nom du fichier.
La commande suivante permet de consulter l’ensemble des modifications ajoutées à l’index:
git status |
Enfin, pour ajouter le contenu de notre index à l’historique du projet, nous allons effectuer la commande suivante :
git commit -m "description du commit" |
Le commit est créé, l’index est désormais vide et prêt à accueillir les éléments du prochain commit.
Une fois que nous estimons avoir terminé le développement de notre fonctionnalité, notre branche possède un ou plusieurs commits en fonction de la complexité de la fonctionnalité ou de l’organisation personnelle du développeur en termes de découpage.
L’avantage de répartir son travail sur plusieurs commits permet plus de lisibilité sur le suivi de développement de la fonctionnalité mais également de pouvoir revenir à l’état d’un commit précédent (principe de la gestion de version), ce qui peut s’avérer dans certains cas très utile.
La commande suivante permet de lister l’ensemble des commits réalisés :
git log |
Le terminal nous renvoie un ou plusieurs commits, exemple :
| commit af8bef25cef85f818bec9666f5578bb5af17d3d1 Author: Me Date: Mon Jun 20 15:08:17 2022 +0200 |
Le nom du commit est indiqué sur la première ligne, si plusieurs commits apparaissent, ils sont rangés par ordre chronologique du plus récent au plus ancien par conséquent si vous décidez de revenir à l’état d’un commit en particulier, toutes les données liées aux commits arrivant chronologiquement après seront ignorées. La commande suivante permet de basculer à l’état du commit choisi (ici on prend l’exemple du commit ci-dessus) :
git checkout af8bef25cef85f818bec9666f5578bb5af17d3d1 |
Vous pouvez à partir de là parcourir l’état de votre code au moment du commit ciblé. Il sera possible par exemple de créer à partir de là une nouvelle branche.
Si vous préférez revenir à l’état de ce commit en supprimant le travail effectué après, effectuez cette commande à la place de celle réalisée précédemment :
git reset --hard af8bef25cef85f818bec9666f5578bb5af17d3d1 |
Le –hard peut paraître effrayant et pour cause cela supprime tout ce qui aura été fait après, soyez sûr de votre choix !
Une fois que vous avez terminé, il est temps de soumettre votre travail au dépôt distant ! Commande s’il vous plaît ! :
git push origin nomdelabranche |
Le push envoie votre branche locale sur le dépôt distant en créant la même branche et en respectant l’arborescence des branches.
La branche fraîchement créée est désormais disponible sur le dépôt distant, il est désormais possible de la fusionner avec la branche develop mais avant cela il est indispensable de s’assurer que le travail produit réponde aux attentes de développement et qu’il n’y a pas de conflit.
En effet, dans le cas où deux personnes réalisent chacune un travail sur une branche qui leur est propre, il est possible que ces personnes aient modifié les mêmes lignes de code, ou encore qu’une personne ait supprimé des lignes qui sont utilisées par l’autre personne.
Durant la fusion des branches, Git ne sera pas en mesure de déterminer seul dans ce contexte quels éléments il est nécessaire de conserver.
Heureusement, lors de la soumission de la branche, Github nous propose de réaliser une Pull Request.
La Pull Request
La Pull Request permet dans un premier temps de faire analyser par Github la branche soumise dans le but de détecter les éventuels conflits et cela afin de nous donner la possibilité de les résoudre en supprimant les lignes bloquantes. L’autre intérêt, et pas des moindres, est de faire analyser également la branche par les autres développeurs. Le travail collaboratif prend une part importante, il sera en effet possible de constater le travail effectué afin d’y apporter des commentaires ou des corrections avant d’approuver la branche.
Il sera possible d’ajouter des personnes pour faire approuver notre code dans la partie “Reviewers” à droite de la page de notre Pull Request.
Une fois la branche propre et validée, il sera possible de la fusionner avec la branche develop grâce au bouton Squash & Merge.
Désormais, notre travail fait partie de la branche principale de développement, notre contribution fut une réussite ! Il est désormais possible pour les autres développeurs de mettre à jour leur branche develop locale depuis le repo distant. Il suffit de se placer sur cette branche et d’effectuer la commande suivante :
git pull |
Dans le cas où l’on est en train de travailler sur une feature en ayant crée une branche enfant de develop, il sera possible de récupérer la nouvelle version de la banche de développement afin de limiter les éventuels conflits avec la commande suivante :
git pull origin develop |
Cette dernière commande est très pratique dans le cas où une autre personne a récemment envoyé des modifications sur la branche de développement et que l’on souhaite récupérer ces dernières pendant la phase de développement de notre propre fonctionnalité.
Sauvegarder son travail, traverser l’historique de git pour retrouver l’état d’avancement désiré ou encore développer une fonctionnalité sur une branche à part, travailler de manière organisée et collaborative, gérer des conflits et soumettre à approbation… Les possibilités offertes par les deux outils présentés dans cet article sont riches et apportent un environnement optimal dans le développement des applications. Il existe tant d’autres fonctionnalités utiles valant la joie d’être découvertes, mais vous avez ici l’essentiel d’entre elles pour commencer, clé en main, votre voyage à travers les commits !
