Oui, c’est du clickbait ! Vous en connaissez sûrement une partie si vous avez l’habitude d’utiliser git en ligne de commande. Mais je suis quand même prêt à parier que vous apprendrez au moins une chose au cours de cet article (soyons fou). Je me base surtout sur mes découvertes récentes et sur ma réaction lors de cette découverte. Un « Wouah mais c’est génial » ou un « Aaaah, c’est donc à ça que ça sert, pamal » vaudront à la commande en question d’apparaître dans cet article. On va commencer par les plus « communes » pour aller dans le plus spécifique (selon évidemment mon propre avis). Et pour éviter de répéter ce qui a déjà été fait, je vais éviter au possible ce qui est déjà cité sur OhShitGit que je vous invite à visiter !

Un set-upstream automatique

On est tous déjà tombé sur le message suivant:

fatal: The current branch test has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin test

Ce message arrive quand vous essayez de push une nouvelle branche fraichement créée mais que la branche n’existe pas encore sur votre repo. Ce message est vite gênant quand on travaille seul vu qu’on sait que la possibilité d’erreur est quand même très faible. Vous pouvez régler votre git pour automatiquement créer la branch si elle n’existe pas encore avec la commande suivante:

git config --global push.autoSetupRemote true

Récupérer un commit spécifique

Mince, gros conflit sur une branch mais on a besoin de deploy un mini-features ou un hotfix qui a été fait sur cette branch… C’est dommage, le commit est propre ! Pas de soucis, allons cueillir des cerises !

La commande cherry-pick permet effectivement de récupérer un commit situé sur n’importe quelle autre branch et l’injecter sur la branch courante. Par exemple si vous êtes sur master et que vous devez récupérer le commit 36a418f sur la branch really-big-refactor, vous pouvez utiliser la commande comme suit:

git cherry-pick 36a418f

Notons qu’il n’y a aucunement besoin de préciser le nom de la branch où est situé le commit, le hash du commit suffit. Restons simples !

Valider les changements lors d’un add

Erf, vous avez modifié beaucoup de lignes d’un fichier mais vous n’avez pas encore fini et on vous demande de push juste la suppression de la popup en bas de page. Tant pis, on ctrl-z jusqu’à avoir le bon état de fichier ? Que nenni ! Faisons plus simple:

git add -p

Vous aurez alors une proposition des modifications blocs par blocs dans chaque fichier et vous pouvez valider (y) ou refuser (n). Cela vous permet également de faire une énième review avant de tout mettre en ligne, ce qui n’est jamais une mauvaise chose !

git add -p

Vérifier son ignorance

Des fois vous avez besoin de push des fichiers ignorés par défaut, ou vérifier que votre .gitignore marche bien. Pour cela le plus simple est de demander ! Il existe effectivement une commande qui vous permet de lister les fichiers non trackés:

git ls-files --others --ignored --exclude-standard

Ce qui nous amène à la commande suivante:

Faire un petit nettoyage de printemps

Vous avez peut-être déjà entendu parler de la commande git clean. Cette commande permet de supprimer tous les fichiers non-trackés par git. C’est à dire les fichiers qui ne sont pas add ni ignorés. Par exemple tous les fichiers terminant par ~ si votre éditeur a un système intégré de backups (ce qui peut causer des soucis de sécurité). Mais laisser git nettoyer ça fait peur. Et si vous aviez éviter de git add un fichier important ? Il disparaîtrait dans les abysses de votre disque dur ! Don’t Panic ! Il existe une option bien pratique pour lister les documents concernés. Ainsi, aucun risque d’erreur:

git clean -n
git clean -n

C’est bon, vous êtes sûrs de vouloir les supprimer ! Mais vous aimeriez bien également supprimer les fichiers ignorés aussi ! Quoique… Vous n’êtes pas sûrs de vouloir supprimer TOUS les fichiers ignorés… Le doute vous ronge, vous n’en dormez plus ! Aucun soucis, il existe pour cela deux options:

  • -x vous permettra d’ajouter à votre git clean les fichiers ignorés
  • -i activera le mode interactif, vous pouvez par exemple choisir les numéros des fichiers à supprimer
git clean -xi

Trouver le commit fautif

Mince un bug… En revanche vous n’avez pas touché à ce fichier depuis genre deux semaines… Mince, quel commit a introduit ce bug ? Il va falloir investiguer chaque commit sur GitHub… Ou utiliser le bisect ! Le quoi ?

Cette commande bien pratique fonctionne en plusieurs étapes:

  • Démarrer la recherche
  • Notifier un commit comme étant mauvais (par exemple l’état actuel vu que le bug y est présent)
  • Remonter assez les commit pour trouver au hasard un commit sain

Ensuite, git prendra petit à petit des commits situés entre les deux et vous pourrez les indiquer comme sains ou non jusqu’à trouver LE commit dans lequel le bug est apparu.

On commence donc la recherche:

git bisect start

On indique ensuite que le commit actuel contient le bug:

git bisect bad

Puis on trouve un commit ancien qui ne contient pas le bug, et on indique à git qu’il est sain:

git bisect good 9825f91

Ensuite git fera du yo-yo et vous pourrez indiquer « git bisect bad » ou « git bisect good » jusqu’à trouver le fautif.

Et si le but n’est pas de corriger le bug mais de prouver que c’est Michel qui l’a introduit, parce que j’ai quand même autre chose à faire que de corriger ses fautes: je ne vous apprend sûrement rien mais vous pouvez lancer un:

git blame monFichier.php

Et hop, vous vous rendez compte qu’en fait c’est bien vous qui avez commis la faute, mais qui n’est finalement pas si grave !!

Et voilà, c’est tout pour cette sélection et j’espère que vous aurez au moins appris quelque chose, sinon tant pis pour vous vous avez perdu environ 10mn !