Pro Git

1. Git est un système de gestion de versions distribué basé sur des instantanés.

Git considère ses données davantage comme une série d’instantanés d’un mini-système de fichiers.

Approche par instantanés. Contrairement aux systèmes plus anciens qui suivent les modifications sous forme de deltas, Git enregistre l’état complet de votre projet à chaque commit. Lorsque vous sauvegardez l’état de votre projet, Git prend une photo de tous vos fichiers à ce moment précis et stocke une référence à cet instantané. Cette différence fondamentale rend Git extrêmement rapide et efficace, notamment pour des opérations comme la création de branches ou la comparaison de versions.

Nature distribuée. Avec Git, les clients ne récupèrent pas seulement la dernière version, mais dupliquent l’intégralité de l’historique du dépôt. Chaque clone constitue donc une sauvegarde complète, et la plupart des opérations s’effectuent localement, sans nécessiter de connexion réseau. Ce modèle distribué offre plusieurs avantages majeurs :

• Le travail hors ligne est fluide.
• Les opérations telles que la consultation de l’historique ou la comparaison de versions sont quasi instantanées.
• La récupération après une panne du serveur est facilitée, car n’importe quel clone peut restaurer les données.

Conçu pour la rapidité et l’échelle. Git a été créé par Linus Torvalds pour gérer le noyau Linux, un projet immense et en évolution rapide. Sa conception privilégie la vitesse, la simplicité, un fort support du développement non linéaire (branches) et une gestion efficace des projets volumineux. Il convient ainsi à des projets de toutes tailles, des scripts personnels aux applications d’entreprise.

2. Maîtrisez les trois états fondamentaux : Modifié, Indexé et Validé.

Git distingue trois états principaux dans lesquels vos fichiers peuvent se trouver : modifié, indexé et validé.

Le flux de travail essentiel. Comprendre Git repose sur le cycle de vie de vos fichiers à travers ces trois états : Modifié (changements effectués mais non encore enregistrés dans Git), Indexé (changements sélectionnés pour le prochain commit), et Validé (changements enregistrés de façon sûre dans la base locale). Cela correspond à trois zones dans un projet Git : l’arbre de travail (vos fichiers), la zone d’indexation (l’index), et le répertoire Git (la base de données).

Le pouvoir de la zone d’indexation. La zone d’indexation est une fonctionnalité unique et puissante. Elle vous permet de choisir précisément quelles modifications de votre répertoire de travail seront incluses dans le prochain commit. Vous pouvez indexer des parties de fichiers ou des changements répartis sur plusieurs fichiers, créant ainsi des commits précis et cohérents. Ce contrôle granulaire aide à maintenir un historique clair et compréhensible.

Cycle de travail basique :

• Modifiez les fichiers dans l’arbre de travail.
• Indexez les changements souhaités avec git add.
• Validez les changements indexés avec git commit.
• Répétez.

Les fichiers peuvent être suivis (Git les connaît) ou non suivis (nouveaux fichiers non encore pris en compte). La commande git status est votre outil principal pour savoir dans quel état se trouvent vos fichiers.

3. Le système léger de branches de Git est une force majeure, permettant des flux de travail flexibles.

Une branche dans Git est simplement un pointeur léger et mobile vers un commit.

Les branches ne sont que des pointeurs. Contrairement à d’autres systèmes où la création de branches implique souvent la copie de fichiers, les branches Git sont extrêmement peu coûteuses. Créer une branche revient à créer un nouveau pointeur vers un commit existant. Changer de branche (git checkout ou git switch) est rapide car Git met à jour le pointeur HEAD et ajuste efficacement les fichiers de l’arbre de travail pour correspondre à l’instantané du commit ciblé.

Encourage la création fréquente de branches. Grâce à cette rapidité et simplicité, Git favorise des flux où les développeurs créent une branche pour chaque nouvelle fonctionnalité ou correction (branches thématiques). Cela isole le travail, facilite le changement de contexte et maintient la branche principale stable. Les branches peuvent être éphémères, fusionnées rapidement puis supprimées.

Avantages des branches :

• Isoler le développement nouveau du code stable.
• Expérimenter librement sans impacter le projet principal.
• Faciliter la revue de code en comparant des branches.
• Simplifier la collaboration sur des fonctionnalités spécifiques.

Le modèle de branches de Git est souvent considéré comme sa « fonctionnalité phare » grâce à sa rapidité et sa flexibilité, transformant profondément la gestion des développements parallèles.

4. Collaborez efficacement en gérant les dépôts distants et en partageant vos modifications.

Pour collaborer sur un projet Git, il est essentiel de savoir gérer vos dépôts distants.

Les dépôts distants sont des versions partagées. Un dépôt distant est une copie de votre projet hébergée ailleurs (internet, réseau). Il sert de point central pour la collaboration. Vous pouvez avoir plusieurs dépôts distants, chacun avec ses propres branches et tags. Cloner un dépôt configure automatiquement un dépôt distant par défaut nommé origin.

Récupération et intégration. Pour obtenir des données d’un dépôt distant, utilisez git fetch <remote>. Cette commande télécharge les données et met à jour les branches de suivi distant (comme origin/master) sans modifier votre travail local. git pull est un raccourci qui combine généralement git fetch suivi d’un git merge (ou git rebase si configuré), intégrant les changements distants dans votre branche courante.

Envoyer des modifications. Pour partager vos commits locaux, utilisez git push <remote> <branch>. Cela envoie votre branche et ses commits vers le dépôt distant spécifié. Vous devez avoir les droits d’écriture sur ce dépôt pour réussir. Si d’autres ont poussé des modifications depuis votre dernier pull, votre push peut être refusé, vous obligeant à récupérer et intégrer leurs changements d’abord.

5. Intégrez le travail via fusion ou rebasage, en comprenant leurs implications.

Dans Git, il existe deux principales façons d’intégrer des changements d’une branche à une autre : la fusion et le rebasage.

La fusion préserve l’historique. git merge intègre les changements d’une branche dans une autre en créant un nouveau commit de fusion. Ce commit a plusieurs parents, montrant explicitement où des lignes de développement divergentes ont été réunies. La fusion est généralement non destructive pour l’historique et constitue la méthode d’intégration par défaut. Les conflits sont signalés dans les fichiers pour une résolution manuelle.

Le rebasage réécrit l’historique. git rebase intègre les changements en déplaçant vos commits au sommet d’une autre branche. Il réapplique vos commits un par un sur la branche cible, créant de nouveaux objets commit avec des identifiants SHA-1 différents. Cela produit un historique plus linéaire et épuré, donnant l’impression que le travail s’est déroulé de manière séquentielle.

Différences clés :

• Fusion : crée un nouveau commit, préserve la structure originale de l’historique.
• Rebasage : réécrit les commits, crée un historique linéaire.

Prudence avec le rebasage. Ne rebasez jamais des commits déjà poussés sur un dépôt partagé et sur lesquels d’autres ont pu baser leur travail. Réécrire un historique partagé peut causer de graves problèmes aux collaborateurs, qui devront réintégrer les changements et risquent des doublons de commits.

6. Exploitez des outils puissants pour inspecter, rechercher et réécrire l’historique de votre projet.

Souvent, en travaillant avec Git, vous souhaiterez réviser l’historique local de vos commits.

Inspection de l’historique. git log est l’outil principal pour consulter l’historique des commits, avec de nombreuses options de formatage (--pretty), de filtrage (--author, --grep, -S) et de visualisation des branches (--graph). git show affiche les détails d’un commit ou objet spécifique. git diff compare les changements entre commits, la zone d’indexation et l’arbre de travail.

Recherche de contenu. git grep permet de chercher des chaînes ou motifs dans n’importe quelle version des fichiers du projet. git log -S (option « pioche ») trouve les commits ayant ajouté ou supprimé une chaîne spécifique. git log -L montre l’historique d’une fonction ou ligne de code précise.

Réécriture de l’historique. Git offre des outils pour modifier des commits passés avant de les partager. git commit --amend modifie le dernier commit. git rebase -i (rebasage interactif) permet de réordonner, éditer, fusionner ou supprimer des commits dans une série. git filter-branch (ou le plus récent git-filter-repo) peut réécrire de larges portions d’historique de manière scriptée, utile pour des tâches comme supprimer un fichier de tous les commits. Soyez prudent avec la réécriture d’historique partagé.

7. Personnalisez le comportement de Git avec des configurations et des hooks automatisés.

Comme beaucoup d’autres systèmes de gestion de versions, Git permet d’exécuter des scripts personnalisés lors d’actions importantes.

Niveaux de configuration. Les paramètres Git peuvent s’appliquer à trois niveaux : système (--system), utilisateur (--global) et dépôt (--local). Ces réglages contrôlent tout, de votre nom/email (user.name, user.email) et éditeur préféré (core.editor) à la gestion des espaces blancs (core.autocrlf, core.whitespace) et outils externes (merge.tool, diff.external).

Attributs Git. Les fichiers .gitattributes permettent des réglages spécifiques par chemin. Vous pouvez indiquer à Git comment gérer les fins de ligne (text), identifier les fichiers binaires (binary), utiliser des filtres de diff personnalisés (diff), ou même empêcher certains fichiers d’être archivés (export-ignore). Ces paramètres s’appliquent uniquement aux fichiers ou dossiers spécifiés.

Hooks automatisent les actions. Les hooks Git sont des scripts déclenchés par des événements précis. Les hooks côté client s’exécutent lors d’opérations locales (commit, fusion, rebasage), utiles pour imposer un format de message ou lancer des tests avant commit. Les hooks côté serveur s’activent lors d’opérations réseau (réception de push), idéaux pour appliquer des règles de projet comme le contrôle d’accès ou déclencher des builds d’intégration continue. Les hooks sont puissants mais doivent être distribués manuellement côté client.

8. La base d’objets Git est un système de fichiers adressable par contenu stockant blobs, arbres et commits.

Git est fondamentalement un système de fichiers adressable par contenu avec une interface utilisateur de gestion de versions construite par-dessus.

Structure de données centrale. Au cœur, Git est un simple magasin clé-valeur où le contenu est adressé par son hash SHA-1. Quatre types d’objets principaux existent :

• Blob : stocke le contenu d’un fichier.
• Tree : représente un instantané de répertoire, contenant des pointeurs vers des blobs et d’autres arbres, avec noms de fichiers et modes.
• Commit : pointe vers un arbre racine, ses commits parents, les informations d’auteur/commiteur et un message.
• Tag : pointe généralement vers un commit, avec informations sur le tagueur et un message (tags annotés).

Adressage par contenu. Lorsqu’un contenu est ajouté, Git calcule son hash SHA-1 et l’utilise comme clé pour stocker l’objet. Cela garantit l’intégrité des données ; toute modification change le hash. Les objets sont initialement stockés sous forme compressée dans .git/objects.

Graphe d’objets. Les commits forment un graphe orienté acyclique (DAG) via les pointeurs parents, représentant l’historique du projet. Les arbres et blobs forment les instantanés référencés par les commits. Comprendre cette structure sous-jacente éclaire de nombreuses opérations Git et permet des manipulations bas niveau avec des commandes « plomberie » comme git cat-file et git hash-object.

9. Les références (refs) fournissent des pointeurs lisibles vers des commits spécifiques.

Dans Git, ces noms simples s’appellent « références » ou « refs » ; vous trouverez les fichiers contenant ces valeurs SHA-1 dans le répertoire .git/refs.

Nommer les commits. Mémoriser des identifiants SHA-1 de 40 caractères est peu pratique. Les références offrent des noms conviviaux pour des commits précis. Ce sont des fichiers simples dans .git/refs contenant un SHA-1. Les types courants incluent les branches (refs/heads/), les tags (refs/tags/) et les branches de suivi distant (refs/remotes/).

Le pointeur HEAD. Le fichier HEAD est une référence spéciale, généralement un pointeur symbolique (ref:) vers la branche active. Lors d’un commit, Git crée un nouvel objet commit dont le parent est le commit pointé par HEAD, puis met à jour la référence HEAD vers ce nouveau commit. En état « HEAD détaché » (checkout d’un tag ou commit spécifique), HEAD contient directement un SHA-1.

Les refspecs définissent les correspondances. Les refspecs spécifient comment les références locales et distantes se correspondent, notamment lors des fetch et push. Leur format est [+]<src>:<dst>, mappant une référence source (<src>) vers une destination (<dst>). Cela permet un contrôle flexible des branches récupérées ou envoyées et de leur emplacement local ou distant.

10. La récupération des données est souvent possible même après des actions apparemment destructrices.

Si cela arrive, comment récupérer vos commits ?

Git ajoute des données. Presque toutes les opérations Git ajoutent des données à la base, rendant difficile la perte définitive d’un travail validé. Même des actions comme les resets durs ou la suppression forcée de branches ne suppriment pas immédiatement les objets commit sous-jacents. Elles suppriment seulement les références qui rendent ces commits facilement accessibles.

Le reflog conserve l’historique. Git maintient un « reflog » (.git/logs/) qui enregistre les déplacements récents de HEAD et des pointeurs de branches. Ce journal local suit les changements sur plusieurs mois. Vous pouvez utiliser git reflog ou git log -g pour consulter cet historique et retrouver le SHA-1 d’un commit apparemment perdu.

Trouver les objets orphelins. Si un commit n’est plus accessible par aucune référence (y compris le reflog), il devient un objet « orphelin ». git fsck --full peut analyser la base d’objets et lister ces objets orphelins, y compris les commits. Une fois le SHA-1 du commit perdu trouvé, vous pouvez le récupérer en créant une nouvelle branche ou un tag pointant dessus (git branch <nouvelle-branche> <sha-1>). Les objets non référencés pendant un certain temps sont finalement supprimés par la collecte des déchets (git gc).