Les mises à jour ont été rejetées car l'extrémité de votre branche actuelle est en retard par rapport à son homologue distant

Question

Notre flux de travail est le suivant. Nous avons une branche appelée dev que je peux atteindre à origin/dev. Lorsque nous apportons des modifications, nous créons une branche à partir de dev :

git checkout -b FixForBug origin/dev

Maintenant j'ai une branche appelée FixForBug qui suit (je pense que c'est le bon mot) origin/dev. Ainsi, si je fais un git pull, il apportera de nouvelles modifications de origin/dev ce qui est super. Maintenant, lorsque j'ai terminé ma correction, je pousse vers une branche distante portant le même nom.

Tout d'abord, je récupère toutes les modifications de origin/dev et je fais un rebase :

git pull --rebase

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

git push origin FixForBug

Maintenant, il y a une branche sur le serveur distant et je peux créer une demande de fusion pour que la modification soit approuvée et fusionnée de nouveau dans la branche dev. Je ne pousse jamais quoi que ce soit vers origin/dev moi-même. Je pense que c'est un flux de travail assez courant.

La première fois que je fais un git push, ça fonctionne bien et crée la branche distante. Cependant, si je pousse une deuxième fois (disons pendant l'examen du code, quelqu'un signale un problème), je reçois l'erreur suivante :

error: failed to push some refs to 'https://github.mydomain.info/Product/product.git'
hint: Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.
See the 'Note about fast-forwards' in 'git push --help' for details.

Cependant, si je fais un git status, il dit que je suis en avance de 1 commit sur origin/dev (ce qui a du sens) et si je suis le conseil et que je lance git pull, il dit que tout est à jour. Je pense que c'est parce que je pousse vers une branche différente de ma branche amont. Je peux résoudre ce problème en exécutant :

git push -f origin FixForBug

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

Mes questions :

Pourquoi est-ce que -f est requis dans ce scénario ? Habituellement, lorsque vous forcez quelque chose, c'est parce que vous faisiez quelque chose de mal ou du moins contre les pratiques standard. Est-ce que je peux le faire, ou est-ce que cela va perturber quelque chose dans la branche distante ou créer des problèmes pour celui qui devra finalement fusionner mes modifications dans dev ?

Answer 1

Nous pouvons forcer des changements sur GitHub en utilisant notre dépôt local avec la commande suivante :

git push -f origin main

Answer 2

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 en retard" était / est cette commande :

git pull origin master

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

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

J'ai noté le commentaire : "Vous voudriez toujours vous assurer de faire un pull avant de pousser" dans la réponse de Keif!

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

(Je n'étais pas sûr de comment faire l'équivalent de la commande en ligne de commande "git pull origin master" dans Git GUI, donc je suis revenu à la ligne de commande pour le faire).

Un diagramme qui montre les différentes commandes Git pour diverses actions que vous pourriez vouloir entreprendre est celui-ci :

Answer 3

Il doit s'agir du fait que le commit est en avance sur votre push actuel.

1. git pull origin "nom de la branche que vous souhaitez push"

2. git rebase

   Si git rebase réussit, alors c'est bien. Sinon, vous devez résoudre tous les conflits de fusion localement et continuer jusqu'à ce que le rebase avec le distant réussisse.

3. git rebase --continue

Answer 4

Cela vient de m'arriver.

• J'ai fait une demande de tirage vers notre branche principale hier.
• Mon collègue l'a examinée aujourd'hui et a vu qu'elle n'était pas à jour avec notre branche principale, alors dans l'intention de m'aider, il a fusionné la branche principale avec ma branche.
• Je ne savais pas qu'il avait fait cela.
• Ensuite, j'ai fusionné la branche principale localement, j'ai essayé de la pousser, mais cela a échoué. Pourquoi? Parce que mon collègue a fusionné avec la branche principale en créant un commit supplémentaire que je n'avais pas en local !

Solution : Tirer ma propre branche pour obtenir ce commit supplémentaire. Puis la pousser vers ma branche distante.

Sur ma branche, j'ai littéralement fait :

git pull
git push

Answer 5

Dans mon cas, le dépôt distant avait déjà une branche portant le même nom que la branche de développement sur laquelle je travaillais. J'ai simplement renommé la branche et poussé le code. Cela a fonctionné pour moi.

git checkout -b nouveau-nom-de-branche
git push origin nouveau-nom-de-branche