Récemment, en réponse à d’innombrables demandes au fil des années, j’ai rédigé un tutoriel sur Git et GitHub destiné aux débutants, car cela demeure une exigence omniprésente dans les postes de développement depuis plusieurs années. Dans la première partie du tutoriel, que vous pouvez consulter ici, j’y expliquais ce que c’est, à quoi cela sert, nous préparions l’environnement, créions et clonions le dépôt, et réalisions les premiers ajustements, les stagings et les commits, en terminant par un push vers la branche main. On peut dire que nous avons traversé un cycle complet. Pas un cycle professionnel, mais complet.
Pourquoi je le dit ainsi ? Parce que, en règle générale, dans des projets professionnels, comme ceux pour lesquels vous allez postuler en entreprise, vous ne travaillerez pas sur la branche main et encore moins vous y ferez des commits et des pushes, ce n’est pas ainsi que cela fonctionne puisque main est un miroir de la production et que, bien souvent, le commit sur celle-ci déclenche des flux CI/CD qui déploient la nouvelle version en ligne.
Ainsi, dans cette leçon, nous allons approfondir certaines pratiques plus professionnelles avec Git et GitHub. Si vous préférez, vous pouvez suivre le contenu via la vidéo ci-dessous, qui couvre le même sujet.
Allons-y !
#1 – Parcourir les commits
Une fois que vous avez « pushé » votre premier commit, il est utile de jeter un œil à la page du dépôt sur GitHub pour voir ce qui s’est passé.
Vous remarquerez dans la bande grise juste au-dessus des fichiers le message du commit le plus récent (« second commit »), l’identifiant qui lui est associé, l’intervalle écoulé depuis sa création et le nombre total de commits du projet. En cliquant sur le message du commit, vous accédez à une page de détails où apparaissent les fichiers ajoutés ou modifiés, avec les ajouts affichés en vert, les suppressions en rouge et les autres changements en jaune.
Maintenant, si vous cliquez sur le nombre de commits, vous verrez quelque chose d’encore plus intéressant : la liste complète des commits du projet.
Grâce à cette liste, vous pouvez lire les messages de chaque commit, voir les modifications effectuées à chaque instant, observer l’état du dépôt à ce moment précis (Browse Repository) ou même remonter le temps. Oui, si, pour une raison quelconque, il vous faut récupérer une version antérieure du projet, vous pouvez utiliser la commande suivante pour le faire, en ayant simplement l’ID du commit que vous pouvez récupérer à droite de la liste des commits.
git checkout <id_commit>Cette commande va restaurer dans le dossier du projet la version précise que vous avez fournie, vous permettant de vous en servir, d’apporter de nouvelles modifications à partir de celle-ci et bien plus encore. Attention toutefois au fait que vous travaillez dans le passé, ce qui rend la fusion avec la version principale ensuite plus délicate ; le plus recommandé dans ce cas est de créer de nouvelles branches, ce que nous allons voir ensuite.
#2 – Gestion des branches et fusion
L’un des avantages d’utiliser un outil de contrôle de version est la possibilité pour deux personnes ou plus de travailler en parallèle sur le même projet. Cependant, lorsque Alice travaille sur une fonctionnalité A et Bob sur une fonctionnalité B, les modifications de l’un peuvent affecter le travail de l’autre, non ? Bien sûr, sur leurs machines respectives, ce souci n’apparaît que lorsque les modifications doivent être fusionnées. À ce moment-là, il faut effectuer ce que l’on appelle une fusion (merge), mais nous reviendrons dessus plus tard.
Le problème ici est que ni Alice ni Bob ne devraient pas travailler directement sur le miroir de production, c’est-à-dire sur la version main. En effet, pendant qu’ils ajoutent de nouvelles fonctionnalités, il peut surgir une demande urgente à résoudre sur la version de production, ce qui impliquerait un nouveau code et un nouveau déploiement. Si l’on continue à toucher à la version de production, celle-ci serait compromise et potentiellement destabilisée, quelque chose qui ne peut jamais arriver. Dans ce cas, chaque fois qu’Alice et Bob doivent intégrer de nouvelles fonctionnalités, ils doivent d’abord créer une nouvelle branche à partir de la main.
Une branche (ou ramification) est une copie du projet qui possède sa propre vie, comme une nouvelle ligne temporelle partant d’un point donné, généralement le plus récent. Chaque développeur peut créer sa propre branche et travailler dessus indépendamment des autres, y compris en y faisant des commits. Plus tard, lorsque son travail est terminé, il peut la fusionner avec une autre branche existante, par exemple main, afin d’unir l’historique principal. L’image ci-dessous illustre ce mécanisme.
Dans cet exemple, nous avons la branche master (ancien nom de main) en vert, symbolisant la version principale du projet. À un moment donné, le développeur bleu a créé une branche à partir du premier commit de main (le point vert) pour travailler sur de nouvelles fonctionnalités, et a fusionné son travail avec la branche principale trois commits plus tard (le point vert numéro 4). Notez qu’il a aussi eu trois commits, dont le premier est celui de création de la branche et les deux suivants les modifications qu’il a apportées, mais tout dans sa branche alternative. Pendant cette période, un autre développeur, l’orange, a également ouvert une autre branche sur le commit 3 de main, qui viendrait à se fusionner avec elle plus tard, à la fin du graphe.
En règle générale, Git est naturellement capable de fusionner les modifications du développeur bleu vers main et celles du développeur orange vers main. Ainsi, la fusion des modifications est généralement automatique et tout l’historique est préservé. Bien sûr, cela suppose qu’il n’y ait pas de conflits. Lorsque des modifications du bleu et de l’orange entrent en conflit — puisque l’orange a commencé son travail avant la fusion du bleu — il faut procéder à une analyse, de préférence avec un outil visuel, pour comprendre le code qui demeure, ce qui part et faire un compromis. Cela correspond à la fusion (merge), que nous développerons plus en détail plus tard. Pour l’instant, cette compréhension initiale est suffisante et nous allons maintenant apprendre comment créer des branches.
#3 – Utilisation des branches
La première étape pour commencer à utiliser les branches, après avoir compris le concept (expliqué précédemment), consiste à découvrir quelles branches existent actuellement dans le projet, ce qui peut être fait avec la commande ci-dessous.
git branchCela va lister leurs noms, l’un sous l’autre, et l’on peut s’attendre à voir uniquement « main » à ce stade. Un astérisque à côté du nom indique la branche actuellement sélectionnée sur votre machine.
Maintenant, imaginez que vous allez démarrer le développement d’une nouvelle fonctionnalité. La première étape est de créer une nouvelle branche, n’est-ce pas ? Vous pouvez le faire avec la commande ci-dessous.
git branch nom_branch
//ou
git switch -c nom_branch
//ou
git checkout -b nom_branchL’une quelconque de ces trois commandes crée une nouvelle ligne du temps à partir du dernier commit de la branche actuellement sélectionnée, et vous pouvez le confirmer avec la commande “git branch”. Cependant, la première commande ne crée que la branche sans la basculer pour commencer le travail. Pour réellement démarrer les modifications de manière indépendante de main dans notre nouvelle branche, il faut la sélectionner, avec l’une des commandes ci-dessous.
git switch nom_branch
//ou
git checkout nom_branchMaintenant, si vous exécutez à nouveau la commande pour lister les branches, vous verrez les mêmes branches affichées, mais l’indicateur indiquant la branche active sera à côté de la nouvelle que vous avez créée. À partir de là, toutes les modifications que vous effectuerez et que vous committerez appartiendront exclusivement à la nouvelle branche et non à main. Essayez d’apporter des modifications et relancez les commandes pour les sauvegarder.
//apportez des modifications au projet
git add .
git commit -m "explique les modifications"
//ou les deux ensemble avec:
git commit -am "explique les modifications"Maintenant, si vous exécutez la commande pour voir les commits (ci-dessous), vous verrez qu’il y a un commit supplémentaire dans votre nouvelle branche (la mienne s’appelle nouvelle_pagina).
git log --oneline
Le signalement “HEAD” indique le commit le plus récent pour la branche pointée. Notez que j’ai un HEAD pour nouvelle_pagina (ma nouvelle branche) et un autre pour main, qui est la branche origin (d’où ma ramification est partie).
Optionnellement, vous pouvez pousser ce commit sur le dépôt distant sur GitHub, afin de ne pas garder vos modifications uniquement en local. Notez que ce n’est pas la même chose qu’un merge, c’est simplement une mise à jour d’une de vos branches.
git push --set-upstream origin <nom_branch>L’option –set-upstream est nécessaire pour dire où envoyer votre push, ici vers l’origine de la branche dont vous passez le nom à la fin de la commande. Sinon, Git pourrait penser qu’il faut l’envoyer vers main, mais comme la branche active est une autre, il renverrait une erreur.
Une fois le commit enregistré en ligne, vous pouvez le voir sur la page du dépôt sur GitHub, mais seulement si vous choisissez la branche correcte dans le sélecteur à gauche. Si vous regardez la liste des commits de main, ce nouveau commit n’y existera pas.
Ensuite, nous verrons comment fusionner les branches (merge).
#4 – Réalisation des merges
À un moment donné, votre travail sur la nouvelle branche sera terminé, n’est-ce pas ? Lorsque cela se produit, si vous souhaitez que tout ce que vous avez fait fasse désormais partie de la version principale du projet, vous devrez effectuer la fusion (merge) de votre branche avec main. Avant cela, je recommande toujours de récupérer les dernières modifications de votre branche depuis le dépôt en ligne, car il peut y avoir des ajouts réalisés par un collègue sur la même branche ou parce que vous avez travaillé sur plusieurs machines différentes. Peu importe le motif, la commande pour télécharger les dernières mises à jour de votre branche est simple, comme ci-dessous.
git pullMaintenant, pour effectuer la fusion entre deux branches, la première étape consiste à changer la branche active pour la branche de destination (la « vraie »), dans ce cas main, afin d’intégrer les modifications de l’autre branche dans main.
git checkout main
//ou
git switch mainAvec la branche de destination sélectionnée, vous allez utiliser la commande ci-après pour récupérer les modifications de la nouvelle branche et les appliquer au-dessus de la branche actuellement sélectionnée (main).
git merge <nom_branch>Si aucun conflit n’apparaît, Git va fusionner automatiquement les fichiers modifiés, ajoutés, supprimés, etc., comme illustré ci-dessous, où un nouveau fichier a été ajouté et comprend 97 lignes.
Notez que le merge est local, donc si vous souhaitez que la version fusionnée soit poussée vers le dépôt en ligne, effectuez un nouveau push.
Si vous ne voulez plus utiliser la nouvelle branche après le merge, vous pouvez la supprimer avec la commande ci-dessous.
git branch -d nom_branchOptionnellement, si vous voulez forcer la suppression d’une branche, utilisez « -D ».
Mais ce qui vient d’être fait représente le scénario de fusion le plus « heureux » possible, n’est-ce pas ? Lorsque main est là, au repos, pendant que vous développez sur une autre branche et que les modifications y aboutissent, cela peut arriver autrement dans un cadre professionnel.
#5 – Résolution de conflits
Dans un second test, imaginez le scénario suivant : une nouvelle branche est créée, une modification est effectuée dans le fichier A. Git add, commit et push. D’accord, les modifications sur la branche sont en ligne.
Retournez maintenant sur la branche main, modifiez quelque chose dans un autre fichier B. Git add, commit. Tentez ensuite de refaire le merge en partant de main et en apportant les modifications de l’autre branche. Vous verrez qu’une fenêtre vous demandera un message de commit pour ce merge. Oui, dans le cas où nous avons deux lignes temporelles qui aboutissent à des points différents, nous aurons besoin d’un merge commit. Laissez un message dans la première ligne (les « # » servent à commenter) ou utilisez le message par défaut et enregistrez. Puis poussez pour envoyer tout sur GitHub.
Ainsi, main contiendra un nouveau commit spécifique au merge. Regardez ci-dessous comment, contrairement au merge précédent, nous n’avons pas transféré les commits de la branche nouvelle vers main, mais bien un merge commit spécifique réunissant tout après le dernier commit que nous avions effectué sur main, car nous avons utilisé main comme base du merge (la « vérité »).
Mais cet autre scénario est encore favorable, car chaque branche contient uniquement des modifications dans des fichiers différents. Mais que se passe-t-il lorsque deux développeurs modifient les mêmes fichiers ?
Le dernier scénario que nous devons tester est celui du merge avec conflits. Avant d’effectuer une modification qui nécessite une résolution manuelle des conflits, il est utile de configurer l’éditeur par défaut de Git pour ces situations. Dans le cas précédent, il suffit de laisser un message et il est probable que vous l’ayez dû faire via le terminal. Or résoudre des conflits de code via le terminal n’est pas une bonne idée; je recommande donc de configurer l’éditeur par défaut de Git sur VS Code, ce que vous pouvez faire avec la commande ci-dessous.
git config --global core.editor "code --wait"Si vous préférez un autre éditeur, adaptez simplement la commande finale.
Maintenant, passez sur une autre branche ou créez-en une nouvelle, apportez des modifications dans index.html. Git add, commit et push sur cette nouvelle branche.
Puis revenez sur main et apportez des modifications dans le même index.html, au même endroit que précédemment (pour générer le conflit), mais avec des valeurs différentes. Git add, commit.
Lorsque vous effectuerez le git merge, vous constaterez que le terminal vous avertira que la fusion automatique a échoué et que vous devrez réaliser la fusion manuellement dans l’outil choisi précédemment, ici VS Code.
En vous rendant dans VS Code, l’éditeur va ouvrir le fichier avec les deux versions mélangées et quelques options :
- Accepter les modifications actuelles : vous privilégiez votre version locale et rejetez celle de l’autre branche;
- Accepter les modifications entrantes : vous privilégiez la version de l’autre branche et rejetez votre version locale;
- Accepter les deux : Git va combiner les deux versions sur des lignes distinctes;
- Comparer les modifications : ouvre une autre fenêtre, divisée en deux, pour comparer les deux fichiers;
Ce qu’il vous faut faire est de comparer les options et prendre la meilleure décision selon le scénario, ce qui variera d’un cas à l’autre. Une fois votre choix effectué, cliquez sur l’option correspondante et enregistrez le fichier. Puis faites le staging des modifications, le commit et le push.
Conflit résolu !
Et voilà, nous achevons encore un chapitre de notre saga Git et GitHub pour débutants.
À bientôt !
