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.

Le reflog Git, c’est quoi ?
Un historique de tous les IDs de commit qu’une branche, un tag ou HEAD a déjà pointés. Utile pour retrouver des commits "perdus".

Différences avec git log :

• Le reflog est local (non partagé entre dépôts).
• Il montre l’état des branches avant un rebase (contrairement à git log).
• Les entrées de plus de 90 jours peuvent être supprimées par git gc.

Comment l’utiliser ?

1. Lancer git reflog (ou git reflog BRANCH pour moins de bruit).
2. Chercher un message de commit pertinent.
3. Inspecter le commit avec git show $COMMIT_ID ou git log $COMMIT_ID.
4. Récupérer le commit avec git reset --hard $COMMIT_ID ou git branch $NAME $COMMIT_ID.

Limites :

• Le reflog d’une branche est supprimé si la branche l’est.
• Inutile pour récupérer un stash supprimé (git stash drop).
• Les entrées ne correspondent pas toujours aux commandes Git exécutées.

Dernier recours :
Si le commit n’est plus dans le reflog, utiliser git fsck pour lister les commits non référencés.

Ce comic explique simplement ce qu’est un dépôt distant (remote) dans Git : un autre dépôt vers lequel on pousse (push) ou depuis lequel on tire (pull) du code. Un remote peut être hébergé sur GitHub, GitLab, un serveur personnel, ou même un dossier local. La syntaxe git push origin main signifie "pousser la branche main vers le remote nommé origin". Les remotes sont configurés dans .git/config avec un nom et une URL, et peuvent utiliser différents protocoles (HTTP, SSH, ou local). Les remotes sont aussi le lieu de "drames" typiques, comme les conflits lors d’un git pull après qu’un·e collègue a réécrit un fichier. Astuce : activer push.autoSetupRemote true pour simplifier le suivi des branches. Une introduction claire et pratique pour comprendre l’interaction entre dépôts locaux et distants !