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 ?
- Lancer
git reflog(ougit reflog BRANCHpour moins de bruit). - Chercher un message de commit pertinent.
- Inspecter le commit avec
git show $COMMIT_IDougit log $COMMIT_ID. - Récupérer le commit avec
git reset --hard $COMMIT_IDougit 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 !
Ce comic illustre comment des commits peuvent se "perdre" dans Git, même s’ils restent souvent stockés quelque part. Les causes fréquentes : git commit --amend, git rebase, la suppression d’une branche non fusionnée ou git stash drop. Trois niveaux de gravité sont décrits : "énervant" (le commit n’est plus référencé par une branche/étiquette mais reste facile à retrouver), "cauchemar" (il faut fouiller tous les commits), et "catastrophe" (le commit est supprimé). Heureusement, Git conserve généralement les commits "perdus" : on peut les retrouver via le reflog pour les cas simples, ou git fsck pour les situations plus complexes. Une bonne raison de ne pas paniquer et de connaître ces outils de récupération !
Ce comic explique de façon visuelle et accessible comment Git stocke les fichiers en interne. À l’aide de la commande git cat-file -p, on peut explorer un commit : celui-ci contient un arbre (tree) pointant vers des fichiers (blobs) ou d’autres arbres, chaque objet étant identifié par un hash SHA-1. Par exemple, un commit affiche son auteur, sa date, son message, et l’ID de l’arbre racine ; cet arbre liste les fichiers et leurs hashs, permettant à Git d’éviter les doublons en réutilisant les mêmes objets si le contenu ne change pas. Une façon simple et concrète de comprendre que Git fonctionne comme un système de fichiers basé sur des hashs, où chaque modification crée de nouveaux objets tout en réutilisant ceux inchangés. Une astuce utile pour mieux appréhender le fonctionnement interne de Git !
L'article explique l'utilisation de la commande break dans Git, introduite dans la version 2.20.0, qui fonctionne comme un point d'arrêt lors d'un rebase. Contrairement à edit, qui cible un commit spécifique, break permet d'arrêter le rebase à n'importe quel endroit pour inspecter l'état du code, exécuter des tests, ajouter des commits ou modifier le dernier commit. L'auteur démontre comment utiliser cette commande pour améliorer le flux de travail de rebase, par exemple en ajoutant un fichier de licence oublié et en modifiant un message de commit. La commande break est présentée comme un outil puissant pour le débogage et l'inspection du code à différents points de l'historique des commits.
L'auteur expose plusieurs concepts et bonnes pratiques de git, en revisitant Blanche-Neige. C'est assez drôle, bien écrit et surtout très compréhensible.
L'article explore l'importance des messages de commit clairs et de la documentation complète dans le processus de développement logiciel. L'auteur y décrit sa routine personnelle pour rédiger des messages de commit détaillés et structurés, en utilisant un modèle standard qui inclut le type de modification, la portée, un résumé, une description du problème, la solution apportée, et le contexte supplémentaire. Il souligne également l'impact positif de cette pratique sur la collaboration et la maintenance du code. L'article aborde aussi l'utilisation d'outils comme les hooks Git pour maintenir la qualité des commits et l'intégration de l'IA pour aider à la documentation. Enfin, l'auteur partage son approche pour gérer la documentation à travers différentes étapes du développement, soulignant que ces pratiques sont essentielles pour un développement professionnel efficace.
L'article présente les 8 stratégies courantes dans la gestion des branches sous git, avec leurs avantages et leurs inconvénients.
Pour préparer un message de commit à l'avance dans Git sans créer de commit immédiatement, vous pouvez utiliser un script qui met en scène du contenu et prépare un message de commit. Ce message sera automatiquement inséré dans l'éditeur lors du prochain commit sans nécessiter de paramètres supplémentaires ou de modifications de configuration.
La solution, qui semble non documentée, consiste à utiliser le fichier .git/MERGE_MSG. En écrivant votre message de commit dans ce fichier, l'éditeur de commit s'ouvrira avec ce message déjà rempli.
Initialement, l'auteur avait suggéré d'utiliser .git/SQUASH_MSG, mais .git/MERGE_MSG est plus approprié. Cette méthode a été découverte en examinant le comportement de git cherry-pick --no-commit, qui permet de comprendre comment Git gère ces fichiers. Cette approche reste utile pour identifier tout nouveau mécanisme si celui-ci venait à changer.
Cet article explique comment configurer un "git credential helper" OAuth sur Debian et Microsoft WSL pour se connecter à GitLab, évitant ainsi de stocker des mots de passe ou des jetons d'accès personnels. Pour Debian, il utilise git-credential-oauth, tandis que pour WSL, il utilise le "Git Credential Manager" inclus avec "Git for Windows". Des instructions détaillées sont fournies pour chaque environnement, y compris la configuration pour des instances GitLab auto-hébergées.
L'article présente dix commandes Git peu connues qui peuvent améliorer l'efficacité des développeurs. Parmi elles, git restore permet d'annuler des modifications ou de déstager des fichiers, tandis que git switch facilite le changement de branches. git sparse-checkout permet de cloner uniquement les fichiers nécessaires dans un dépôt volumineux, et git range-diff compare les différences entre deux séries de commits. git notes ajoute des métadonnées aux commits sans encombrer l'historique, et git worktree permet de travailler sur plusieurs branches simultanément. git bisect aide à identifier les commits à l'origine de bugs, git replace modifie l'historique sans changer les hashs, et git fsck vérifie l'intégrité du dépôt. Enfin, git alias permet de créer des raccourcis pour des commandes fréquentes. Ces commandes peuvent faire gagner du temps et résoudre des problèmes complexes.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Les astuces :
- alias git
- indexation partielle
- vscode
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre