Git - 4 - Bons à savoir

Dernier épisode de la série git, c’est un peu foutrac, parcourez l’article en fonction de ce que qui vous intéresse !
On y parle des commandes utiles (alias, suppression et nettoyage de l’historique, …), des outils graphiques et des outils pour faire des diffs et des messages de commits.

Commandes en plus

Créer des alias

git alias, alias

Certaines commandes git sont trop longues pour vous ? Utiliser les alias ! Il y a en deux types : les alias git, les alias bash.

Les alias git

Les alias git sont des commandes de type git <alias> et qui sont associés à une autre commande git plus longue. Exemples :

git config --global alias.st status -sb
git st

Sortie :

## main...origin/main
 M _posts/dev/2024-08-13-git-3.md
 M _posts/dev/2024-08-13-git-4.md

On peut les configurer directement dans le fichier .gitconfig qui se trouve dans votre home directory.

[alias]
    st = status -sb
    ol = log --oneline
    graph = log --oneline --decorate --graph
    graphall = log --oneline --decorate --graph --all
    ac = !git add -A && git commit -m  # add all and commit

    discard = !git reset --hard && git clean -fd # Supprimer toutes les modifications des fichiers suivis et non-suivis depuis le dernier commit
    uncommit = reset --soft HEAD^ # Supprimer le dernier commit sans supprimer les modifications
    unstage = reset HEAD -- # Annuler l'ajout des fichiers dans la staging area

Les alias bash

Dans .bashrc, on peut configurer des alias. Exemple :

alias ca='git add -A && git commit -m ' # Commit All
ca "Mon message"

Supprimer l’historique

git reset

Dans un précédent article de cette série, je présentais git revert et vous recommandais de l’utiliser de préférence à git reset. Cependant git reset a son intérêt.

git reset est une commande qui permet d’écraser l’historique. Or, s’il y a bien une chose que git n’aime pas pour le travail collaboratif, c’est modifier l’historique. Des historiques non synchronisés = problèmes assurés. N’utilisez git reset que si vous êtes seul sur votre projet ou seul sur votre branche. Dans l’idée, il faut toujours aller de l’avant, un rollback est une modification comme une autre qui mérite d’être conservée dans l’historique.

git reset git log --oneline Commentaire
--hard d9d039d
--hard HEAD~2		 d9d039d (HEAD -> main) First commit Toutes les commits et leurs modifications jusqu’à d9d039d seront effacées de l’historique
--soft d9d039d
--soft HEAD~2		 d9d039d (HEAD -> main) First commit Tous les commits jusqu’à d9d039d seront effacés,
les modifications sont conservées mais à recommiter.
Faire un git status pour voir les fichiers à valider

Maintenant que vous êtes devenus des boss de git, vous pouvez manipuler cette dangereuse commande qu’est git reset !

Nettoyer l’historique

bfg, git filter-repo

bfg repo cleaner fait du ménage pour vous dans l’historique d’un repo. Il permet les choses suivantes :

  • supprimer des fichiers de taille importante ou des patterns de fichiers dans l’historique d’un repo
  • remplacer des chaînes de caractères dans l’historique (pour supprimer des mots de passe, tokens malencontreusement commités)

Git a développé git filter-repo plus récemment qui fait concurrence à bfg . git filter-repo a l’air très puissant mais il est plus difficile à manier et contrairement à bfg, il ne protège pas le dernier commit.

Attention cependant ! En modifiant l’historique, un repo distant ne sera plus synchronisé. Il faudra très certainement se recaler sur la version nettoyée du repo et pousser l’intégralité de l’historique grâce à git push --force.

Stocker des fichiers de taille importante

git lfs

git n’a pas été conçu pour stocker des fichiers de volume important ou des binaires (même si il peut le faire). Imaginons que vous ayez des fichiers de test, des images, voire des vidéos que vous souhaitez stocker dans votre repo. Alors peut-être que Git LFS peut vous aider ! Git Large File Storage est un plugin permet de gérer ces fichiers différemment :

  • sur un repo local, les fichiers volumineux ne sont que des pointeurs jusqu’à ce que vous exécutiez git lfs fetch pour récupérer ces fichiers sur le repo distant.
  • sur un repo distant, les fichiers pointés par Git LFS sont stockés dans un espace disque spécifique.

J’avais commencé à l’utiliser de manière plus généralisée cependant je l’utilise de moins en moins :

  • il faut installer git lfs sur sa machine et l’initialiser dans son repo,
  • il faut que le repo distant utilise un serveur ou un espace spécifique pour stocker les fichiers volumineux. Sinon ils sont simplement stockés sur les disques du repo ! Et donc git lfs est inutile. Donc l’utilisation de Git LFS dépend de la décision de l’organisation qui héberge votre repo distant.
  • pas toujours facile d’avoir tout le monde sur un projet qui utilise Git LFS.

Donc mon point de vue est de ne pas utiliser git lfs à moins que ce soit la seule solution et dans ce cas il faut être organisé entre tous les contributeurs.rices d’un projet.

git lfs doit être installé depuis ici.

Commandes en vrac

git worktree

Si j’avais su que git worktree existait plus tôt, j’aurais pu construire la tour Eiffel 3 fois au lieu de perdre mon temps dans des merges conflicts résultant d’un switch entre branches. Git worktree permet de rattacher une branche à un arbre de travail spécifiquement, c’est à dire un dossier par branche. Pour plus d’infos : Git worktree : se dénouer les branches

git stash

Commande permettant de mettre de côté des modifs, de faire des opérations de branches, puis de réappliquer les modifs.

git bisect

Permet de trouver l’origine d’un bug dans l’historique. Jamais utilisé (car je développe sans bug), le principe est le suivant : vous êtes au commit A et vous rencontrez un bug, mais vous savez que par le passé celui-ci n’existait pas notamment au commit Z. git bisect va vous aider à faire une recherche binaire pour retrouver l’origine du bug introduit.

C’est mieux expliqué sur cette question Stack Overflow How do I use git bisect?.

Documentation

  • man git-<cmd> : pour obtenir le référentiel complet des options d’une commande git. git <cmd> --help ouvre aussi les manpages
  • tldr git-<cmd> : pour obtenir les options et les utilisations les plus fréquentes d’une commande git. tdlr reste à installer mais il y a un site internet

Outils graphiques

IDEs

C’est vrai que dans ce tuto, on a utilisé uniquement des lignes de commandes. C’est important, parce que si vous voulez dépanner un repo, mieux vaut bien connaître les commandes git. Cependant à l’usage quotidien, on utilise beaucoup les IDE qui intègrent souvent git. Je pense à VSCode (ou VSCodium) ou les logiciels de la suite JetBrains (PyCharm, Intellij …).

JetBrains
J’adore les interfaces JetBrains pour la gestion git. Ce sont les plus clairs et les plus cohérentes et une suite d’interface graphique git est intégré par défaut. Jetbrains est en train de sortir Fleet qui se veut un concurrent de VSCode. J’espère que le projet va rester ouvert !

VSCode
Il faut installer des plugins :

  • Git History qui permet d’avoir une vue du git log, de voir l’historique d’un fichier. C’est pratique mais assez limité comme utilisation.
  • Git Lens est l’extension la plus utilisée, elle est indispensable mais elle est sacrément complexe à utiliser. De nombreuses fonctionnalités sont bloquées par un accès payant (le graphe complet par exemple !)

Parcourir l’historique

J’aimerai franchement bien un outil simple qui m’aide à me balader facilement dans l’historique de manière visuelle sans que j’ai peur de casser quoi que ce soit. Les IDEs et leurs plugins ne sont pas toujours les plus prédisposés à la tâche. J’ai testé plusieurs outils alternatifs et pour l’instant, celui qui ressort c’est Sublime Merge. On espère qu’il reste gratuit !

Avec Sublime Merge, je peux :

  • explorer l’historique
    • sur l’ensemble du repo
    • sur un fichier
    • sur un dossier
    • sur un fichier qui a changé de nom
  • faire une recherche sur l’historique avec des critères de recherche spécifiques.
  • faire des tâches de maintenance git classiques

Pas la possibilité de faire des diffs entre fichiers arbitraires cependant 😢.

Il y a plein d’autres Git GUI dispos, voici la liste la plus exhaustive.

Diffs

Faire des diffs dans git c’est clairement pas user friendly.

Avec les IDEs

Pour faire des diffs d’un fichier ou d’un dossier avec un autre commit ou une autre branche :

Outil Actions
VSCode + plugin Git Lens Clic droit sur le dossier/fichier > “Open Changes”
JetBrains Clic droit sur le dossier/fichier > Compare …

Avec une UI

git diff affiche les différences dans le terminal. Mais il est possible de voir ces diffs dans une interface graphique. Pour cela il faut remplacer git diff par git difftool qui va ouvrir votre éditeur de diff favori (meld, vscode, kompare etc.).

Pour configurer git difftool :

git config --global diff.tool meld
git config --global merge.tool meld
git config --global --add difftool.prompt false

Astuce git worktree

Pour être plus libre dans les fichiers que vous voulez tester entre deux branches ou deux commits, je vous conseille d’utiliser git worktree. Vous aurez ainsi deux versions de votre projets dans deux dossiers différents, il deviendra beaucoup plus facile d’utiliser les IDEs et les UIs pour tester les différences.

Messages de commits

Bien écrire des messages de commits, c’est essentiel. A la fois pour vous, pour se rappeler des changements qui ont été appliqués sur le repo et pour les autres contributeurs et contributrices du projet. Seulement on est bien d’accord, il n’y a rien de plus fastidieux qu’écrire un bon message de commit. Si vous parvenez à être consistant dans ce travail de journaliste, alors cela permet également de compiler beaucoup plus facilement un Changelog.

Convention commits

Il existe désormais une convention pour écrire vos commits : Spécification de la convention.
Vous pouvez vous en inspirer pour votre propre rédaction.

AI Takeover

Avec l’émergence des LLMs, il devient possible de générer automatiquement les messages de commits. C’est magique ✨ Bon après, c’est pas encore tout à fait évident à configurer.

Type de solutions Outils
Solutions payantes et prêtes à l’usage - VSCode : GitHub Copilot, Git Lens
- JetBrains : AI Assistant, Github Copilot
Solutions payantes à configurer CLI : opencommit + Model API Key (ex: OpenAPI/Claude/Mistral)
Solutions gratuites à configurer CLI : opencommit + Modèle local hébergé par ollama (ex: Codestral)

Voilà un exemple de message de commit généré avec llama3 :

Generated commit message:
——————————————————
docs(thredds-wiz.md): add restricted access information for SXT5_PREVIMER users to IOWAGA-WW3-HINDCAST and IOWAGA-WW3-FORECAST datasets on TDS3
——————————————————

Il faudrait écrire un article complet dessus. Je suis encore en train de tester !

Conclusion

J’espère que vous avez aimé ce tuto ! Je suis preneur de vos retours.
Abonnez-vous et activez la cloche pour être les premiers au courant de mes prochaines vidéos.

Ressources

Précédents articles

  1. Intro
  2. Concepts de base
  3. Actions fréquentes
  4. Gitlab - Repo distant
  5. Bons à savoir