Tags et releases
Un tag est une reference nommee vers un commit specifique. Alors que les branches avancent au fur et a mesure que vous ajoutez des commits, les tags restent fixes. C'est la methode standard pour marquer les points de release dans l'historique de votre projet.
git tag — Marquer les commits importants
Git prend en charge deux types de tags. Un tag leger est simplement un pointeur vers un commit — considerez-le comme une branche qui ne bouge jamais. Un tag annote (git tag -a) est un objet Git complet avec le nom du tagueur, son email, la date et un message. Les tags annotes sont recommandes pour les releases car ils contiennent des metadonnees et peuvent etre signes cryptographiquement.
Les tags ne sont pas pousses par defaut — vous devez utiliser git push origin --tags pour les partager avec le depot distant. Pour supprimer un tag distant, utilisez git push origin :refs/tags/v1.0.0.
Versionnage semantique
La plupart des projets open-source suivent le Versionnage Semantique (SemVer) pour leurs tags : vMAJEUR.MINEUR.PATCH. Incrementez MAJEUR pour les changements incompatibles, MINEUR pour les nouvelles fonctionnalites retrocompatibles, et PATCH pour les corrections de bugs. Par exemple, passer de v1.2.3 a v1.3.0 signale une nouvelle fonctionnalite sans changement incompatible.
Reference rapide : v1.0.0 = premiere release stable. v0.x.y = tout peut changer. Prefixez le tag avec v par convention (par ex., v2.1.0).
Configuration Git
Le comportement de Git est controle par des fichiers de configuration a trois niveaux. Comprendre comment ils se superposent est la cle d'un workflow confortable et personnalise.
git config — Parametres locaux, globaux et systeme
Git lit la configuration depuis trois portees, chacune ecrasant la precedente : systeme (/etc/gitconfig, s'applique a tous les utilisateurs), global (~/.gitconfig, vos parametres utilisateur), et local (.git/config, par depot). Utilisez --global pour votre identite et vos preferences, et aucun drapeau (ou --local) lorsqu'un seul projet necessite des parametres differents.
Alias utiles
Les alias vous permettent de creer des raccourcis pour les commandes que vous tapez souvent. Ils sont stockes dans votre fichier ~/.gitconfig et peuvent vous faire gagner un temps considerable au cours de la journee. Voici quelques alias populaires pour demarrer.
Astuce : Vous pouvez egalement definir des alias qui executent des commandes shell en les prefixant avec !. Par exemple : git config --global alias.undo '!git reset --soft HEAD~1'.
Partager des patches
Avant l'existence des pull requests GitHub, les developpeurs partageaient leurs modifications via des fichiers patch envoyes par email. Ce workflow est encore largement utilise dans des projets comme le noyau Linux, et il reste une competence utile lorsque vous devez partager des modifications en dehors d'une plateforme hebergee.
git format-patch — Creer des fichiers patch
git format-patch transforme des commits en fichiers .patch contenant le diff ainsi que le message de commit, l'auteur et la date. Chaque commit devient son propre fichier numerote, pret a etre envoye par email ou partage dans un ticket.
git apply — Appliquer des fichiers patch
git apply prend un fichier patch et applique les modifications a votre arbre de travail sans creer de commit. Si vous souhaitez conserver les metadonnees du commit original (auteur, message), utilisez git am a la place, qui applique le patch et cree un commit en une seule etape.
Travailler avec plusieurs copies
Parfois, vous devez travailler sur deux branches en meme temps — par exemple, appliquer un correctif urgent pendant qu'une fonctionnalite est en cours de developpement. Au lieu de stasher et changer de branche, Git vous permet de maintenir plusieurs repertoires de travail a partir d'un seul depot.
git worktree — Plusieurs repertoires de travail
git worktree add cree un nouveau repertoire de travail lie au meme depot. Chaque worktree extrait une branche differente, et tous partagent les memes donnees .git. Cela signifie pas de clone supplementaire, pas d'espace disque en plus pour l'historique, et aucun risque de perdre du travail non commite lors d'un changement de contexte.
Empaqueter votre code
Besoin d'envoyer un instantane de votre projet a quelqu'un qui n'utilise pas Git, ou de produire un artefact de release pour le deploiement ? git archive est fait pour cela.
git archive — Exporter une archive propre
git archive exporte le contenu d'un arbre (un commit, une branche ou un tag) sous forme de fichier .zip ou .tar.gz. Contrairement a un simple zip du dossier, git archive exclut le repertoire .git et respecte les regles .gitattributes export-ignore. C'est la maniere la plus propre de produire un instantane distribuable.
Git hooks
Les hooks sont des scripts que Git execute automatiquement a des moments cles de votre workflow. Ils vous permettent d'imposer des standards de code, d'executer des tests, de valider les messages de commit, ou d'empecher les push vers des branches protegees — le tout sans dependre de la discipline humaine.
Les hooks les plus couramment utilises sont :
pre-commit— s'execute avant la creation d'un commit. Utilisez-le pour linter le code, executer des formateurs, ou verifier la presence de secrets.commit-msg— s'execute apres la redaction du message. Utilisez-le pour imposer un format comme Conventional Commits.pre-push— s'execute avant le push. Utilisez-le pour lancer la suite de tests et bloquer les push si les tests echouent.
Partage en equipe : Les hooks dans .git/hooks/ ne sont pas versionnes. Pour les partager, placez vos scripts dans un dossier suivi (par ex. .githooks/) et executez git config core.hooksPath .githooks. Des outils comme Husky ou pre-commit automatisent cela pour vous.
Git submodules
Un submodule integre un depot Git a l'interieur d'un autre. Le depot parent enregistre quel commit du submodule extraire, ce qui vous permet d'epingler des versions exactes de bibliotheques ou composants partages. C'est la reponse native de Git aux "depots a l'interieur de depots".
Les submodules sont puissants mais ont une courbe d'apprentissage. Lorsque vous clonez un projet qui contient des submodules, n'oubliez pas de les initialiser et de les mettre a jour. Lorsque vous mettez a jour un submodule, vous commitez la nouvelle reference dans le depot parent.
Alternatives : Si les submodules vous semblent trop complexes, envisagez git subtree (fusionne le code externe directement dans votre arbre) ou un gestionnaire de paquets specifique au langage pour les dependances tierces.
Avec les tags, hooks, worktrees, patches, archives et submodules dans votre boite a outils, vous etes equipe pour pratiquement n'importe quel workflow Git. La meilleure facon d'interioriser ces commandes est de les pratiquer dans un vrai projet — commencez petit et progressez.