Si j'étais marseillais un verre de ricard à la main, je me serai posé cette question bien plus tôt ! Mais ce n'est pas le cas. Heureusement il n'est jamais trop tard ! ;)
Par habitude, afin de mettre à jour un repository GIT distant, j'utilise git pull. Ca fonctionne à merveille, tout le monde a ses données à jour et on se croirait presque au pays des bisounours. Mais Gargamel vient mettre son nez là-dedans (ouais je mélange Schtroumpf et Bisounours. Honte sur moi !).
Ce matin, j'ai voulu, avant de faire la release de la version 1.0.0 de jesus (car il est prêt pour la production), mettre à jour la documentation. Le principe est simple. J'utilise GitHub Pages. Il me faut donc juste une branche "gh-pages", dont le contenu correspond à ce qui est en ligne chez GitHub pour ma documentation. Dès que je commit sur cette branche, la page en ligne est mise à jour.
Cependant mes deux branches master et gh-pages n'ont pas le même index. Les deux ne peuvent pas être mergées ! Ce matin, je me vois donc faire un
git pull origin gh-pages:gh-pages
Et justement pour le coup, j'aurai du faire un
git fetch origin gh-pages:gh-pages
La différence entre ces deux commandes en apparence similaires est pourtant énorme. Git fetch ne fait que récupérer les données. Git pull les récupère et fait un merge avec la branche courante ... Du coup merge mes deux branches, vu qu'elles ont pas la même base, c'est pas super cool.
Moralité : vous pouvez faire un git fetch afin de mettre à jour votre copie locale avec les derniers commits distants. La branche sur laquelle vous faites le fetch aura les derniers commits. Mais votre branche de travail ne sera pas modifiée. Si vous faites un git pull, non seulement la branche sur laquelle vous faites le fetch aura les derniers commits distants. Mais votre branche de travail sera également mergée avec ces derniers commits.
En y réflechissant bien, fetch est bien plus recommandable que pull, qui peut casser un repository assez facilement.
Commentaires