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

Comment push si la branche local n'est plus à jour ?

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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.

git status :

(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.

+0 -0

Cette réponse a aidé l’auteur du sujet

Hello,

Tu fais un git pull --rebase qui prend upstream/dev comme source, puis tu veux pousser sur origin/testgulp, donc ça ne peut pas s’arranger comme ça.

Il faut d’abord que tu récupères les modifications de origin/testgulp avec git fetch origin, puis tu vas pouvoir faire un rebase correctement avec git rebase origin/testgulp puis pouvoir pousser normalement comme tu le veux.

Néanmoins, es-tu sûr que c’est sur cette branche que tu veux faire ça ? Tu pourras toujours revenir en arrière, mais ça paraît étrange comme les noms ne sont pas les mêmes. Si je comprend bien, upstream est le repo public et tu veux probablement faire un git push --set-upstream origin testgulp sauf si tu mets plus souvent à jour depuis upstream ?

EDIT: Pour info, l’autre solution consiste à prendre une branche partant de origin/testgulp puis merge ta première branche dedans.

Édité par unidan

+2 -0

Cette réponse a aidé l’auteur du sujet

dans ce cas-là, si tu as fait un rebase sur upstream/dev pour récupérer les modifications depuis le github officiel, tu vas vouloir faire git push --force origin testgulp pour forcer l’ajout des modifications de la première branche.

(à faire dès que tu rebases la branche de base pour ta branche de dev, jamais pour une autre raison normalement)

Édité par unidan

+0 -0
Auteur du sujet

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 ?

+0 -0
Auteur du sujet

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

+0 -0

Cette réponse a aidé l’auteur du sujet

Merci de ne pas cliquer sur le bouton "mettre à jour la branche" ce bouton fait un merge. Il est préférabl de faire:

git fetch upstream # met à jour les références du repo public
git rebase upstream/dev # rembobine les modifs, se place sur le commit le plus à jour de dev puis applique les commits un à un.
git push origin ta_branche -f # le -f est obligatoire car tu as réécrit l'historique

Édité par artragis

+1 -0

Merci de ne pas cliquer sur le bouton "mettre à jour la branche" ce bouton fait un merge. Il est préférabl de faire:

git fetch upstream # met à jour les références du repo public
git rebase upstream/dev # rembobine les modifs, se place sur le commit le plus à jour de dev puis applique les commits un à un.
git push origin ta_branche -f # le -f est obligatoire car tu as réécrit l'historique

artragis

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

+0 -0

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é ?

+0 -0

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.

Édité par artragis

+0 -0

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.

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.

artragis

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.

Édité par unidan

+0 -0

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.

Édité par artragis

+0 -0

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.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0

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é.

+0 -0

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.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

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

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0

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.

Édité par unidan

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte