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 :
- À jour
- Besoin de pull
- Besoin de push
- 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 fetchré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 :
- Ajouter les modifications à la zone de staging (
git add,git rm,git mv). - Valider avec
git commit.
La zone de staging, 3 noms pour une seule chose :
- staged (
--staged) - cache (
--cached) - index (
--keep-index)
Astuces :
git add -ppermet de commiter seulement certaines parties d’un fichier.git diffne montre que les modifications non staged :git diff HEAD→ toutes les modifications non commitées.git diff --cached→ seulement les modifications staged.
git commit -ane prend pas en compte les nouveaux fichiers (il faut lesaddavant).
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 resetpeut 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 ?
- 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