Apprenez à utiliser Git : les bases pour suivre l'évolution d'un document

Tout d'abord, il faut installer Git. Sous Linux ou dans le sous-système Linux de Windows (WSL), il est le plus souvent présent. Sous macOS ou Windows, il faudra le télécharger et l'installer. La plupart des gestionnaires de paquets l'ont dans leurs dépôts de base. C'est notamment le cas des plus populaires comme Brew, Chocolatey ou winget. 

• Télécharger Git

Pendant une installation classique sous Windows, plusieurs questions vous seront posées. Vous pouvez laisser les paramètres par défaut, mais certains sont utiles à activer comme la vérification de nouvelle version et la modification de l'éditeur utilisé, tel qu'Atom, Notepad++ ou Visual Studio Code. 

Une documentation complète est disponible en français, ainsi que d'autres ressources pouvant être utiles comme une cheat sheet listant les principales commandes ou des vidéos (en anglais) pour comprendre les bases. Une liste des principaux clients en interface graphique (GUI), gratuits/open source ou non, est aussi proposée par ici.

Une fois l'installation terminée, ouvrez un terminal et créez un dossier à l'emplacement de votre choix. Placez-vous à sa racine. Nous allons l'initialiser pour en faire ce que l'on nomme un dépôt Git (repository) local, qui sera utilisé comme tel et où aura lieu le suivi des versions. Pour cela, une simple commande suffit : 

git init

Pour vérifier que tout fonctionne, tapez la commande suivante :

git status

Si tout se passe bien vous devriez obtenir le message suivant : 

On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Pour faire simple, Git indique que vous êtes sur la branche principale (master), en attente de modifications.

Création d'un fichier et ajout à l'index

Nous allons créer un premier fichier et l'ouvrir avec un éditeur gérant nativement Git, Visual Studio Code dans notre cas. Le fonctionnement sera similaire dans les autres.

code .

Cette commande lance Visual Studio Code dans le dossier courant. Nous créons un fichier nommé README.md via l'interface. Nous y écrivons une simple ligne de texte sous forme d'un titre au format Markdown : 

# Hello, world !

Une fois le fichier enregistré (CTRL+S), tapez à nouveau git status dans votre terminal. Cette fois, vous obtiendrez un message différent vous indiquant que le fichier README.MD est untracked. Comprendre qu'il existe, mais qu'il n'a pas été demandé à Git de le suivre. Cela se fait en une commande :

git add README.MD

Notez que cette étape est « 2-en-1 » puisqu'elle ajoute le fichier à l'index, en attente de validation (staged). Par la suite, il pourra avoir deux autres états et être considéré comme modifié ou non. Pour qu'un fichier ne soit plus suivi, il faudra le demander explicitement (remove), mais ce ne sera pas nécessaire en général.

Vérifiez à nouveau le statut de votre dépôt (git status). Cette fois le fichier sera bien affiché en vert avec un message indiquant qu'il contient des modifications devant être validées, une étape que l'on nomme commit. Vous avez alors deux possibilités : effectuer votre commit depuis le terminal ou l'interface graphique de votre éditeur.

Notez que la première fois, il vous sera parfois demandé de configurer des identifiants. En effet, chaque commit est unique, associé à une empreinte (hash) et à un nom/pseudo et un email. Si Git trouve ces informations dans votre compte utilisateur il va les utiliser. Mais vous pouvez aussi les préciser :

git config --global user.email "votre@email.com"
git config --global user.name "votre nom ou pseudo"

Ces commandes effectuent une modification globale, considérée comme identique au sein de la machine. Vous pouvez retirer cet argument pour qu'elle soit limitée au compte utilisateur actuel.

Attention, si vous partagez votre code sur des plateformes en ligne, ces informations seront publiques. Veillez donc à utiliser des éléments diffusables à tous. Notez que certains services utilisent un email sur leur domaine faisant office de filtre. Cela peut être une solution. À vous de voir ce qui vous convient le mieux.

Revenons à notre commit tel qu'il doit être formulé en ligne de commandes :

git commit -m "Ceci est un premier essai"

L'argument « -m » permet d'ajouter une description. Elle n'est pas nécessaire, mais c'est une habitude à prendre car elle peut s'avérer utile pour assurer un bon suivi des modifications sur le long terme. Dans un client graphique, la procédure est similaire : dans la zone de l'interface dédiée à la gestion des versions, on voit la liste des fichiers en attente avec la possibilité d'ajouter une description puis d'effectuer le commit.

Vous pouvez voir la modification effectuée avec diverses commandes comme git log ou git show qui sera plus complète. git log --oneline affiche à l'inverse une version plus courte, notamment de l'empreinte. Cette dernière pourra être utile dans certains cas, comme pour revenir en arrière ou analyser un commit particulier.

Si vous avez un doute sur le fonctionnement d'une commande, il suffit d'ajouter l'argument --help à la fin de celle-ci pour obtenir son aide détaillée, en ligne ou dans le terminal selon les cas. Par exemple :

git commit --help

Nouvelle modification, validée en une commande

Effectuons une nouvelle modification à notre fichier en remplaçant son contenu par le suivant :

# Titre 1

## Sous-titre 1

Ceci est un simple texte

# Titre 2

Ceci est un autre texte, mais cette fois on ajoute une citation :

> Cogito ergo sum

On sauvegarde le fichier. L'interface de votre éditeur de texte doit normalement vous signaler que des modifications ont été détectées et vous permettre de les visualiser. Une commande existe aussi pour cela :

git diff

Les ajouts sont indiqués en vert avec un « + », les suppressions en rouge avec un « - ». Cette fois, nous allons effectuer l'ajout du fichier à l'index et la validation des modifications en une seule commande :

git commit -a -m "Ajout de texte et d'une citation"

Ici, le « -a » (ou --all) indique que tous les fichiers modifiés doivent être staged, en attente d'un commit.

Branches et fusion : des modifications plus sereines

Imaginez maintenant que vous souhaitiez effectuer des modifications à votre texte, mais sans prendre le risque de perdre le travail que vous avez effectué jusque-là si vous décidez de revenir en arrière.

Pour cela, les outils de gestion de versions (dont Git) disposent d'un principe : les branches. Comme nous l'avons évoqué plus haut, vous êtes par défaut sur la branche master. Imaginons maintenant que vous ajoutiez des listes à votre texte pour voir le résultat sans prendre de risque. L'une des solutions est de créer une branche « Liste », d'y faire vos modifications, puis de les valider dans votre branche master si le résultat vous convient.

Cette solution est couramment utilisée dans le développement logiciel pour travailler sur l'ajout d'une fonctionnalité spécifique, notamment lorsque l'on intervient à plusieurs sur un même code. Des fonctionnalités multiples peuvent ainsi être préparées dans différentes branches avant que l'on ne les réconcilie par la suite.

Ce workflow est souvent représenté sous forme d'un graphique (voir ci-dessous). Pour la réconciliation, deux approches s'opposent : la fusion (merge) et rebase. Nous n'étudierons ici que la première, la seconde consistant à réécrire l'historique des commits selon l'évolution de la branche. Chacune a ses avantages et inconvénients.

Il est surtout important d'utiliser celle qui vous conviendra le mieux selon vos projets et besoins, et de vous adapter aux pratiques des projets tiers sur lesquels vous aurez à travailler. Même si certains en sont persuadés, retenez qu'aucune approche n'est meilleure. Il s'agit de gestions différentes de l'historique d'un projet.

Si le sujet vous intéresse, vous pouvez lire ce guide de la documentation d'Atlassian BitBucket.

L'évolution des commits suite à l'ajout de fonctionnalités dans une branche puis une fusion (merge)

Pour comprendre comment fonctionnent les branches, nous allons en créer une, puis y effectuer une modification et la fusionner avec le texte de départ. Commençons par la création :

git branch Liste

On demande à Git de nous passer sur la branche Liste :

git switch Liste

Dans notre éditeur, on ajoute le texte suivant, on enregistre la modification et on commit :

# Différents types de listes

## Liste des jours

* Lundi
* Mardi
* Mercredi
* Jeudi 
* Vendredi
* Samedi
* Dimanche

## Liste des mois

1. Janvier
2. Février
3. Mars
4. Avril
5. Mai
6. Juin
7. Juillet
8. Août
9. Septembre
10. Octobre
11. Novembre
12. Décembre

On se retrouve alors avec une branche master qui contient le texte de départ et une branche Liste contenant un commit et donc une version différente du texte. Notez que passer d'une branche à l'autre modifie les fichiers accessibles localement, donc ce qui est affiché dans l'éditeur. C'est l'un des avantages de cette méthode.

On peut visualiser le tout sous la forme d'un petit graphique avec des outils spécifiques. Il existe toutefois une commande pour obtenir un résultat visuel similaire depuis le terminal :

git log --oneline --graph --all

Passons à la fusion (merge). Il faut retourner dans la branche master et fusionner les branches. Cela consiste à créer un commit répercutant les différences constatées entre la branche courante et celle à fusionner. Vous pouvez le faire pour plusieurs branches à la fois, mais c'est déconseillé. En effet, il faudrait en passer par une procédure de résolution de conflits depuis l'éditeur, ce que l'on cherche à éviter.

Voici la procédure à suivre :

git switch master
git merge Liste

Une fois la procédure terminée, le texte devrait intégrer le contenu de base, les listes et le code. Vous pouvez visualiser à nouveau l'historique de votre dépôt sous forme de graphique. Le résultat est assez simple puisqu'il n'y avait qu'un commit, sans modifications dans la branche principale. 

Git a donc utilisé une procédure dite Fast-forward, avec le résultat suivant :

Dans la suite de ce dossier, nous étudierons le travail à plusieurs sur un même document, notamment à travers un dépôt distant (remote) et des services d'hébergement Git comme GitLab ou GitHub.