Git et le versioning

Bienvenue les cadettes et les cadets ! Maintenant qu'on a défini les besoins de notre client zombie, nous allons mettre en place les outils nécessaires pour bien travailler. Le premier, et un des plus importants pour travailler professionnellement en équipe, c'est git !

À quoi sert Git ?

Avant le Cataclysme, quand on débutait dans le code et qu'on cherchait notre premier travail, c'est dans notre maîtrise de ce genre d'outil que la différence pouvait se faire lors d'un entretien d'embauche ! En effet, quand on commence, on maîtrise tous plus ou moins le code de la même façon. C'est donc sur ces petits "plus" qu'on pouvait vous choisir, vous, plutôt qu'un autre.

Git a trois avantages :

• On garde un historique des points d'étape (commit) qu'on a créés. Si l'on souhaite revenir en arrière parce qu'un bug est apparu ou parce que ce qu'on vient de faire ne nous convainc pas, on peut le faire facilement en indiquant à Git à quel point d'étape on souhaite revenir.
• On peut travailler à plusieurs sur le même projet. Git va fusionner les fichiers communs pour mixer les modifications afin d'éviter de devoir faire le delta de chaque fichier à la main.
• On va pouvoir sauvegarder nos projets sur des dépôts distants (repositories = Gitlab/Github). On peut ainsi :
  • bosser sur plusieurs ordinateurs et toujours avoir un projet à jour en centralisant le code à un même endroit ;
  • partager le code de nos projets avec une communauté, exemple : les projets open source ; 
  • montrer ce qu'on sait faire, par exemple dans le cadre d'un entretien d'embauche.

Installation

Linux

Utiliser le gestionnaire de paquets de son instance de Linux, exemple sur Ubuntu/Debian :

sudo apt update && sudo apt install git

Mac

Sur MacOS, certains paquets embarquent avec eux Git (comme XCode par exemple), vérifier si Git n'est pas déjà installé sur sa machine :

git --version

Sinon l'installer avec HomeBrew :

brew install git

Windows

Se rendre sur la page de téléchargement de Git pour Windows et lancer l'installateur. Si vous avez besoin de plus d'informations, regardes la vidéo associée à ce cours au chapitre sur l'installation Windows.

Paramétrage de Git

Avant de commencer à utiliser Git, il faut paramétrer le nom d'utilisateur et l'adresse email :

git config --global user.name "John Doe"
git config --global user.email "john@doe.fr"

Si vous souhaitez changer le nom d'utilisateur et/ou l'email dans un projet spécifique, si vous bossez par exemple sur un projet perso et que vous avez des infos pro habituellement (ou vice versa), vous pouvez faire les mêmes commandes, après le git init, dans le dossier du projet spécifique, sans le --global :

git config user.name "John Doe"
git config user.email "john@doe.fr"

Initialiser Git dans un projet

À la racine du projet qu'on veut versionner avec Git, on fait :

git init

Git va créer un dossier masqué .git à la racine, dossier qu'on ne touchera pas, il ne sert qu'à Git.

Add

Pour pouvoir faire un commit, il faut indiquer à Git quels sont les fichiers qu'on va lui lier. Pour ça, on utilise :

git add /chemin/leNomDuFichier.html fichier2.css

...ou...

git add .

... pour ajouter tous les fichiers modifiés/créés/supprimés. Cette commande est à manier avec précaution, car de grands pouvoirs impliquent de grandes responsabilités 😉🕷️. C'est surtout qu'on risque d'ajouter des fichiers qu'on ne souhaitait pas, par erreur (un fichier qui contient des credentials, par exemple).

Documentation pour la méthode add [en].

Commit

Un commit est un point d'étape sauvegardé. Quand on fait :

git commit

...on dit à Git retient l'état du projet à ce moment-là. Comme ça, si l'on souhaite plus tard revenir à cet état du projet, on pourra dire à Git : "Reset le projet au commit N°X" et Git reviendra à l'état X.

Une fois qu'on a fait la commande ci-dessus, Git va ouvrir l'éditeur de texte par défaut et va vous demander de mettre un court message de commit. Essayez d'être clair et concis sur ces messages, on conseille moins de 48 caractères. De plus, privilégiez l'anglais pour habituer votre cerveau à manier la langue de Shakespeare.

Si sur votre machine aucun éditeur ou celui associé à git ne vous satisfait pas, vous pouvez changer l'éditeur qui sera ouvert par git avec cette commande : 

git config --global core.editor "nom_de_lediteur"

Pour vim par exemple :

git config --global core.editor "vim"

On peut aussi faire un raccourci pour indiquer le message directement en ligne de commande :

git commit -m "Message clair et concis de commit"

Et si les fichiers à commiter ont déjà été ajouté à git au moins une fois, vous pouvez faire :

git commit -am "Message clair et concis de commit"

...le -a va dire à Git : "Fais un git add sur tous les fichiers ajoutés/modifiés/supprimés que tu as déjà suivis au moins une fois".

Documentation pour la méthode commit [en].

Status

Pour voir les fichiers qui sont en attente d'être "guités", il faut faire :

git status

Cette commande va afficher :

• la branche sur laquelle vous êtes en train de travailler ;
• s'il y a eu des modifications dans les fichiers depuis le dernier commit : les fichiers modifiés, créés et/ou supprimés 
• s'il n'y a pas eu de modification : que la branche actuelle est propre.

Documentation pour la méthode status [en].

Log

La commande git log permet d'afficher la liste de tous les commits qui ont déjà été faits. Un log se divise en plusieurs parties :

• 1ère ligne = identifiant unique du commit et si c'est le dernier commit d'une branche, la branche en question
• 2ème ligne = l'auteur du commit Nom <email>
• 3ème ligne = la date
• Le reste = le message de commit

On peut aussi l'avoir en une seule ligne :

git log --oneline

...et si l'on souhaite une version stylisée avec des couleurs, il suffit de paramétrer Git avec cette ligne :

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

...et on utilise cet alias nouvellement créé pour faire le log stylisé est :

git lg

Documentation pour la méthode log [en].

Branch

Liste des branches

Pour visualiser toutes les branches qu'on a dans le dépôt :

git branch

Créer une nouvelle branche

Pour créer une nouvelle branche, on fait :

git branch nomDeLaNouvelleBranche

Si l'on souhaite créer et passer tout de suite à la nouvelle branche plutôt que de faire :

git branch nomDeLaNouvelleBranche
git switch nomDeLaNouvelleBranche

...on peut faire directement...

git checkout -b nomDeLaNouvelleBranche

...c'est équivalent, le checkout var créer la nouvelle branche et nous emmène sur la cette dernière. 

Supprimer une branche

Pour supprimer une branche, on fait :

git branch -d nomDeLaBranche

git branch -D nomDeLaBranche

Documentation pour la gestion des branches [en].

Checkout/switch

La commande :

git checkout nomDeLaBranche

...permet de passer dans une autre branche pour y travailler.

À partir de la version 2.23 de Git, on peut également utiliser :

git switch nomDeLaBranche

... la commande est similaire à git checkout sans être identique. Pour une introduction à Git la différence n'est pas indispensable, il est par contre conseillé de privilégier git switch qui a moins de responsabilité et donc moins de pouvoir que git checkout, cela limitera donc les erreurs par inadvertance.

Documentation vers la méthode checkout [en] et la documentation vers la méthode switch [en].

Merge

Quand on veut rassembler deux branches, parce qu'on a fini une feature (feature branch -> develop) ou si l'on veut passer une partie de l'application en production (develop -> master), on va faire un merge (fusion en français). C'est utilisé aussi si l'on veut rassembler deux branches de deux développeurs. Quand on bosse à plusieurs sur le même projet, chacun va travailler sur sa branche et quand chacun a terminé, il fera un merge dans develop. Git s'occupera de faire la différence entre les fichiers pour que toutes les modifications soient assemblées.

Pour faire un merge, il existe deux solutions.

Avec fusion des historiques

On se met dans la branche qui va recevoir l'autre et on fait un merge. Par exemple, si l'on veut récupérer tout le code de develop pour le mettre dans master, on fait :

git checkout master
git merge develop

... tous les commits qui étaient dans develop seront alors passés dans master. On fusionnera également les historiques et la différence entre master et develop seront alors gommées.

Avec historique parallèle

Quand on fait le merge, on peut dire à la branche qui réceptionne l'historique qu'elle se souvienne que les commits ont été faits dans une autre branche, même exemple que ci-dessus :

git checkout master
git merge --no-ff develop

...les historiques seront liés mais non fusionnés.

Documentation vers la méthode merge [en].

Rebase

La commande rebase va faire en sorte qu'une branche qui est en retard sur une a utre de se baser, non plus sur son propre historique, mais sur celui de l'autre branche. Quand je suis sur la branche en retard, je fais la commande :

git rebase nomDeLaBrancheEnAvance