Ah ben zut, je pige pas un mot de ce que tu dis là. Je suis désolé, mais je pige que dalle à Git dès qu’on fait des branches et des machins.
Déjà que je pige pas la différence entre «Fetch» et «Pull» (Fil m’a expliqué, j’ai rien gobé), alors l’histoire de «dry-run», tu te doutes que c’est du chinois.
Je reprend : visiblement tu as fais quelque part une merde en local, en fusionnant une branche distante de dev dans ton master (je sais pas comment !)
Ce n'est pas très grave si tu fais juste cela en local. Mais si tu push, ca devient problématique, puisque cela pourri l'historique des autres.
Si tu utilise l'option --dry-run sur ton git push, alors git ne va pas pousser tout de suite, mais juste faire une sorte de test, et te dire les resultats que cela donnerait. Comme ca tu aurais vu que t'a envoyé un commit foireux, et aurait pu corriger.
Arno, pourrais-tu taper la commande dans ton terminal pour que tes pull soient toujours en rebase et éviter de nous faire des merge sans arrêt sur le master quand quelqu’un a commit en parallèle de toi ?
git config --global pull.rebase true
J’en profite pour répondre à ta question :
git fetch : git va chercher les commits qui sont sur le serveur et les récupère en local, dans son arbre, MAIS il ne les checkout pas. En gros tu restes sur le même commit en local, mais simplement git sait maintenant qu’il y a des commits en plus sur le serveur si c’est le cas
git pull : c’est un git fetch + le checkout dans ton répertoire des commits qui arrivent depuis le serveur.
Et c’est là que le problème se pose : si toi tu as travaillé entre temps, ton dossier local contient des commits qui ne sont pas sur le serveur, et le serveur contient des commits qui ne sont pas sur ton disque.
Pour ça 2 solutions :
• soit git fait un merge (c’est le réglage par défaut que tu as actuellement), et ça génère sans arrêt plein de commits de merge un peu ennuyeux
• soit git fait un rebase : il va enlever tes commits locaux, remettre les commits qui arrivent depuis le serveur, et rejouer tes commits par dessus. 99% du temps ça se passe bien, mais parfois il peut y avoir un conflit sur une modif faites des 2 côtés. Dans ce cas suivre les indications de git : editer le fichier, résoudre le conflit manuellement, faire un `git add` dessus, puis un `git rebase --continue`
OK, je viens donc de taper la commande, mais j’utilise un client git graphique (Fork sur Mac), je ne sais pas du tout s’il passe par git en ligne de commande tel que configure dans le terminal.