Les commandes Git (trop) souvent ignorées

Cet article a été publié depuis plus de 6 mois, cela signifie que le contenu peut ne plus être d'actualité.

S’il y a bien un outil de gestion de sources qui a gagné la bataille, on ne peut citer que Git. Cet outil pratique et extrêmement puissant a été largement adopté par les développeurs. A tel point que c’est devenu l’outil de référence pour la gestion des versions décentralisé. Nous allons voir dans cet article quelques fonctionnalités bien pratiques mais qui sont bien trop souvent ignorées par les développeurs.

git cherry-pick

La commande cherry-pick permet d’appliquer des changements effectués au sein d’un autre commit. Lorsque l’on travaille, il est fréquent d’utiliser des branches pour le développement des différentes fonctionnalités à implémenter. Il peut parfois être utile de récupérer une partie du travail d’un autre développeur sans devoir récupérer l’ensemble de sa branche.

git cherry-pick d42c389f

git bisect

Le git bisect est certainement l’une des commandes que j’affectionne le plus. Pourtant je ne l’ai presque jamais vu utilisé dans mes différentes expériences professionnelles.

Cette commande permet pourtant de faciliter grandement la correction d’un bug de votre application en se chargeant de trouver le commit ayant introduit ce dernier. Il s’agit d’une commande redoutable surtout lorsqu’elle est couplée avec un outil de tests automatisés (c’est pratique mais pas obligatoire).

Son utilisation peut sembler complexe au premier abort, c’est peut-être ce qui freine à son utilisation, mais pourtant une fois familiarisé avec cette dernière, vous ne pourrez plus vous en passer.

git rebase

Je pense que tout le monde connait la commande rebase, mais on ne sait jamais réellement ce qu’il y a derrière. Nous utilisons en général le merge beaucoup plus que nous ne devrions. Certainement parce que ces deux commandes permettent d’intégrer les modifications d’une branche dans une autre. J’ai moi-même mis beaucoup de temps pour bien comprendre la différence.

De manière générale, je vois le rebasage utilisé pour fusionner des commits au sein d’une même branche. Le développeur a utilisé le commit pour sauvegarder son travail à un instant T et souhaite une fois terminé, fusionner et regrouper tous les commits correspondant à la même tâche.

Le fonctionnement du rebase est simple. Cette commande permet de rejouer une série de commits à partir d’une nouvelle base de travail.

Des collègues ont rencontré le problème très récemment. Une fonctionnalité avait été développée sur une branche qui a ensuite été laissée de côté pendant un certain laps de temps. La branche principale ayant elle evolué pendant ce temps, lorsqu’ils ont ensuite tenté de fusionner cette la branche dans le master, ils ont constaté que certaines portions de code avaient été écrasées.

Ce fonctionnement peut sembler déroutant pourtant il est tout à fait logique. La branche où avait été développée la fonctionnalité avait pour point de départ une version obsolète de la branche principale. Lorsque Git a effectué sa fusion, il a réintégré les modifications en tenant compte des changements les plus récents.

Ce problème aurait pu être évité, si un rebase avait été fait avant le merge. Cette opération ayant pour effet de remettre le point de départ de la branche à une version récente et à jour du master.

git checkout ma-branche-ancienne
git rebase master