Les worktrees Git, introduits en 2015 mais popularisés récemment, permettent de gérer plusieurs branches simultanément sans basculer entre elles ni utiliser de stash. Contrairement aux branches classiques, ils créent des dossiers séparés pour chaque branche, évitant ainsi les conflits de contexte et les réinstallations de dépendances lors des changements de tâche. Par exemple, un développeur peut corriger un bug urgent dans un dossier dédié tout en laissant son environnement de travail principal intact.

Cette approche réduit la charge mentale liée au passage d’une tâche à l’autre, notamment avec l’essor des outils modernes comme GitHub Copilot, qui encouragent le travail parallèle. Les worktrees sont désormais mieux supportés par les environnements de développement, comme VS Code, et offrent une alternative plus fluide aux méthodes traditionnelles de gestion de branches.

Cependant, leur adoption reste limitée par un manque de visibilité historique et une intégration parfois imparfaite dans certains outils. Malgré cela, ils s’imposent comme une solution efficace pour les développeurs manipulant plusieurs contextes simultanément.

Git propose plusieurs méthodes pour ignorer des fichiers, au-delà du traditionnel fichier .gitignore. L’auteur explique qu’il existe trois niveaux d’ignorance : le fichier .gitignore classique (partagé avec le dépôt), le fichier .git/info/exclude (local au dépôt mais non versionné) et le fichier global ~/.config/git/ignore (valable pour toutes les instances Git de la machine). Ce dernier est utile pour des motifs comme .DS_Store sur macOS, tandis que .git/info/exclude permet d’exclure des fichiers propres à un dépôt sans les commiter.

L’article détaille aussi comment personnaliser le fichier d’ignorance global via git config --global core.excludesFile, et comment vérifier quel fichier est à l’origine de l’ignorance d’un fichier avec la commande git check-ignore -v. Cette commande affiche le chemin et la ligne du fichier responsable, utile pour le débogage.

Enfin, l’auteur mentionne que ce sujet a suscité l’intérêt sur Hacker News, et propose d’autres articles liés à Git, comme le clonage de branches spécifiques ou l’extraction de versions de paquets Homebrew.

L’article explique comment organiser ses worktrees Git avec Antigravity 2.0, une fonctionnalité permettant de gérer plusieurs branches simultanément dans des répertoires distincts sans conflit. Les worktrees, introduits par Git en 2015, offrent une alternative aux git stash en isolant les modifications dans des copies liées au dépôt principal. L’auteur illustre leur utilisation via des commandes comme git worktree add et souligne leur utilité pour paralléliser les développements, notamment avec des agents IA.

Antigravity 2.0 intègre cette approche en créant des worktrees dédiés pour les modifications générées par des agents, évitant ainsi les conflits lors de contributions multiples. Les worktrees sont accessibles graphiquement dans l’IDE Antigravity, simplifiant leur gestion. Cette fonctionnalité accélère les workflows en permettant une orchestration parallèle des tâches, tout en maintenant une séparation claire entre les branches.

Enfin, l’auteur propose un skill personnalisé pour automatiser la suppression des worktrees après validation, évitant l’accumulation de copies inutiles. Bien qu’Antigravity gère les commits et pushes, il recommande de nettoyer manuellement les worktrees pour conserver un environnement organisé, reflétant une pratique rigoureuse de gestion de code.

L'auteur critique le format Conventional Commits, un standard populaire pour structurer les messages de commit Git, qu'il juge inefficace et contre-productif. Selon lui, ce format met l'accent sur le type de commit (comme fix ou feat) au détriment du scope (la partie du code concernée), alors que ce dernier est bien plus utile pour les développeurs, les débogueurs ou les équipes en réponse aux incidents. Le scope permet de localiser rapidement les changements pertinents dans l'historique, contrairement au type, souvent redondant ou trop restrictif.

L'article souligne que le scope devrait être obligatoire et placé en tête du message, car il répond aux besoins concrets des contributeurs, des débogueurs et des équipes de maintenance. À l'inverse, le type est jugé superflu, car le libellé du commit suffit généralement à en déduire la nature. L'auteur dénonce ainsi une priorisation inversée dans le standard, qui complique plutôt que simplifie la compréhension de l'historique des modifications.

Cette formation en ligne, intitulée Git par la pratique, s’adresse aux développeurs et administrateurs souhaitant maîtriser Git, un outil essentiel pour la gestion de versions. L’approche adoptée est résolument pratique, privilégiant l’apprentissage par la manipulation directe plutôt que la théorie, avec des ateliers conçus pour une installation minimale de Debian Linux.

Les prérequis sont modestes : une familiarité avec le shell Linux, les commandes de base et un éditeur de texte comme Vim ou Nano. Bien que des adaptations existent pour Windows et macOS, la formation recommande de commencer sous Linux pour éviter les complexités liées aux environnements propriétaires.

L’objectif principal est de permettre une gestion efficace de projets informatiques collaboratifs, en assurant un suivi des modifications, une coordination entre développeurs et une stabilité du code. Les concepts clés, comme les branches, les conflits ou les pull requests, sont abordés de manière progressive pour éviter les erreurs courantes.

Jujutsu (jj) est présenté comme une alternative moderne à Git, conçue pour simplifier la gestion des commits, des branches et des opérations complexes comme le rebase. L’outil se distingue par sa capacité à fonctionner en parallèle de Git, permettant aux développeurs de l’adopter sans impacter leur équipe. L’auteur partage son expérience de présentation à Devoxx France, illustrant les fonctionnalités clés de jj à travers des démos pratiques.

Le clonage d’un dépôt avec jj est détaillé, montrant comment initialiser un projet en mode "colocated" pour combiner les avantages des deux systèmes. Les revsets, équivalents des commits Git, sont mis en avant avec une visualisation claire de l’historique, incluant identifiants, auteurs, dates et messages. L’outil introduit aussi des concepts comme les bookmarks (remplaçant les branches) et l’operation log pour suivre les modifications.

Enfin, l’article aborde des fonctionnalités avancées comme l’absorption automatique des changements (absorb), le rebase simplifié et la gestion des conflits, tout en proposant des astuces de configuration pour optimiser l’expérience utilisateur. Des ressources complémentaires sont suggérées pour approfondir l’apprentissage.

Gérer plusieurs versions d’un projet avec Git peut devenir complexe, surtout quand il faut jongler entre branches ou modifier des fichiers de configuration exclus du suivi. La solution classique (cloner plusieurs fois le dépôt) est peu pratique et gourmande en espace. Cet article explique comment utiliser les arbres de travail (worktrees) pour travailler sur plusieurs branches simultanément à partir d’un seul clone, évitant ainsi la duplication des dépôts. Une méthode efficace pour simplifier le workflow Git, avec des astuces pour basculer facilement entre les dossiers.

GitButler est un outil de gestion de modifications Git optimisé pour les workflows de développement modernes, notamment avec l'IA. Il permet de travailler sur plusieurs branches en parallèle ou empilées, offre un "undo" illimité, des intégrations d'agents IA pour automatiser les commits/PR, et une édition simplifiée des commits. Disponible en version desktop (Linux) et CLI, il se distingue par son interface intuitive et ses fonctionnalités collaboratives (intégration GitHub/GitLab, orchestration d'agents IA comme Claude). Les retours utilisateurs soulignent son efficacité pour éviter les maux de tête liés aux branches et aux workflows complexes.

Dolt est un système de gestion de base de données SQL qui intègre des fonctionnalités de contrôle de version similaires à Git. Il permet de fork, cloner, brancher, fusionner, pousser et tirer des bases de données comme des dépôts Git. Compatible avec MySQL, Dolt expose ses fonctionnalités via des tables, fonctions et procédures SQL. Il propose également une interface en ligne de commande similaire à Git pour importer des fichiers CSV, committer des modifications, les pousser vers un dépôt distant, ou fusionner les changements de collaborateurs. DoltHub est une plateforme pour partager des bases de données Dolt, avec des options d'auto-hébergement via DoltLab ou d'hébergement externe. Une version compatible PostgreSQL, Doltgres, est également disponible en version bêta.

Découvrez git-cliff, un générateur de changelog hautement personnalisable qui suit les spécifications des commits conventionnels. Cet outil open-source permet de créer des fichiers de changelog à partir de l'historique Git en utilisant des commits conventionnels et des analyseurs personnalisés basés sur des expressions régulières. La configuration du modèle de changelog est flexible et peut être adaptée selon les besoins. La documentation officielle fournit des instructions détaillées pour l'installation, l'utilisation et la configuration.

Andrew Nesbitt explique dans cet article les fichiers spéciaux que Git recherche dans les dépôts pour contrôler son comportement. Ces fichiers, comme .gitignore, .gitattributes, .lfsconfig et .gitmodules, sont commis avec le code et influencent la manière dont Git traite les fichiers. Par exemple, .gitignore définit les fichiers à ignorer, .gitattributes configure le traitement des fichiers spécifiques, .lfsconfig gère les paramètres de Git LFS, et .gitmodules configure les sous-modules. Ces fichiers sont essentiels pour les outils travaillant avec les dépôts Git.

Un article partageant un astuce Git issue des documents internes de la CIA, divulgués par WikiLeaks en 2017. La commande permet de supprimer en une seule ligne toutes les branches déjà fusionnées, sauf la branche courante et les branches principales comme "main" ou "develop". L'auteur propose également de créer un alias pour simplifier l'utilisation de cette commande. Une astuce utile pour garder son dépôt Git organisé.

Ploum explique comment utiliser git send-email pour contribuer à des projets GitHub sans passer par l'interface web, en travaillant hors ligne et avec plusieurs comptes email. Il décrit la configuration de msmtp pour gérer plusieurs comptes email et comment intégrer cela avec Git pour envoyer des patches par email. Il recommande d'utiliser une adresse email spécifique par projet pour mieux gérer le spam. Le processus implique de configurer les adresses email dans chaque dépôt Git et de corriger les erreurs de configuration avec git commit --amend --reset-author.

Ce billet explore des techniques Git avancées pour optimiser votre workflow de développement. Il met en lumière l'importance de maintenir un historique Git logique et cohérent, en utilisant des outils comme git rebase -i pour réécrire l'histoire avant de partager vos commits. Il aborde également l'utilisation efficace du staging area avec git add -p pour créer des commits atomiques, et le workflow "fixup" pour corriger des erreurs sans encombrer l'historique. Enfin, il souligne l'importance de travailler avec des branches éphémères et de les rebaser régulièrement pour éviter les conflits et maintenir un historique propre.

L'article "Two regimes of Git" de Mark Seemann explore deux modes d'utilisation distincts de Git : le régime de collaboration et le régime tactique. En collaboration, Git est utilisé pour partager et maintenir un code base avec d'autres, où l'historique partagé est considéré comme immuable pour éviter la confusion. Les actions comme rebase ou squash sont évitées une fois l'historique partagé. En revanche, le régime tactique utilise Git localement pour gérer et expérimenter avec le code, permettant des manipulations plus libres de l'historique. L'auteur souligne l'importance de comprendre ces deux régimes pour éviter les malentendus lors des discussions sur Git.

Abhinav Sarkar partage son expérience avec Jujutsu (JJ), un nouveau système de contrôle de version qu'il utilise depuis trois mois pour ses projets personnels. Dans ce billet, il détaille les commandes JJ qu'il utilise le plus fréquemment, en assumant que le lecteur connaît déjà Git. Il explique comment démarrer avec JJ, créer et modifier des changements, visualiser les modifications, gérer les branches, et interagir avec Git. Sarkar souligne que JJ utilise Git comme backend, permettant ainsi une utilisation transparente de Git dans les dépôts partagés. Il conclut en mentionnant que l'utilisation de JJ ne nécessite pas de maîtriser toutes ses fonctionnalités avancées pour en tirer profit.

L'article explore les limites des hooks de pré-commit dans Git, en illustrant les problèmes à travers un projet Rust simple. L'auteur montre que les hooks de pré-commit, qui vérifient le formatage du code avant un commit, ne fonctionnent pas comme prévu car ils s'exécutent sur l'arborescence de travail et non sur l'index. Même en améliorant le script pour vérifier les fichiers dans l'index, l'auteur rencontre des difficultés lorsque le dépôt contient déjà du code mal formaté. L'article met en lumière les défis de l'utilisation des hooks de pré-commit pour maintenir un style de code cohérent.

Gitmoji est un guide d'emojis pour vos messages de commit. Il propose une liste d'emojis associés à des actions spécifiques dans le développement de logiciels, comme l'amélioration du code, la correction de bugs, l'ajout de documentation, le déploiement, et bien plus encore. Chaque emoji est accompagné d'une brève description de son utilisation, facilitant ainsi la standardisation et la compréhension des messages de commit au sein d'une équipe. Un outil pratique pour rendre vos commits plus expressifs et informatifs.

Le BFG Repo-Cleaner est un outil en Scala, plus rapide et plus simple que git-filter-branch, conçu pour nettoyer les dépôts Git en supprimant les gros fichiers ou les données sensibles comme les mots de passe. Il permet de cloner un dépôt, de le nettoyer avec des commandes spécifiques, puis de pousser les modifications. Exemples d'utilisation : suppression de fichiers spécifiques, suppression de blobs volumineux, remplacement de texte sensible. Le BFG ne modifie pas le dernier commit pour éviter les problèmes de déploiement.

Une astuce pour donner plusieurs adresses de push pour le même remote