top of page
Search
  • fabricefontenoy

Attention au (git) pull !

Updated: Oct 5, 2023



Attention à git pull



Si toi aussi t'as envie de pourrir ton historique, de le rendre illisible et te faire lyncher par tous tes collègues, alors fais comme moi, utilise la commande git pull !!!





Bon ok ! C'est vrai que je n'ai jamais vu quelqu'un se faire lyncher parce qu'il avait fait un git pull et heureusement !


Mais pourquoi alors faut-il faire attention avec la commande git pull ? 🤔



Parce que dans certains cas, la commande git pull va rendre votre historique illisible si vous n'y prêtez pas attention. Je vais vous expliquer pourquoi.



Supposons qu'il y ait dans l'équipe deux développeurs ayant cloner un repo contenant initialement deux commits C1 et C2.


git pull suck

Une fois cloné dans leur workspace respectif, chacun des deux développeurs fait une modification et la commit.


Le développeur 1 pousse ses modifications le premier, ce qui se passe bien car aucun commit n'a été effectué sur la branche distante entre temps.


Le développeur 2 essaie également de pousser ses modifications mais comme le développeur 1 a poussé avant lui, il est rejeté par git car il doit mettre à jour son espace de travail.


Il utilise donc la commande git pull... (ben oui, c'est quand même le sujet de ce post !)


git pull sucks

La commande git pull étant par défaut la combinaison entre la commande git fetch et la commande git merge, et comme il y a une divergence entre la branche distante et la branche local du développeur 2, un "vrai" merge est effectué.


Je dis "vrai" merge car s'il n'y a pas de divergence (par exemple un développeur 3 avec dans son repo local uniquement les commits C1 et C2) alors dans ce cas un merge fast-forward est effectué et l'historique reste linéaire.


Le développeur 2 est content, il a récupéré les modifications de la branche distante, le merge s'est bien passé, sans conflit, et il pousse donc ses modifications sur la branche distante.


git pull sucks

Bon déjà, on remarque que l'historique n'est plus linéaire sur le repo distant. Ce n'est pas top mais il reste encore lisible.


Pendant ce temps, le développeur 1 ne s'est pas arrêté de développer car il adore ça, développer. Il développe jours et nuits dans sa chambre dans le noir (les joies du remote 😉), en buvant du café et en parlant à personne (un peu trop stéréotypé peut-être ?).



Il a donc effectué de nouvelles modifications (dans un commit C6) depuis son dernier push qu'il veut à présent partager. il commence donc par récupérer les modifications qui sont la branche distante en utilisant la commande git pull ( ben, oui... c'est toujours le sujet de ce post)


Là encore, il y a divergence avec la branche distante, un "vrai" merge est donc effectué.

git pull sucks

Vous commencez à comprendre, avec deux développeurs, l'historique dévient déjà compliqué.


Mais supposons qu'un troisième développeur arrive et clone le repo juste après que C5 soit poussé, qu'il fait une modification et qu'il la pousse...



git pull sucks

Et ben ça commence à être sacrément le bordel là-haut et comprendre quelque chose avec cet historique risque d'être compliqué !



Et en plus de ce problème d'historique illisible, l'utilisation de la commande git pull engendre également les problèmes de foxtrot merge... mais ça, ça fera l'objet d'un autre article.



Ok mais comment éviter ça ???



Plusieurs solutions :

  • Arrêter le dev 🤣

  • Flageller tous ceux qui utilisent git pull jusqu'à ce qu'ils comprennent

(disclamer : ceci est une blague, n'y voir aucune incitation à la violence)

  • Travailler chacun sur sa branche. Seul sur ta branche, tu n'as pas de problème car les merge feront des fast-forward, c'est-à-dire des rebase.

  • Configurer la commande git pull pour qu'elle effectue la combinaison git fetch + git rebase au lieu de git fetch + git merge

Je vous invite à jeter un oeil à mon tuto sur la configuration pour savoir comment faire.

  • Ne plus utiliser la commande git pull et d'abord utiliser la commande git fetch pour comprendre ce qui c'est passé sur le repo, puis utiliser git rebase ou git merge en connaissance de cause. C'est ma solution préférée !

  • Faire une formation avec GitAddict pour tout comprendre à git. Ah non ! En fait c'est celle-là ma solution préférée !



Voilà ! J'espère que je vous ai convaincu à ne plus utiliser la commande git pull ou alors à bien la configurer ! Si ce n'est pas le cas, venez en discuter avec moi 😉



----


Vous avez aimé cette article ? Vous voulez devenir un expert git ?

N'hésitez pas à me contacter !







266 views

Recent Posts

See All
bottom of page