Les mises à jour ont été rejetées car la pointe de votre branche actuelle est en retard

156

Je suis nouveau sur Git, alors n'hésitez pas à me traiter comme un débutant.

Notre flux de travail est tel. Nous avons une succursale appelée à devlaquelle je peux accéder origin/dev. Lorsque nous apportons des modifications, nous créons une branche de développement:

git checkout -b FixForBug origin / dev

Maintenant, j'ai une branche appelée FixForBugqui suit (je pense que c'est le bon mot) origin/dev. Ainsi, si je fais un, git pullcela apportera de nouveaux changements, origin/devce qui est formidable. Maintenant, quand j'ai fini avec mon correctif, je pousse vers une branche distante appelée la même chose.

Tout d'abord, je tire vers le bas toutes les modifications origin/devet je fais un rebase:

git pull --rebase

Ensuite, je pousse les modifications vers une branche distante du même nom:

git push origin FixForBug

Maintenant, il y a une branche sur le serveur distant et je peux créer une demande d'extraction pour que ce changement soit approuvé et fusionné dans la branche de développement. Je ne me pousse jamais rien origin/dev. Je suppose que c'est un flux de travail assez courant.

La première fois que je fais un git push, cela fonctionne bien et crée la branche distante. Cependant, si je pousse une deuxième fois (disons lors de la révision du code, quelqu'un signale un problème), j'obtiens l'erreur suivante:

erreur: échec de l'envoi de certaines références vers ' https://github.limeade.info/Limeade/product.git ' indice: les mises à jour ont été rejetées car la pointe de votre branche actuelle est derrière indice: son homologue distant. Intégrez les modifications distantes (par exemple indice: 'git pull ...') avant de pousser à nouveau. astuce: Voir la 'Remarque sur les avancées rapides' dans 'git push --help' pour plus de détails.

Cependant, si je fais un, git statuscela dit que je suis en avance de origin/dev1 commit (ce qui a du sens) et si je suis l'indice et que je cours git pull, cela dit que tout est à jour. Je pense que c'est parce que je pousse vers une branche différente de ma branche en amont. Je peux résoudre ce problème en exécutant:

git push -f origin FixForBug

Dans ce cas, il transmettra les modifications à la branche distante, en disant (mise à jour forcée) et tout semble aller bien sur la branche distante.

Mes questions:

Pourquoi est -frequis dans ce scénario? Habituellement, lorsque vous forcez quelque chose, c'est parce que vous avez fait quelque chose de mal ou du moins contre la pratique courante. Est-ce que je vais bien faire cela, ou est-ce que cela va gâcher quelque chose dans la branche distante ou créer des tracas pour quiconque doit éventuellement fusionner mes éléments dans le développement?

Mike Christensen
la source
2
Il semble que le message que vous recevez indique que la branche distante FixForBug est en avance sur votre branche locale FixForBug. Vous devez extraire les modifications de cette branche distante et les fusionner dans votre branche locale avant de pousser.
mhatch
4
@mhatch - Alors en gros, lancez-vous git pull origin FixForBugavant de pousser vers ça? Ok, ça a du sens. N'hésitez pas à ajouter comme réponse!
Mike Christensen

Réponses:

202

Le -f est en fait requis en raison du rebase. Chaque fois que vous effectuez un rebase, vous devez effectuer une poussée forcée car la branche distante ne peut pas être avancée rapidement vers votre validation. Vous voudrez toujours vous assurer que vous faites un pull avant de pousser, mais si vous n'aimez pas forcer push to master ou dev d'ailleurs, vous pouvez créer une nouvelle branche vers laquelle pousser, puis fusionner ou faire un PR .

Keif Kraken
la source
2
Merci pour cette réponse très utile! :)
AIM_BLB
1
Pourriez-vous clarifier le point "Vous voudriez toujours vous assurer que vous faites une traction avant de pousser"? Il est clair pourquoi "push -f" après le rebase de la branche locale est nécessaire. Dans ce cas, le rebase du local ne sera-t-il pas annulé en tirant sur la télécommande avant de pousser?
haripkannan le
51

Pour vous assurer que votre branche locale FixForBug n'est pas en avance sur la branche distante FixForBug, tirez et fusionnez les modifications avant de pousser.

git pull origin FixForBug
git push origin FixForBug
mhatch
la source
2
OP a déclaré qu'ils avaient déjà fait un git pull et avaient essayé de pousser. Votre réponse ne s'applique pas à la question d'OP.
Patrick
1
Il vaut toujours mieux éviter une poussée forcée. Merci d'avoir partagé ça!
Ann Kilzer
16

Si vous voulez éviter d'avoir à utiliser -f, vous pouvez utiliser simplement

git pull

au lieu de

git pull --rebase

Le non-rebase récupérera les modifications origin/devet les fusionnera dans votre FixForBugbranche. Ensuite, vous pourrez exécuter

git push origin FixForBug

sans utiliser -f.

Greg Hewgill
la source
3
Rebase fait partie de notre flux de travail ici. Je vais me faire crier dessus si je ne le fais pas.
Mike Christensen
1
@MikeChristensen: D'accord, alors suivez bien sûr la procédure documentée. D'après ce que vous décrivez, vous devrez utiliser -fparce que vous remplacez les commit (s) sur le référentiel en amont par d'autres qui ont un historique différent (rebasé). Si vous deviez utiliser un produit tel que Gerrit, il prend en charge ce type de flux de travail de révision de code de rebasage sans avoir à l'utiliser -flors du push. Nous utilisons Gerrit au travail de cette manière et cela fonctionne très bien.
Greg Hewgill
16

the tip of your current branch is behind its remote counterpartsignifie qu'il y a eu des changements sur la branche distante que vous n'avez pas localement. et git vous dit d'importer de nouvelles modifications REMOTEet de les fusionner avec votre code, puis pushvers remote.

Vous pouvez utiliser cette commande pour forcer les modifications au serveur avec local repo ().

git push -f origin master

avec une -fbalise, vous remplacerez Remote Brach codepar votre code.

Talha Rafique
la source
6

La commande que j'ai utilisée avec Azure DevOps lorsque j'ai rencontré le message «les mises à jour ont été rejetées car la pointe de votre branche actuelle est derrière» était / est cette commande:

git pull origin master

(ou peut commencer avec un nouveau dossier et faire un clonage).

Cette réponse ne répond pas à la question posée, en particulier, Keif a répondu à cela ci-dessus, mais elle répond au titre / titre de la question et ce sera une question courante pour les utilisateurs d'Azure DevOps.

J'ai noté le commentaire: "Vous voudriez toujours vous assurer que vous faites une traction avant de pousser" en réponse de Keif ci-dessus!

J'ai également utilisé l'outil Git Gui en plus de l'outil de ligne de commande Git.

(Je ne savais pas comment faire l'équivalent de la commande en ligne de commande "git pull origin master" dans Git Gui, donc je suis de retour en ligne de commande pour faire cela).

Un diagramme qui montre diverses commandes git pour diverses actions que vous pourriez vouloir entreprendre est celui-ci:

entrez la description de l'image ici

Allan F
la source
4

Cela m'est juste arrivé.

  • J'ai fait une demande de tirage à notre maître hier.
  • Mon collègue l'examinait aujourd'hui et a vu qu'il n'était pas synchronisé avec notre branche principale, donc avec l'intention de m'aider, il a fusionné le maître avec ma branche.
  • Je ne savais pas qu'il avait fait ça.
  • Ensuite, j'ai fusionné le maître localement, j'ai essayé de le pousser, mais cela a échoué. Pourquoi? Parce que mon collègue fusion avec master a créé un commit supplémentaire que je n'avais pas localement !

Solution: déroulez ma propre branche pour obtenir ce commit supplémentaire. Puis repoussez- le dans ma branche distante.

littéralement ce que j'ai fait sur ma branche était:

git pull
git push
Mon chéri
la source
3

C'est ainsi que j'ai résolu mon problème

Supposons que la branche amont est celle à partir de laquelle vous avez bifurqué et que l'origine est votre dépôt et que vous souhaitez envoyer un MR / PR à la branche amont.

Vous avez déjà disons environ 4 commits et vous obtenez Updates were rejected because the tip of your current branch is behind.

Voici ce que j'ai fait

Tout d'abord, écrasez tous vos 4 commits

git rebase -i HEAD~4

Vous obtiendrez une liste de commits avec pickécrit dessus. (ouvert dans un éditeur)

exemple

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

à

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

Après cela, vous pouvez enregistrer votre commit combiné

Prochain

Vous devrez cacher votre commit

Voici comment

git reset --soft HEAD~1
git stash

maintenant rebase avec votre branche amont

git fetch upstream beta && git rebase upstream/beta

Maintenant, pop votre commit caché

git stash pop

engager ces changements et les pousser

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f
Deepesh Nair
la source
2

Cela doit être parce que la validation est en avance sur votre poussée actuelle.

1) git pull origin "nom de la branche que vous voulez pousser"

2) git rebase

si git rebase réussit, alors c'est bien. Sinon, vous avez résolu tous les conflits de fusion localement et continuez jusqu'à ce que le rebase à distance réussisse.

3) git rebase --continuer

kris
la source
0

J'ai eu ce problème en essayant de pousser après un rebase via Visual Studio Code, mon problème a été résolu en copiant simplement la commande à partir de la fenêtre de sortie git et en l'exécutant à partir de la fenêtre du terminal dans Visual Studio Code.

Dans mon cas, la commande était quelque chose comme:

git push origin NameOfMyBranch:NameOfMyBranch

HoloLady
la source
0

Vous devez avoir ajouté de nouveaux fichiers dans vos commits qui n'ont pas été poussés. Vérifiez le fichier et poussez-le à nouveau et essayez de tirer / pousser cela fonctionnera. Cela a fonctionné pour moi.

Rahul Parab
la source