Article traduit depuis l’anglais avec DeepL
Quand j’ai fait ma première initiation à git, le formateur a pris une heure pour nous expliquer comment ça marche. J’en ai ensuite parlé à mon colocataire qui était déjà un Devops confirmé et il m’a dit « Mais ça m’a pris au moins un an pour apprendre les concepts de base »…
Cela fait maintenant plus de trois ans que j’utilise « un système de versionnement qui est expressément conçu pour vous faire sentir moins intelligent que vous ne le pensiez » et je voulais partager quelques conseils que j’aurais aimé connaître plus tôt.
Des Graphiques Utiles
Lorsque vous utilisez git en équipe, vous avez souvent besoin de revenir en arrière pour comprendre quand les choses se sont mal passées. git graph est l’outil qu’il vous faut pour cela, mais la commande base n’est pas aussi pratique que vous pourriez vouloir. C’est pourquoi vous pouvez utiliser git log --graph --oneline et git log --graph --oneline --all
Ces commandes produisent un graphique lisible que vous pouvez facilement parcourir. Vous pouvez également l’utiliser comme aide pour vos notes de version si vous utilisez semver. L’utilisation du flag --all aura l’avantage d’afficher toutes les branches, ce qui peut se révéler un peu fouilli parfois…
Supprimer les conneries
Lorsque vous faites un rebase, vous pouvez vouloir garder seulement un ensemble de changements du commit sur lequel vous travaillez. La méthode officielle est de parcourir furieusement tous vos change et de supprimer le code de la même branche sans faire d’erreur…
La méthode la plus intelligente est d’utiliser git checkout –ours/theirs que vous pouvez évidemment utiliser comme ceci : git checkout --ours -- myfile pour limiter les changements. Cela vous permettra de voir les différents changements que git tente d’appliquer, de manière plus précise. Voici un exemple avec le conflit suivant
Ici, nous avons un rebase classique et désordonné où nous devons choisir les changements à conserver. Utilisons d’abord git diff --ours pour voir d’où nous venons :
Nous voyons rapidement le code que nous sommes en train d’éditer, nous pouvons le comparer avec le code que nous devrions avoir dans le prochain commit que nous essayons d’appliquer (leurs changements) avec git diff --theirs
En utilisant les drapeaux avec git checkout, nous pouvons obtenir directement le code que nous voulons. Notez que vous devez préciser le fichier que vous voulez modifier. Voici un exemple avec le résultat de git checkout --theirs -- main.py
Plutôt sympa non ? Mais restez ici pour la prochaine partie, avec cette fonctionnalité les changements seront beaucoup plus faciles qu’aujourd’hui
Une nouvelle façon de gérer les conflits
Nous pouvons discuter du fait que git est drôle ou non, mais les conflits ne le sont jamais. C’est pour cela que diff3 a été inventé : pour faciliter ce processus difficile. L’option Diff3 va changer la présentation des conflits pour qu’il soit plus facile de trier ce qu’il faut garder.
Le mode conflit par défaut vous montre le commit actuel et le commit conflictuel mais il ne vous montre pas le premier ancêtre commun, vous aurez donc du mal à trouver ce que vous vouliez réellement écrire à cet endroit
Ignorer facilement
Ce n’est pas vraiment une commande git mais j’aimerais mettre en avant le site gitignore.io qui génère un .gitignore sur mesure pour votre projet en fonction de vos besoins
Derniers conseils
Si vous êtes un utilisateur de zsh, je vous conseille d’activer le plugin git qui vous donne beaucoup d’alias utiles. Par exemple, nos bien-aimés git log --graph --oneline et git log --graph --oneline --all sont devenus glol et glola!