GIT c’est la vie

GIT est un outil puissant, si vous avez manqué le 1er volume c’est ici : GIT, commandes utiles. J’y donnais quelques commandes qui me servent bien au quotidien et qui permettent surtout de gagner du temps et/ou résoudre des problèmes.

Pas d’intro, juste des commandes bien pratiques je trouve :

Par situation

Le cherry-pick

J’ai plusieurs environnements, j’ai plusieurs branches, au hasard, une branche master, une branche qualif, une branche dev. J’ai besoin de passer un correctif en prod. Je pourrais créer autant de branches que de tickets par exemple et passer les tickets correctifs en “mergeant dans chaque env” ce qui présente des avantages et des inconvénients.

Une autre voie peut être de chopper l’identifiant du commit, avec un git log –oneline ça se fait rapidement et puis je cherry-picke :

git checkout mon_branche_env
git cherry-pick ea44b63

source

Le rebase méconnu

Tout à fait méconnu, le rebase permet de soigner son historique. Lors de nos dévs nous sommes amenés très souvent à récupérer le dépôt distant ne serait-ce que pour intégrer le travail des collègues. GIT est un outil collaboratif mais très vite et proportionnellement au nombre d’intervenants, l’historique va se retrouver pourri par des merge successifs et inutiles, notamment lorsque l’on travaille sur la même branche.

C’est automatique parce que la stratégie par défaut d’un git pull fait que le merge est utilisé. Pour y remédier il vaut mieux intégrer directement dans sa feuille de config globale :

git config --global pull.rebase true

Ainsi à chaque fois que je ferai un pull, autant dire tout le temps le rebase sera choisi par défaut au lieu du merge.

Si on le dit autrement, au lieu de laisser GIT considérer qu’il y a deux branches à merger alors qu’il s’agit strictement de la même (la locale et la distante), on lui indique d’intégrer tout à la suite sur la même branche. C’est pour ça que vous verrez lors d’un pull en mode rebase, les commits récupérés s’insérer et vos commits s’appliquer par dessus.

Ours ? Theirs ? C’est quoi ce bordel ?!

Une chose qui m’a longtemps laissé perplexe est ce principe de “theirs” et “ours” notamment quand on résout des conflits. C’est confus parce que c’est pas clair à la base. Ce vocabulaire est inadapté mais c’est facile de critiquer les fondations, inspecteur des travaux fini smile

Alors le cas simple : “ours” c’est, par exemple dans le cas d’un merge, la branche dans laquelle on fusionne. “theirs” est la branche qu’on merge, pourrait-on dire. Dans le cas d’un cherry-pick par exemple, moi j’y comprends plus rien :=)

show show

Le git show permet de lister les fichiers impliqués dans un commit grâce à son sha. Donc typiquement un git show sha :

git show --pretty="format:" --name-only ea44b63

Et les options que je rajoute améliore la présentation qui est dégueulasse mais complète par défaut.

Je fetche !

Par définition le fetch va concerner notre dépôt distant. On peut récupérer par exemple tout ce qui a été commité sans pour autant le déployer :

git fetch --all

Une que j’ai découvert il y a peu :

git fetch -p

Si par exemple j’ai supprimé des branches et que je veux synchroniser ça sur mes env :

git fetch -p
git branch -a

Vous verrez que les branches supprimées à distances le seront aussi en local maintenant. Mettre le dossier .git/ au régime, ça lui fera pas de mal, il est gras quand même faut dire, pratique mais gras smile

reflog

Je recherche un commit, j’ai fait de la merde ou pas d’ailleurs, je suis un peu perdu, putain en plus on m’a interrompu mais qui a osé ?! Je peux faire :

git reflog

Il va me sortir tout ce qui s’est passé récemment à la manière de ce que l’on peut voir dans les séries TV et qui permet d’à peu près suivre même si on a raté quelques saisons.

remote show

Je veux toujours de l’info, encore de l’info, cette fois-ci sur le dépôt distant :

git remote show origin

Très méconnu mais permet de récupérer facilement de l’info.

GIT, l’ultime ?

GIT n’est pas ultime, loin s’en faut. Au quotidien, on utilise finalement très peu de commandes, mais comme dans tout langage, il faut être en mesure d’élever son niveau de jeu de temps à autre pour faire face à des situations.

De ce que j’ai vu jusqu’à présent, GIT n’échappe pas aux travers des autres langages comme PHP et autres. Totalement inconstant, une même commande peut servir à faire 36 trucs différents et donc augmente la probabilité, de fait, de faire des erreurs.

GIT ne garantit pas l’intégrité des données, c’est l’expertise, le savoir-faire, la connaissance, appelez-le comme vous voulez, qui le permet. Avec un reset –hard un push -f on peut flinguer n’importe quel GIT. L’historique se remanie à la volée…

C’est ultra verbeux, pour faire des trucs basiques faut 5 commandes minimum.

Ok ok, je viens de l’écrire donc a priori c’est mon ressenti. Cela ne m’empêche pas d’apprécier l’outil, de le trouver indispensable et adapté au travail en équipe, de le recommander aussi à tout va.

Conclusion

La seule vérité est qu’il faut connaître ses outils sur le bout des doigts et pas seulement les avoir au bout des doigts. Rien ne remplace l’expérience, le travail en équipe avec des développeurs plus expérimentés ou tout simplement mieux renseignés sur un sujet est un accélérateur phénoménal.

La maîtrise, du moins une meilleure maîtrise de ses outils, c’est le gage d’une sérénité, d’une plus grande efficacité pour enfin peut-être un jour arriver à s’exprimer en plein potentiel dans son code. Apprendre sans brûler les étapes, tel un sage, on voudrait tous y arriver. Dans la réalité, la “vraie vie” (expression que certaines détestent smile ), on veut tout absorber rapidement, on croit qu’on sait tout dès qu’on apprend un truc nouveau.

Je crois qu’arrivé à un certain point, on peut prendre plus de recul et comprendre que ce n’est pas le cas et que l’on peut juste humblement s’assurer qu’on sera meilleur que la veille, que la semaine dernière, le mois passé, l’année dernière, je vais pas tous les faire c’est déjà lourd.