Modification sur github.com, branche local n'est plus à jour

Bonjour,

J’ai suivi : https://zestedesavoir.com/forums/sujet/3630/push-rejete/ La solution indiquée sur le sujet est-elle complète ? J’ai fais git pull --rebase mais j’ai encore le premier message.

(zdsenv) xxx:~/zds/zds-site(testgulp)$ git push origin testgulp
To https://github.com/A-312/zds-site
 ! [rejected]        testgulp -> testgulp (fetch first)
error: impossible de pousser des références vers 'https://github.com/A-312/zds-site'
astuce: Les mises à jour ont été rejetées car la branche distante contient du travail que
astuce: vous n'avez pas en local. Ceci est généralement causé par un autre dépôt poussé
astuce: vers la même référence. Vous pourriez intégrer d'abord les changements distants
astuce: (par exemple 'git pull ...') avant de pousser à nouveau.
astuce: Voir la 'Note à propos des avances rapides' dans 'git push --help' pour plus d'information.

(zdsenv) xxx:~/zds/zds-site(testgulp)$ git status
Sur la branche testgulp
Votre branche est en avance sur 'upstream/dev' de 13 commits.
  (utilisez "git push" pour publier vos commits locaux)
Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)

        assets/screenlog.0
        package-lock.json
        zdsenv/

aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre)

Bon vol,

A.

Pour les noms et les commandes, j’ai suivi : https://zestedesavoir.com/forums/sujet/324/comment-contribuer-comprendre-comment-suivre-le-workflow/

Je voulais juste mettre à jour ma PR.

D’accord donc je peux faire librement ma commande avec -f ou --force.

Si je récapitule : Je rebase : Soit en cliquant sur le bouton sur la page de ma PR sur github, ou soit en utilisant la console avec :

git fetch upstream
git rebase upstream/dev

Puis ensuite je fais git push origin testgulp -f, est-ce bien ça ?

Quand ma branche n’est plus à jour avec de Zeste de savoir le bouton apparaît juste au dessus de la zone de texte pour écrire un message sur la PR, ça génère un commit du style : Merge branch 'dev' into fixspoiler comme ici : https://github.com/zestedesavoir/zds-site/pull/5054

D’ailleurs comment les régressions avec rebase sont testées du coup ?

C’est à dire?

Si tu fais un rebase, seul le dernier commit est testé par la CI habituellement. Du coup tu peux introduire des régressions dans les commits précédents qui cassent git bisect typiquement. Est-ce que c’est testé ? est-ce que c’est pas utilisé ?

heu quand tu fais un merge aussi tu ne vas tester que le dernier commit.

et en soi, si la CI est lancée sur le dernier commit et qu’il y a une régression, il y aura des tests qui vont échouer, donc les regressions ne passeront pas à la trappe.

et globalement je ne vois pas en quoi le rebase casse git bissect, on parle bien ici des PR : la branche "dev" (le master de zds-site) n’est jamais rebase hein.

heu quand tu fais un merge aussi tu ne vas tester que le dernier commit.

Sauf que c’est bien le commit que tu veux tester en —no-ff

et en soi, si la CI est lancée sur le dernier commit et qu’il y a une régression, il y aura des tests qui vont échouer, donc les regressions ne passeront pas à la trappe.

Tu peux avoir une régression sur les commits qui étaient déjà testé et validé si tu fais un rebase, mais qui est corrigée dans les commits d’après.

Si tu merges jamais en fast-forward, effectivement ça fonctionne sur master avec des options type --first-parent en utilisant rev-list.

PS: je dis pas qu’il faut faire quelque chose. Ça se trouve ça ne vous arrive jamais, mais c’est intéressant si vous avez quelque chose pour ça.

Sauf que c’est bien le commit que tu veux tester en —no-ff

heu non, ce que tu veux tester c’est tes commits à toi ajouté au travail commun. Le commit de merge c’est juste du bruit.

Tu peux avoir une régression sur les commits qui étaient déjà testé et validé si tu fais un rebase, mais qui est corrigée dans les commits d’après.

je ne comprends toujours pas.

master = validé ta branche = à valider

si tu rebase ta branche sur master, si tu lances la CI sur le dernier commit tu vas bien tester que tes modifs apportent ou non une régression.

Si tu merges, tu vas devoir tester non seulement que tes commits n’en appotent pas, mais en plus que le commit de mergte n’en 'apporte pas.

Et en plus ce commit c’est du bruit.

Bref je ne comprends toujours pas ton problème.

Je ne toucherais plus au bouton maintenant que je connais la commande exacte à écrire.

Si tu merges, tu vas devoir tester non seulement que tes commits n’en appotent pas, mais en plus que le commit de mergte n’en 'apporte pas.

Ben non, t’as juste à tester le commit de merge, c’est le seul qui a été ajouté au bout de master.

Et en plus ce commit c’est du bruit.

Ben non, il représente le merge lui même.

Le problème d’un rebase, c’est que tu ne peux pas garantir que chaque commit ajouté sur master est sain individuellement, donc tu te retrouves avec une branche avec peu de commit correspondant à un état testé et fonctionnel du projet. Quand tu merges, tu défonces pas cette information et tu sais que si tu remontes la branche master en prenant le commit de gauche à chaque merge, tu restes sur un état valide du projet.

Après c’est une question de philosophie.

Ben non, t’as juste à tester le commit de merge, c’est le seul qui a été ajouté au bout de master.

Ce que je vois quand on a deux branches

master  --A--B--C--D
PR            \--E--F

lorsqu’on merge master dans PR on a

master  --A--B--C--D
PR            \--E--F--MERGE

du coup dans PR tu as bien E,F ET merge a tester

Et comme en plus "merge" vient après E et F tu ne sais pas si c’est E, F ou merge qui ajoute une régression.

En rebasant PR sur master tu as :

master  --A--B--C--D
PR                  \--E--F

du coup si tu as une régression elle est soit dans E, soit dans F.

Le commit de merge, dans le cas d’une PR c’est juste du bruit.

Et pour le coup tu as forcément rebasé sur un master qui est sain. et à la fin la PR peut être ajouté avec un fast forward alors qu’avec le merge c’est plus complexe puisque un des commits (E ou F) peut avoir des conflits au moment du FF alors qu’avec un rebase tu l’as déjà géré.

On ne parle pas de la même chose en fait, toi tu parles de ce qui se passe avant le merge de la PR, moi de ce qui se passe après.

bah en soit le problèmede A-312 c’est qu’il est en train de faire une PR et que github te dit "ta pr est pas à jour".

Ouais mais c’est parce que github est mal fichu, tu peux aussi merger ta branche de PR dans master directement.

Tu peux ne pas voir les commits de merge avec --no-merges.

Sinon on est d’accord que merger master dans une branche c’est généralement pas très beau. Dans ton cas, tu sais que si il y a une régression, c’est à cause des commits de master mergés. Si tu le fais dans l’autre sens tu sais que c’est la branche qui a fait la régression et c’est super important d’avoir le commit de merge dans ce cas-là. Mais tu peux être amené à le faire si tu ne veux pas faire des branches à rebaser.

Mais je parlais en particulier des rebase, pas des merge.