Git rebase est ton ami
Salut les ami(e)s !
Suite à une petite démo de mon CTO Gaëtan Buellet (gaetanbuellet sur twitter) sur l’utilisation de git rebase et les bonnes méthodes pour bosser, j’ai voulu mettre en pratique tout ça en me faisant un petit cas pratique chez moi le soir (si si j’ai une vie, je vous jure). Et, ô miracle j’ai réussi tout seul comme un grand.
Après avoir pleuré de joie pendant quelques secondes intérieurement, je me suis dit que j’allais partager cela avec vous.
Et rien de mieux que de comprendre ce que l’on fait par un exemple ! Autant vous prévenir de suite : je ne suis pas un expert, mais pour ce que j’ai appris et compris, je pense qu’il serait pas mal de vous le partager.
Rendons à César ce qui est à César
Je n’ai rien inventé. Gaëtan a fait une petite conférence / démo sur le sujet un peu plus poussé que ce que je vais vous proposer. Je vais me baser sur le même type d’exemple, mais cette version écrite sera avec mes mots (parfois avec des blagues pas très classe je l’avoue). Vous trouverez la vidéo de sa conférence / démo par ici les ami(e)s ! : https://www.youtube.com/watch?v=mYnF7eo5C20&t=12s
Rebase, kézako m’sieur ?
Rebase c’est tout simplement une façon de reconstruire ses commits plus proprement afin d’éviter par exemple 4 commits de suite qui indique “correction header” alors qu’un seul serait plus propre. Mais pas que, vous pouvez réécrire vos messages, éditer vos commits, etc. !! L’avantage avec rebase c’est qu’au lieu de faire systématiquement des commits et des push dans la foulée, vous ne faites que des commits. Et quand vous êtes fier de votre code, vous faites un coup de rebase pour mettre de l’ordre dans tout ça. Mettez-vous en tête que le git rebase c’est un peu le “range ta chambre” de votre mère. Et après tout ça, un git push et c’est dans la boîte :)
De quoi j’ai besoin chef ?
De git, d’un terminal et…c’est tout ! Ha si, un café. On a toujours besoin d’un café. A ce propos, vous allez probablement me dire “écoute mon lapin, t’es mignon mais moi j’ai un super éditeur de code et j’ai tout à dispo directement par l’interface alors ton terminal hein…” C’est vrai, pourquoi s’emmerder à faire en ligne de commande un git commit –m “mon message de la mort qui tue des personnes décédées” alors qu’en appuyant sur un bouton c’est automatique ? Bah tout simplement j’ai envie de dire que déjà on est des fifous et que c’est plutôt pas mal de comprendre ce qu’on fait et pas juste cliquer sur un bouton. Personnellement, j’aime apprendre comment fonctionnent les choses. Apprendre, c’est la vie (et le gras aussi mais là c’est un autre sujet…).
Dit chérie, ce soir on rebase ?
Après ce titre très classe et qui va me valoir une tôlée de commentaire pas sympa (mais moi ça m’a fait rire), commençons notre exploration de rebase.
Je précise de suite : je pars du principe que vous avez installé git sur votre PC, que vous avez votre projet déjà en place lié à votre github ou bitbucket et que vous savez vous servir de votre terminal. Pour ma part git est bien au chaud sur mon ordi avec un projet hyper Hi-Tech de ouf malade. J’utilise cmder comme terminal (https://cmder.net/) et VS Code de Microsoft que je trouve plutôt sympa, mais que nous ne verrons pas dans notre cas pratique.
Regardons ensemble ce que j’ai en stock grâce à la commande git log :
“Mais Jamy, comment ça marche ?”
Déjà on voit que le git log affiche du commit le plus récent au commit le plus ancien. Et qu’ai-je fait comme commit ? Alors là franchement j’ai fait de la merde :) Des commits comme ça je peux vous dire que mon boss m’attaque à coup de pistolet Nerf.
Update ? Update home ? Oui ok mais j’ai fait quoi exactement, car là ça ne veut rien dire. “La vérité est ailleurs Scully”.
Donc on peut dire dans l’ordre de bas en haut : J’ai récupéré mon projet avec mon git clone. Ensuite, j’ai initialisé mon projet. Apparemment, j’ai fait un “update de la home”, un autre “update” (un update de quoi ? Alors là celui qui va faire de la relecture de code me le renverra dans les dents) et enfin, on dirait que j’ai fait dans un seul commit encore un “update de la home” et créé une nouvelle page. Et ça, ce n’est pas top. Nous allons renommer certains commits, faire des merges et découper tout ça pour que ce soit plutôt propre.
Faisons un git rebase -i. Le -i veut dire interactive. Cela va nous permettre d’interagir au fur et à mesure sur nos commits et faire des actions. A noter que le git rebase -i rebase sur tous les commits. Pour moi, lors de l’installation de git, j’ai associé notepad++ comme éditeur de configurations. Mais vous pouvez le faire sous vim ou nano. Faites comme bon vous semble. Voici ce que j’obtiens :
Et là attention : l’ordre d’affichage est inversé par rapport au git log. Le plus ancien en haut et le plus récent en bas. Je vais tenter de vous expliquer ce que j’ai compris et appris. Par défaut, vous avez pick devant chaque commit. Pour modifier un commit, vous devez remplacer pick par la lettre ou le mot complet correspondant à l’action décrit sous les commit :
- reword (r) : permet de réécrit le message de votre commit
- edit (e) : permet d’éditer le commit. On l’utilisera tout à l’heure par exemple pour diviser un commit en deux pour que ce soit plus propre.
- squash (s) : que celui qui vient de dire que c’est une partie de Squash prend ses affaires et sort. Cette commande va vous permettre de merge 2 commits en gardant les 2 messages.
- fixup (f) : la même chose que notre ami squash à la différence qu’il prendra le ou les commit(s) et les mergera dans le premier en ne gardant que le message du premier. Dans notre exemple, nous n’utiliserons que lui et non squash.
- exec (x) : permet d’exécuter une commande directement dans le shell
- break (b) : stop à l’endroit du commit où nous mettons le b
- drop (d) : supprime votre commit
Concernant label, reset et merge. Autant être honnête avec vous. Je n’ai pas la connaissance nécessaire pour vous l’expliquer et affirmer que c’est ça. A prendre avec des pincettes : label permet de mettre un label sur votre commit. Je pense que cela doit agir un peu comme un tag. Reset vous permettra d’annuler votre rebase après avoir fait des modifications pour revenir en arrière. Et merge, bah… un merge de votre commit en utilisant le message mis sur le commit initial. Attention, sur ces 3 là, prenez bien mes explications avec des pincettes. Je ne voudrais pas vous dire des conneries. :)
Commençons par renommer notre commit “update home” car là franchement ça ne veut rien dire. À la place de pick sur la ligne “update home”, mettez un r (si vous avez suivi, c’est reword). Enregistrez et sortez de votre éditeur proprement (VIM, Nano, notepad++, etc.).
Bim !! Il se rouvre. Non ce n’est pas un bug :) Git a vu que vous vouliez éditer votre message avec reword. A la place de “update home” je vais mettre “Ajout de mon bloc CMS” et fermer de nouveau mon éditeur favori proprement après avoir enregistré. J’insiste sur le proprement hein, on est des fifous mais pas des bourrins ^^.
Là plusieurs infos vont apparaître dans votre terminal pour vous dire que vous avez modifié avec succès votre commit. Refaite un coup de git log pour voir ?
Nous pouvons voir qu’au troisième commit en partant du bas, nous n’avons plus “update home” mais “Ajout de mon bloc CMS”. Magnifique hein ? Bon maintenant, je n’aime pas trop le “home + new page”. Nous avons deux actions et cela mériterait de séparer en deux commits. Et vous allez voir ce n’est pas si compliqué que ça. Déjà on va refaire un git rebase -i et on va remplacer pick par e sur le commit “home + new page”. On enregistre et on ferme toujours proprement.
Que s’est-il passé ? Il a parcouru tous les commits et s’est arrêté sur notre coupable que l’on veut éditer. Faites un git status et vous allez voir que git vous indique que vous êtes actuellement en train d’éditer le commit ‘7a713f8’ (pour moi).
OK cool continuons et faisons un git reset HEAD~. HEAD c’est comme un pointeur. En gros on dit que l’on veut faire un reset à l’endroit où on est. Ensuite, faites un git status. Et là, je trouve le contenu de mon commit. Je peux voir que j’ai modifié encore mon index.php et que j’ai un nouveau fichier (page.php) :
Chouette tout ça ! Et bin là, rien de plus simple. Nous allons faire deux commits : un commit avec notre index.php et un autre pour notre page.php. Et pour ce faire :
- git add index.php
- git commit –m « Correction bug home »
- git add page.php
- git commit –m « Ajout page.php »
Pas très dur hein ? Bon là on a fini, car si vous faites un git status, vous ne voyez plus de fichiers à commit. Alors on fait quoi ? On continue ? Bah voilà vous avez trouvé : git rebase — continue. Git vous déroule le tapis rouge et vous dit « Successfully rebased and updated… »
Refaite un git log pour le fun :
Et ben voilà ! On a deux commits bien propres à la place de notre commit tout dégueu de « update + new page ».
On a presque fini. Là c’est cool on voit notre beau commit “correction bug home”, mais celui de dessous n’est pas top. Mais…. mais… Attends ! Ho non, je me rappelle avoir fait une correction sur la home et non un update ! J’ai probablement oublié de changer le message du commit, zut alors !…….. (vous avez vu un peu ce jeu d’acteur ?). Bref, on va fusionner les deux commits. Prêt ? C’est parti, vous commencez à connaitre la chanson :
- git rebase -i
- On remplace le pick par f (qui veut dire fixup) du commit « update »
- On enregistre et on ferme proprement.
Successfully blablabla… oué je sais on est au top mister git 😊 Refaite un git log et là. Plus de « update ». Il a été mergé avec le commit au-dessus.
Entre nous, les commits là, ça a quand même plus de gueule que ce que l’on avait au départ :
Là on est fier de nos commits. On peut faire un git push.
J’attire votre attention sur un point très important. Lorsque vous mettez le f de fixup, il se mergera automatiquement sur celui du dessus. Donc ne mettez pas de f sur le commit cible et laissez pick.
Dernière remarque, si vous voulez regrouper plusieurs commits dans un seul, mais que ces derniers ne se suivent pas, vous devez réordonner les commits. L’avantage d’avoir lié notepad++, c’est que je fais tout à coup de ctrl+x et ctrl+v. Mais avec VIM ou Nano vous pouvez aussi réordonner comme bon vous semble. Et pas besoin de réordonner et de sortir, vous pouvez tout faire d’un coup, bouger vos commits, mettre vos f, r ou e et faire votre tambouille si vous n’avez pas trop d’action à appliquer. Mais je vous conseille de le faire par étape si vous devez faire pas mal de remaniement sinon vous allez vite transpirer du slip les amis :)
Voilà ! J’espère que cette petite introduction au git rebase vous aura plu !
Longue vie et prospérité !
Laisser un commentaire