GilLabs notes, talks, and experiments

Mes commandes Git preferees

30 May 2026

Apres avoir lu quelques articles comme celui-ci et celui-ci, j'ai decide de faire ma propre liste aussi. Voici donc une petite liste des choses de Git auxquelles je reviens encore et encore.

git add -i

Permet d'ajouter des fichiers de maniere interactive dans la staging area.

J'aime beaucoup cette commande quand je modifie plusieurs fichiers en meme temps et que je veux separer le travail en commits plus petits. Au lieu de tout envoyer dans un commit d'un coup, je peux revoir fichier par fichier et choisir ce qui entre.

git add -p

Celle-ci ressemble a git add -i, mais va un niveau plus loin : elle permet d'ajouter des parties specifiques d'un fichier.

C'est tres utile quand le meme fichier contient deux changements differents. Par exemple, vous avez corrige un bug et aussi fait un petit refactoring dans le meme fichier. Avec git add -p, vous pouvez mettre seulement le bug fix dans le commit actuel et laisser le refactoring pour un autre commit.

git log --oneline --graph --all

C'est la commande classique pour visualiser l'historique comme un graphe :

bash
git log --oneline --graph --all

Je l'utilise beaucoup pour comprendre rapidement ou je suis, quelles branches existent, ou un merge a eu lieu et si ma branche a diverge d'une autre.

git rebase -i

git rebase -i est l'une des commandes les plus utiles pour nettoyer une sequence de commits avant d'ouvrir une PR ou avant de partager une branche.

Avec elle, on peut :

  • reorganiser les commits
  • fusionner de petits commits avec squash ou fixup
  • modifier les messages
  • supprimer les commits qui n'ont plus de sens

Bien sur, c'est aussi une commande a utiliser avec prudence, surtout sur des branches deja partagees. Mais sur des branches locales, avant de publier, elle est excellente pour transformer une sequence de travail un peu desordonnee en une histoire plus facile a relire.

git push origin HEAD:<branch>

Envoie le commit actuel de votre HEAD vers une branche specifique sur origin. C'est tres utile si votre branche locale n'a pas le meme nom que la branche distante, ou si vous voulez publier exactement l'etat actuel sans changer de branche.

git bisect

git bisect est une de ces commandes que je trouve belle conceptuellement : elle fait une recherche binaire dans l'historique pour decouvrir quel commit a introduit un bug.

L'idee de base est de marquer un commit comme bon et un autre comme mauvais :

bash
git bisect startgit bisect badgit bisect good <bon-commit>

A partir de la, Git saute dans l'historique et vous lui dites si chaque point teste est bon ou mauvais. A la fin, il indique le commit suspect.

La commande devient encore plus puissante quand elle est combinee avec des tests automatises, parce qu'on peut laisser Git tester les commits pour nous.

git reflog

Le reflog vous sauve souvent apres un "mauvais reset", un "mauvais rebase" ou une confusion avec detached HEAD.

Alors que git log montre l'historique des commits accessibles depuis la branche actuelle, git reflog montre par ou votre HEAD est passe recemment.

Cela signifie que lorsqu'un commit "disparait", il apparait souvent encore dans le reflog.

bash
git reflog

Apres avoir trouve le hash perdu, vous pouvez creer une branche temporaire ou revenir prudemment a ce point.

Alias et fonctions bash

Creer des raccourcis et des fonctions utilitaires est une bonne addition a votre devX personnel. Dans cette ligne, j'ai un repo avec des commandes que je collectionne depuis quelques annees :

https://github.com/adrianogil/git-tools

Un exemple est gz, une fonction qui fait un git reset --hard vers une reference choisie avec fzf. Attention quand meme, parce que le hard reset peut supprimer des changements non commites.

bash
function ghard-reset-fz() {    if [ -n "$1" ]; then        echo "Git hard reset to ref $1"        git reset --hard "$1"        return $?    fi    # Build a nice list with:    # <ref> | <short-hash> | <author> | <date> | <subject>    local line ref    line=$(        git for-each-ref \            --sort=-committerdate \            --format='%(refname:short) | %(objectname:short) | %(authorname) | %(committerdate:short) | %(subject)' \            refs/heads refs/remotes \        | default-fuzzy-finder    ) || return 1  # user aborted    # Take only the first field (the ref name before the first '|')    ref=\((awk -F'|' '{gsub(/^ *| *\)/, "", \(1); print\)1}' <<< "$line")    if [ -z "$ref" ]; then        echo "No ref selected."        return 1    fi    echo "Git hard reset to ref $ref"    git reset --hard "$ref"}alias gz="ghard-reset-fz"

Vous pouvez copier les alias d'autres personnes, mais ecrire les votres vous apprend beaucoup plus. Commencez avec 3 commandes que vous utilisez tous les jours. Donnez-leur de bons noms. Documentez-les. Ameliorez-les avec le temps. Ce processus construit a la fois de meilleurs outils et une meilleure intuition de Git.