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

Bartek Płotka partage son expérience avec lazygit, une interface utilisateur pour Git qu'il a découverte par accident en utilisant Neovim. Malgré son attachement à Goland pour le développement professionnel, il a été séduit par la simplicité, la rapidité et l'interactivité de lazygit, qu'il utilise désormais pour tous ses workflows Git. Dans cet article, il explique pourquoi lazygit est si spécial, comment il peut améliorer la productivité et ce que nous pouvons apprendre de son design et son expérience utilisateur. Il compare également différentes interfaces Git et souligne l'importance de maîtriser le CLI Git, surtout pour les nouveaux développeurs.

L’article présente Git Much Faster, un script open source conçu pour optimiser drastiquement les temps de clonage des dépôts Git, surtout pour les gros projets (comme Chromium ou le noyau Linux). En combinant des stratégies comme la désactivation de la compression (core.compression=0), l’augmentation de la taille des buffers HTTP (http.postBuffer=1024M), les clones partiels (--filter=blob:none) et les checkouts éparses, il permet de réduire les temps de clone jusqu’à 93% et l’espace disque jusqu’à 98%, sans sacrifier l’accès au code source. Par exemple, le dépôt Chromium (60+ Go) passe de 95 minutes à 6 minutes de clonage. Le script propose aussi des benchmarks comparatifs avec Git Scalar et des configurations sur mesure pour CI/CD ou environnements distants. Idéal pour les équipes confrontées à des dépôts volumineux ou des pipelines lents, il s’installe simplement via un script bash et s’adapte à différents cas d’usage, tout en limitant les impacts sur l’historique ou la complétude des données. Une solution pragmatique pour booster la productivité et réduire les coûts d’infrastructure.

Les branches divergentes : source de conflits en push/pull
Erreurs classiques :

! [rejected] main -> main (non fast-forward)
fatal: Need to specify how to reconcile divergent branches.

Qu’est-ce qu’une branche divergente ?
Local et distant ont chacun des commits que l’autre n’a pas.

4 états possibles avec une branche distante :

1. À jour
2. Besoin de pull
3. Besoin de push
4. Divergée (il faut choisir comment résoudre le conflit)

Comment détecter une divergence ?

git fetch
git status
# Exemple de sortie :
# "Your branch and ‘origin/main’ have diverged, and have 1 and 1 different commits each."

Solution rapide :

git pull --rebase

(Mais il existe d’autres options, comme merge.)

À retenir :

• git fetch récupère les derniers commits.
• git pull = git fetch + git merge (ou rebase).

Git affiche constamment des diffs – mais parfois, ils semblent étranges.

Pourquoi ?

• Git ne comprend pas les intentions : un renommage (git mv old.py new.py) est traité comme une suppression + ajout.
• L’algorithme de diff compare simplement deux versions et essaie de résumer les changements de façon lisible… mais pas toujours avec succès.

Astuce :

• Git propose plusieurs algorithmes de diff. Par exemple, pour mieux gérer les réorganisations de code :

  git diff --histogram

Git utilise un processus de commit en 2 étapes :

1. Ajouter les modifications à la zone de staging (git add, git rm, git mv).
2. Valider avec git commit.

La zone de staging, 3 noms pour une seule chose :

• staged (--staged)
• cache (--cached)
• index (--keep-index)

Astuces :

• git add -p permet de commiter seulement certaines parties d’un fichier.
• git diff ne montre que les modifications non staged :
  • git diff HEAD → toutes les modifications non commitées.
  • git diff --cached → seulement les modifications staged.
• git commit -a ne prend pas en compte les nouveaux fichiers (il faut les add avant).

Git n’a pas de bouton "Annuler"
Pas de unadd, uncommit, unmerge ou unrebase. À la place, il y a git reset – puissant, mais dangereux.

Comment fonctionne git reset ?

• La plupart des commandes Git avancent la branche (git commit, git merge, git pull).
• git reset peut déplacer la branche n’importe où : en arrière, en avant, ou "de côté".
• Exemple : git reset HEAD^ force la branche à pointer sur le commit parent, et déstage les changements.

Options clés :

• Par défaut : conserve les modifications dans le répertoire de travail.
• --hard : supprime les modifications non commitées (attention, irréversible !).

Risques :

• Facile de "perdre" des commits en reculant une branche.
• Avec --hard, perte définitive des changements non commités.