Putain de GIT !

GIT c’est le BIEN mais comme dirait Daniel Roch parfois le développeur mérite d’aller brûler en enfer.

Bon on exagère peut-être mais sur ce sujet l’adage selon lequel l’outil dépend de ce que l’on en fait est toujours vrai.

GIT ?

Pour les non initiés, GIT est un outil de versionning, on conserve la trace de toutes les opérations sur le code source du site. Qu’il s’agisse de petites ou de grosses modifications, comme un petit fix sur un bug ou une mise à jour du core et des plugins, le versionning s’impose.

Et donc de ce discours on en arrive à dire que GIT c’est top, moi le premier. Le problème c’est qui va l’utiliser. Et comme on est tous ultra nuls avant d’être bons et que la différence ne va se faire que sur la marge de progression et la rapidité d’apprentissage, je vous propose la voie rapide.

Allez tout schuss ?!!

Là aussi c’est un problème que je constate en faisant un peu de formation en ligne. On va parfois très vite, on oublie que nous aussi on a paniqué un jour devant tout ça, on se prend même à se moquer parfois. Ah la la honte sur nous smile

On va vite parce qu’on traite un sujet donné, on a pas le temps de refaire tout le toutim, c’est la différence entre une formation complète sur un sujet et un tutoriel ciblé. Avec GIT certaines subtilités peuvent parfois vous échapper et ça peut tourner au casse-tête. Donc on va essayer de ne pas tomber dans tous ces écueils ici.

Considérations métier

Pour ma part j’essaie d’utiliser les lignes de commandes pour apprendre à maîtriser l’ensemble et ensuite j’avise sur les outils. Comme je ne sais pas tout de GIT, je ne m’appelle pas Christophe Porteneuve et même lui doit ignorer quelques trucs quand même, j’y travaille. Et rien ne vaut la pratique pour voir des cas de figure parfois même improbables.

Cela permet d’essayer de raisonner et ce n’est qu’en faisant l’effort soi-même que l’on peut y arriver. Si on attend que quelqu’un nous explique à chaque fois on stagnera et on regardera sans cesse les autres faire. Je ne sais plus où j’ai entendu cette phrase :

la compréhension n’est pas nécessaire à l’exécution
mais au secours ! Tu sais pas lire ou/ni écrire t’es mal, tu sais pas te servir d’un ordi t’es pas loin d’être dans la merde en 2015 malgré tout. Alors après quand tu commences à charbonner (ex: en tant que développeur) y a une énorme hiérarchie devant toi, tu as beau connaître beaucoup de choses voire être spécialiste, relativement parlant ça peut devenir risible et là je parle sur une échelle mondiale aussi.

Alors qu’est-ce qu’on fait ? On touche plus à rien et on laisse faire les grands ? Moi je dis non. Comme disait mon Grand-Père “si t’y arrives pas tu vas y arriver”. Remarquez y a un autre adage qui dit que “refaire sans arrêt la même chose en attendant un résultat différent c’est le début de la folie”, à vous de voir smile

J’en arrive quand même à mon point : on est pas tous égaux. Y en a certains qui captent plus vite que d’autres qui font tout plus mieux globalement et puis y a 99% de la population. Tout ce qu’on fait dans nos métiers peut rapidement devenir frustrant. Quand bien même y aurait de l’open source avec des articles et des vidéos au top en fallback, bah si moi j’y arrive pas ça risque de craindre non ? Deux réactions courantes : “allo maman bobo” et “c’est de la merde ce tuto, pff !”. Notez que la dernière marche avec tout, une API, un plugin, etc.

Si je continue à blablater là-dessus en fait on s’en sort jamais. Donc une fois n’est pas coutûme c’est la philosophie qui va nous aider. Pourquoi on fait ça ? Qu’est-ce qu’on recherche finalement ? Si c’était la maille, je pense qu’on ferait autre chose donc on cherche plutôt à évoluer, apprendre de nouvelles choses, surmonter pourquoi pas certains blocages, une sorte d’accomplissement.

La peur, l’ennemie du dév

@TweetPressFr @BoiteAWeb @grafikart_fr J’attend ton analyse avec impatience! Changer D’IDE me fait encore peur tongue

— Altis Celing (@AlTi5)

April 7, 2015

Pour l’avoir expérimenté et constaté chez d’autres la peur c’est le MAL. Il faut la fuir. On peut être très bon développeur mais si on manque (trop) de confiance en soi ou si on panique bah finalement on va régresser et on est là pour trouver des solutions donc gardons la tête froide. Alors attention ça vient pas du jour au lendemain, on bosse tous dur pour y arriver, mais par exemple ça peut passer par changer d’IDE, se mettre à utiliser d’autres outils et technologies, en somme :

Sortir de sa zone de confort
Je me permets d’en conclure que :

si tu es dév et adepte de l’immobilisme tu es foutu !
Au passage tiens si on parle des communautés sur la toile par exemple, quand ça bouge pas assez et bah ça meurt.

C’est quoi le rapport avec GIT ?

Tout est lié, pour moi il y a quelques mois GIT c’était réservé à Duncun Macleod et puis en fait non et puis espérons que ce que je trouve hyper technique aujourd’hui j’en rigole dans quelques mois.

GIT, le versionning en général, ça sert aussi à revenir en arrière facilement quand ça a merdé et dans une autre perspective à exécuter les coupables façon Game of Thrones comme il se doit smile Je déconne mais savoir qui a fait quoi c’est important.

Rien à foutre là, les commandes ça vient ?!

Pour toutes celles et ceux qui n’ont que faire de mes considérations sur le métier et qui sont venus ici parce que le titre parlait de commandes GIT, shortcut ! On passe aux codes. Ici j’ai trié par situation, ça me semble plus parlant.

Sauvegarder le travail en cours

Je suis entrain de bosser sur mon code et un collègue me demande de pousser certains de mes commits sur la branche où on bosse ensemble ou à l’inverse je dois récupérer ses modifs avec un pull. Le problème c’est que je suis entrain de terminer une autre partie du code. Je ne vais pas tout abandonner pour pouvoir pousser ou récupérer les autres modifs. En effet si j’essaie de faire git push ou git pull, je vais avoir un message d’erreur qui dit en gros “non non, soit tu supprimes tes modifs en cours soit tu les stashes”. Et comme je ne sais pas ce que veux dire “stash” je supprime mes dernières modifs et je me console en me disant que c’est le retour des beaux jours.

Stop & stash man ! Ou en français : “Allez vas-y remises-donc pour voir…”

Au lieu de tout perdre, je vais pratiquer le remisage :

git stash

source

La commande permet d’enregistrer les modifications en cours tout en revenant au dernier commit. Donc là on peut pousser nos modifs. Ensuite je n’aurai plus qu’à faire :

git stash pop

Cette commande est un raccourci, elle va chercher le dernier enregistrement (nos dernières mofifs) et le supprime de la stash list.

Restaurer

Ouh là, pose-toi les bonnes questions. Cela peut être le début de la merde. GIT c’est bien pour conserver un historique mais si tu commence à vouloir le retravailler donc réécrire l’histoire c’est chaud.

Avant de te lancer dans le git reset vois si d’autres possibilités s’offrent à toi :

 git checkout -- monfichier.php

Au passage c’est pratique si on ne veut pas rester 107 ans à appuyer sur CTRL + Z.

Si maintenant il s’agit d’annuler un commit foireux par exemple :

git revert 

C’est la méthode la plus indiquée et considérée comme propre.

Maintenant on va pas faire des reverts dans tous les cas. Par exemple j’ai oublié un fichier dans mon commit mieut vaut ne pas faire un git revert ou un autre commit avec un message genre “missing file” c’est pas très intéressant. A la place on pourra faire :

git commit --amend

pour refaire le commit en question cette fois-ci avec le fichier manquant.

MAIS ! Parfois, dans certains cas on a besoin d’aller beaucoup plus loin. En général ça veut dire que ça a merdé. Et là on passe au reset. C’est pas bon signe dans tous les cas. Si vous pouvez éviter faites-le sinon tant pis.

Donc là on peut être dans la situation où en local on a fait 5 commits mais en fait on en veut plus (c’est bizarre quand même rien qu’à le dire mais ça peut arriver) :

git fetch origin
git reset --hard origin/master

Là on va revenir à l’état antérieur, historique + fichiers.

Si vous êtes au bout de votre vie et que vous avez poussé les modifs en question sur le dépôt distant :

git reset --hard 

Ici commit est le commit de référence où vous voulez replacer le curseur autrement dit l’état où vous voulez revenir et puis après faudra forcer le push :

git push -f

Mais là on joue avec le feu.

Supprimer du GIT seulement

Si vous voulez exclure du versionning un fichier ou un répertoire déjà versionné mais sans les supprimer partout. En fait je veux supprimer ces éléments de mon historique GIT mais j’en ai besoin dans mon systèe de fichiers.

La solution :

git rm -r --cached 

Attention à ne pas oublier l’option –cached sinon tout va disparaître y compris du système de fichiers.

Eviter les all

C’est plutôt une bonne pratique je trouve que d’éviter les options du type –all, rien que dans le terme déjà c’est grossier. Lancer des commandes du type :

git commit --all

ça me paraît hasardeux. On va enregistrer tout sans se posser de question si bien que dans le commit tous ce qui trainasse va être aspiré. Si en plus on fait :

git commit -am

Alors là on va directement être amené à enregistrer et à écrire le message de commit sans avoir vérifié la liste des fichiers donc mieut vaut ne pas le faire je pense. Le seul cas où pour moi ça ne posera pas de souci c’est lors d’un fetch :

git fetch --all

On se contente de récupérer tout le GIT sans modifier quoi que ce soit. Après on avise.

Local/Distant pas pareil

Là je dois dire que j’étais scié (par mon ignorance) mais je ne savais pas que l’on pouvait connecter des branches locales et distantes sans qu’elles portent le même nom.

Dans ce cas on va faire un :

git push -u origin mabranche:labranche-distante

Cette syntaxe est un remplacement. Je dis à GIT de remplacer à la volée le contenu de la branche distante par la branche locale. Et apparemment si on fait :

git push -u origin :labranche-distante

on supprime la branche distante. Et paf !

Bon après :

git push origin --delete 

semble être la version updatée de la technique et apparaît un peu plus simple à retenir.