Git avance - 08 - Glossaire

Tous les termes git avances : rebase, cherry-pick, reflog, stash, bisect, fast-forward et plus.

08 - Glossaire

Tous les termes utilises dans cette serie, expliques en quelques lignes. Quand un terme a un article dédié, le lien est indique.


B

Bisect

Recherche binaire dans l'historique git pour trouver le commit qui a introduit un bug. git bisect start, puis tu marques des commits "good" ou "bad" et git coupe en deux a chaque étape. Automatisable avec git bisect run. Voir l'article 04.

Branch (branche)

Une référencé mobile vers un commit. Quand tu fais un commit sur une branche, la référencé avance automatiquement. Creer une branche est quasi instantane dans git (c'est juste un pointeur, pas une copie de fichiers). Voir l'article 01 pour les stratégies de branching.

C

Cherry-pick

Copier un commit spécifique d'une branche vers une autre. git cherry-pick <hash> créé un nouveau commit avec le meme contenu mais un hash différent. Utile pour les hotfixes. Voir l'article 04.

Commit

Un snapshot de ton code a un instant T. Contient un hash (SHA-1), un auteur, une date, un message, et un pointeur vers le commit parent. Les commits forment un graphe oriente acyclique (DAG).

Conflit (conflict)

Situation ou git ne peut pas fusionner automatiquement deux modifications qui touchent la meme zone d'un fichier. Les marqueurs <<<<<<<, =======, >>>>>>> indiquent les zones en conflit. Voir l'article 05.

Conventional Commit

Convention de nommage pour les messages de commit. Format : type(scope): description. Les types courants : feat, fix, chore, docs, refactor, test. Permet la génération automatique de changelogs. Voir l'article 03.

D

Detached HEAD

État ou HEAD pointe directement sur un commit au lieu d'une branche. Ca arrive quand tu fais git checkout <hash> ou pendant un bisect. Les commits faits en detached HEAD ne sont rattaches a aucune branche. Si tu quittes sans créer de branche, ils deviennent orphelins (mais restent dans le reflog pendant 90 jours).

F

Fast-forward

Type de merge ou la branche cible n'a pas diverge. Git avance simplement le pointeur de branche sans créer de merge commit. C'est le cas quand ta branche est lineairement en avance sur main. git merge --ff-only refuse le merge si un fast-forward n'est pas possible.

Fetch

Telecharge les commits et références depuis le remote sans modifier ta branche locale. git fetch origin met à jour origin/main mais ne touche pas a ton main local. C'est la première moitie de git pull (qui fait fetch + merge ou fetch + rebase).

Force push

git push --force ecrase l'historique du remote avec ton historique local. Dangereux si d'autres personnes travaillent sur la meme branche. Prefere git push --force-with-lease qui refuse le push si le remote a change depuis ton dernier fetch.

H

Référence speciale qui pointe vers le commit actuellement checkoute. En général, HEAD pointe vers une branche (qui elle-meme pointe vers un commit). HEAD~1 est le commit parent, HEAD~3 est trois commits en arriere.

Hook

Script qui se lance automatiquement a un moment precis du workflow git. Les hooks vivent dans .git/hooks/. Les plus utiles : pre-commit, commit-msg, pre-push. Voir l'article 06.

Husky

Outil npm pour versionner les git hooks dans un dossier .husky/. Resout le problème que .git/hooks/ n'est pas suivi par git. Alternative : lefthook (écrit en Go). Voir l'article 06.

I

Interactive rebase (rebase interactif)

git rebase -i HEAD~N ouvre un éditeur qui te permet de modifier les N derniers commits : squash, reword, fixup, drop, reorder. L'outil principal pour nettoyer l'historique avant une merge request. Voir l'article 02.

L

lint-staged

Outil npm qui lance des commandes (lint, format) uniquement sur les fichiers stages dans git. Evite de checker tout le projet a chaque commit. Se combine avec Husky ou lefthook. Voir l'article 06.

M

Merge

Fusionner deux branches en creant un commit de merge avec deux parents. Preserve la topologie des branches dans l'historique. A comparer avec rebase. Voir l'article 02.

Merge commit

Commit avec deux parents, créé par git merge. Represente le point de jonction de deux branches. Contient la résolution de tous les conflits eventuels.

O

Origin

Nom par défaut du remote principal. Quand tu fais git clone, le repo source s'appelle origin. origin/main est la version de main sur le remote. Tu peux avoir plusieurs remotes (origin, upstream, etc.).

P

Pull

git pull = git fetch + git merge (par défaut). Recupere les changements du remote et les intégré dans ta branche locale. git pull --rebase fait fetch + rebase a la place, ce qui évité les merge commits parasites. Configurable par défaut avec git config pull.rebase true.

Push

Envoie tes commits locaux vers le remote. git push -u origin feat/search push la branche et configure le tracking. Refuse si le remote a des commits que tu n'as pas (sauf avec --force).

R

Rebase

Rejouer les commits d'une branche sur la pointe d'une autre. Reecrit l'historique (les commits obtiennent de nouveaux hash). Produit un historique lineaire. Regle d'or : ne jamais rebase une branche partagee. Voir l'article 02.

Reflog

Journal local de tous les mouvements de HEAD. git reflog montre l'historique des opérations (commits, checkouts, rebases, resets). Les entrees expirent apres 90 jours. C'est le filet de sécurité ultime pour récupérer du travail "perdu". Voir l'article 07.

Remote

Un dépôt git distant (GitLab, GitHub, un serveur). La plupart des projets ont un seul remote nomme origin. Les commandes fetch, pull, push communiquent avec le remote.

Rerere

"REuse REcorded REsolution". Fonctionnalite git qui memorise comment tu as résolu un conflit et applique la meme résolution automatiquement si le conflit reapparait. Active avec git config --global rerere.enabled true. Voir l'article 05.

Reset

git reset deplace HEAD (et potentiellement la branche) vers un autre commit. Trois modes : --soft (garde les modifs en staging), --mixed (garde les modifs dans le working directory, défaut), --hard (supprime les modifs). --hard est destructif localement mais le reflog permet de revenir en arriere.

S

Squash

Fusionner plusieurs commits en un seul. Se fait via rebase interactif (squash ou fixup). Utile pour nettoyer une branche avant de merger : les "fix typo" et "wip" disparaissent. GitLab propose aussi un "Squash and merge" dans les merge requests.

Stash

Mettre de cote du travail en cours sans commiter. git stash sauvegarde les modifications et nettoie le working directory. git stash pop les restaure. Nomme tes stashs avec git stash push -m "description". Voir l'article 04.

T

Tag

Référence fixe vers un commit. Contrairement a une branche, un tag ne bouge pas. Utilise pour marquer les versions (v1.0.0, v2.3.1). Deux types : lightweight (juste un pointeur) et annotated (contient un message, un auteur, une date). git tag -a v1.0.0 -m "First release".


Article précédent : 07 - Reflog et recovery

C'est le dernier article de la serie. Si tu as suivi depuis l'introduction, tu as maintenant les outils pour travailler avec git sans stress. Le reste, c'est de la pratique.

Sources

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.