git push dit "tout à jour" même si j'ai des changements locaux


238

J'ai un serveur de gitosis distant et un référentiel git local, et chaque fois que je fais un gros changement dans mon code, je vais pousser les changements sur ce serveur aussi.

Mais aujourd'hui, je trouve que même si j'ai des modifications locales et que je m'engage dans le référentiel local, lors de son exécution, git push origin masteril indique `` Tout à jour '', mais lorsque j'utilise git clonepour extraire des fichiers sur le serveur distant, il ne contient pas les dernières modifications. . Et je n'ai qu'une seule branche nommée "maître" et un serveur distant nommé "origine".

PS: c'est ce que git affiche lors de l'exécution ls-remote, je ne sais pas si cela aide

$ git ls-remote origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/remotes/origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c        refs/tags/stage3


Vaut la peine de vérifier que vous êtes dans le bon répertoire! Esp. lorsque vous avez des sous-modules, vous pouvez confondre les réponses git du parent ..
geotheory

Dans mon cas, j'obtenais une erreur pendant commitlaquelle je n'ai pas remarqué et j'ai essayé de pousser le code
Zohab Ali

3
oublié de vous engager?
ldgorman

Réponses:


256

Travaillez-vous avec une tête détachée par hasard?

Un péché:

tête détachée

indiquant que votre dernier commit n'est pas un chef de branche.

Attention : ce qui suit fait git reset --hard: assurez-vous d'utiliser d' git stashabord si vous souhaitez enregistrer vos fichiers actuellement modifiés.

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

Comme mentionné dans la git checkoutpage de manuel (soulignement le mien):

Il est parfois utile de pouvoir extraire un commit qui n'est pas à la pointe d'une de vos branches .
L'exemple le plus évident est de vérifier le commit à un point de sortie officiel balisé, comme ceci:

$ git checkout v2.6.18

Les versions antérieures de git ne le permettaient pas et vous ont demandé de créer une branche temporaire à l'aide de l' -boption, mais à partir de la version 1.5.0, la commande ci-dessus détache votre HEADde la branche actuelle et pointe directement sur le commit nommé par la balise ( v2.6.18dans le exemple ci-dessus).

Vous pouvez utiliser toutes les commandes git dans cet état.
Vous pouvez utiliser git reset --hard $othercommitpour vous déplacer plus loin, par exemple.
Vous pouvez apporter des modifications et créer un nouveau commit au-dessus d'un HEAD détaché .
Vous pouvez même créer une fusion à l'aide de git merge $othercommit.

L'état dans lequel vous vous trouvez lorsque votre HEAD est détaché n'est enregistré par aucune branche (ce qui est naturel --- vous n'êtes sur aucune branche).
Ce que cela signifie, c'est que vous pouvez annuler vos validations et fusions temporaires en revenant à une branche existante (par exemple git checkout master), et plus tard, git pruneou git gcles récupérerait.
Si vous avez fait cela par erreur, vous pouvez demander au reflog de HEAD où vous étiez, par exemple

$ git log -g -2 HEAD

4
Ce n'est pas tout à fait clair pour moi comment je suis entré dans cet état (faire du déblayage avec git-svn pour le moment), mais cela a suffi pour me ramener au bon endroit. Merci.
Christopher Schmidt

Je suis dans un état de tête détaché, j'ai fusionné mes changements, engagé mes changements et maintenant je veux pousser cela au Maître et ne peux pas - me dit "tout à jour". Mais je suis les instructions fournies par mon Gitlab: Step 1: git fetch origin git checkout -b "nodeAPI" "origin/nodeAPI" Step 2. Review the changes locally Step 3. Merge and fix conflicts git fetch origin git checkout "origin/master" git merge --no-ff "nodeAPI" Step 4. Push the result of the merge to GitLab git push origin "master" je suis bon jusqu'à la dernière étape. Mais maintenant, je ne sais plus comment aller de l'avant.
John

@John Vous devez être dans une branche pour pousser. Tant que vous êtes en mode HEAD détaché, cela ne fonctionnera pas. Réinitialisez votre succursale à l'endroit où vous vous trouvez git branch -f myBranch HEAD:, puis vérifiez ladite succursale et appuyez dessus. Dans votre cas, myBranchpeut-être mastersi vous étiez en train de fusionner nodeAPI.
VonC

Attention à ne pas perdre toutes les modifications locales après avoir exécuté cette commande !! Pensez à faire une sauvegarde de git stash et de code avant de faire quelque chose comme ça.
kta

@kta Bon point: j'ai modifié la réponse pour rendre cet avertissement visible.
VonC

152

Euh .. Si vous êtes un git noob, êtes-vous sûr que vous l'avez git commitdéjà fait git push? J'ai fait cette erreur la première fois!


10
C'était git commit -a -m "your message goes here"dans mon cas
aexl

J'AIME (sarcasme) chaque fois que je veux ajouter un nouveau projet à un github que j'oublie parfois et le message d'erreur me fait penser que j'ai fait quelque chose de vraiment mal - alors bien sûr DUH! commit ne m'arrive que lorsque je suis créé de nouveaux référentiels de sauvegarde et que j'oublie
Tom Stickel

git noob here - j'oublie de m'engager à chaque fois avant de pousser - pousser devrait automatiquement s'engager si vous ne l'avez pas fait auparavant
FoxMcCloud

2
@FoxMcCloud commiting est une étape importante pour être conscient, je suis sûr que vous allez apprendre à l' aimer si vous avez pas déjà :) ~ git add -A, git diff --staged, fait défiler les changements Hmm très bon augure, git commit -m 'bam!',git push
AFOC

58

Vous proposez peut-être une nouvelle succursale locale?

Une nouvelle branche locale doit être poussée explicitement:

git push origin your-new-branch-name

Juste une de ces choses à propos de git ... Vous clonez un repo, faites une branche, commettez quelques changements, poussez ... "Tout est à jour". Je comprends pourquoi cela se produit, mais ce flux de travail est extrêmement hostile aux nouveaux arrivants.


3
Merci! Cela a résolu mon problème "tout à jour" avec une nouvelle branche que j'avais
Pangu

Que diable entend-on par "votre-nouveau-nom-de-succursale"? Ps: Vous avez tellement raison sur les nouveaux arrivants.
www-0av-Com du

@ user1863152 est le nom de la nouvelle branche locale que vous avez créée. On dirait que vous ne l'avez pas fait, alors vérifiez les autres réponses ici.
Roman Starkov

Tout à fait d'accord avec "ce flux de travail est extrêmement hostile aux nouveaux arrivants". Je lutte avec cela depuis 1 heure. J'ai configuré le dépôt à distance et local. Apporté des modifications au fichier REAME local et essayez de le pousser vers la télécommande et rien ne change dans la télécommande.
Vir


28

Une autre situation qu'il est important de connaître: Le type d'état par défaut pour git est que vous travaillez dans la branche "master". Et pour beaucoup de situations, vous vous contenterez de rester votre principale branche de travail (bien que certaines personnes aient envie de faire d'autres choses).

Quoi qu'il en soit, ce n'est qu'une branche. Donc, une situation dans laquelle je pourrais entrer est:

Ma branche active n'est en fait PAS la branche principale. ... Mais je fais habituellement la commande: git push(et je l'avais déjà fait git push origin master, c'est donc un raccourci pour CELA).

Donc je pousse habituellement la branche master vers le repo partagé ... ce qui est probablement une bonne chose propre, dans mon cas ...

Mais j'ai oublié que les changements sur lesquels je travaille ne sont pas encore DANS la branche master !!!

Donc donc à chaque fois que j'essaye git push, et que je vois "Tout à jour", j'ai envie de crier, mais bien sûr, ce n'est pas la faute de git! C'est à moi.

Au lieu de cela, je fusionne ma branche en maître, puis je pousse, et tout est à nouveau heureux.


Je voulais aussi crier, mais ensuite, vous avez prêché le chemin du salut, fusionner le brant en maître, et puis git push.
Aaron C

16
$ git push origin local_branch:remote_branch

Explication

J'ai eu la même erreur et j'ai passé des heures à essayer de le comprendre. Finalement, je l'ai trouvé. Ce que je ne savais pas, c'est que pousser comme ça git push origin branch-xva essayer de rechercher branch-x localement puis de pousser vers branch-x distant.

Dans mon cas, j'avais deux URL distantes. J'ai effectué une vérification de la branche-x à la branche-y lorsque j'essayais de passer de y localement à x distant. J'ai eu le message que tout est à jour, ce qui est normal car je poussais vers x de la deuxième télécommande.

En bref, pour ne pas tomber dans ce type de piège, vous devez spécifier la référence source et la référence cible:

$ git push origin local_branch:remote_branch

Mettre à jour:

Si vous devez exécuter cette commande à chaque fois que vous appuyez sur votre branche, vous devrez peut-être définir l'amont entre votre branche locale et distante avec les éléments suivants:

$ git push --set-upstream origin local_branch:remote_branch

Ou

$ git push -u origin local_branch:remote_branch

'git push upstream dev: master' Cela signifie qu'il poussera la source de dev vers master. Droite?
Dhaduk Mitesh

Cela m'a aidé, j'avais une autre branche locale nommée branche distante, ce qui a causé de la confusion.
Hubert Kubiak

Ok, ça marche vraiment pour moi mais je dois le faire chaque fois que je veux pousser quelque chose vers la télécommande. Comment puis-je le réparer une fois pour toutes?
SamuraiJack

vous devrez peut-être définir l'amont entre votre branche locale et distante avec ce qui suit: $ git push --set-upstream origin local_branch: remote_branch
Melchia

6

Voir la réponse de VonC ci-dessus - j'avais besoin d'une étape supplémentaire:

$ git log -1
- note the SHA-1 of latest commit
$ git checkout master
- reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

J'ai fait cela, mais quand j'ai ensuite essayé git push remoterepo master, il a dit "erreur: n'a pas réussi à pousser certaines références. Pour vous empêcher de perdre l'historique, les mises à jour non rapides ont été rejetées, Fusionnez les modifications à distance (par exemple 'git pull') avant poussant à nouveau. "

J'ai donc fait «git pull remoterepo master», et cela a trouvé un conflit. Je l'ai fait à git reset --hard <commit-id>nouveau, j'ai copié les fichiers en conflit dans un dossier de sauvegarde, je l'ai fait à nouveau, j'ai git pull remoterepo masterrecopié les fichiers en conflit dans mon projet git commit, puis git push remoterepo master, et cette fois, cela a fonctionné.

Git a cessé de dire "tout est à jour" - et a cessé de se plaindre des "avancées rapides".


3

J'ai fait face à une situation similaire; lorsque j'ai apporté les modifications et essayé git push origin master, cela disait que tout était à jour.

Je devais git addle fichier modifié et puis git push origin master. Il a commencé à fonctionner à partir de là.


4
N'auriez-vous pas besoin de git commitce fichier ajouté avant de pousser?
David Harkness

3

De votre statut git, vous avez probablement une situation différente de la mienne.

Mais de toute façon, voici ce qui m'est arrivé .. J'ai rencontré l'erreur suivante:

fatal: The remote end hung up unexpectedly
Everything up-to-date

Le message le plus informatif ici est que la télécommande a raccroché. Il s'est avéré que cela est dû au dépassement de la taille du tampon de publication http. La solution est de l'augmenter avec

git config http.postBuffer 524288000


3

J'ai eu ce problème aujourd'hui et cela n'a rien à voir avec les autres réponses. Voici ce que j'ai fait et comment je l'ai corrigé:

Un de mes dépôts a récemment déménagé, mais j'avais une copie locale. Je me suis éloigné de ma branche "maître" locale et j'ai apporté quelques modifications - puis je me suis souvenu que le référentiel avait été déplacé. J'avais l'habitude git remote set-url origin https://<my_new_repository_url>de définir la nouvelle URL, mais lorsque je poussais, elle disait simplement "Tout à jour" au lieu de pousser ma nouvelle branche vers master.

J'ai fini par le résoudre en rebasant origin/masterpuis en poussant avec des noms de branche explicites, comme ceci:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

J'espère que cela aide toute personne qui a eu mon même problème!


3

Super rare - mais toujours: Sous Windows, il se pourrait que -refs emballés possède une succursale avec un cas de lettre (c. -à- dev / mybranch), tandis que refs le dossier a un autre cas (c. -à- Dev / mybranch) lorsque core.ignorecase est à true .

La solution consiste à supprimer manuellement la ligne appropriée des références emballées . Je n'ai pas trouvé de solution plus propre.


C'était aussi un problème pour moi. Vous avez fini par renommer des dossiers avec une casse incorrecte dans le dossier .git (journaux / références / têtes, références / têtes).
Alexey Solonets

2

Je suis tombé dessus moi-même lorsque j'ai fusionné une succursale sur Github et continué à y développer localement. Ma solution était un peu différente des autres qui ont été suggérées.

J'ai d'abord créé une nouvelle branche locale à partir de mon ancienne branche locale (que je ne pouvais pas pousser). Ensuite, j'ai poussé la nouvelle branche locale vers le serveur d'origine (Github). C'est à dire

$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch

Cela a fait apparaître les changements sur Github, bien que dans newlocalbranch plutôt que dans oldlocalbranch.


2

Dans mon cas, j'avais 2 dépôts distants.

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:git@bitbucket.org:...
origin  ssh:git@bitbucket.org:...

Les deux repo étaient identiques. Un seul était un httpsautre ssh. Donc, supprimer celui qui n'était pas souhaité (dans mon cas, sshcar je l'ai utilisé httpsparce que sshne fonctionnait pas!) A résolu le problème pour moi.


2

Mon erreur était différente de tout ce qui a été mentionné jusqu'ici. Si vous ne savez pas pourquoi vous auriez une tête détachée, vous ne l'avez probablement pas. Je travaillais sur le pilote automatique avec git commitet git push, et je n'avais pas lu la sortie de git commit. Il s'avère que c'était un message d'erreur car j'ai oublié -am.

[colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git.
[colin] ~/github/rentap.js [master] M % git push
Enter passphrase for key '/home/colin/.ssh/id_ecdsa': 
Everything up-to-date

Corrigé en mettant -amoù je fais d'habitude:

[colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'

2

J'ai rencontré le même problème. Comme je n'ai pas ajouté de modifications à la zone de transit. Et j'ai directement essayé de pousser le code vers un dépôt à distance en utilisant la commande:

git push origin master

Et cela montre le message Everything up-to-date.

pour résoudre ce problème, essayez ces étapes

  1. git add .
  2. git commit -m "Bug Fixed"
  3. git push -u origin master

1

Vérifiez que vous n'avez pas gâché votre URL distante.

Je voulais juste mentionner également que j'ai rencontré cela après avoir activé Git en tant que CVS dans une configuration de build Jenkins locale. Il semble que Jenkins a vérifié le dernier commit de la branche que je lui ai donnée et a également réinitialisé ma télécommande pour correspondre aux chemins que je lui ai donnés pour le dépôt. J'ai dû reprendre ma branche de fonctionnalité et corriger mon URL distante d'origine avec 'git remote set-url'. N'allez pas pointer un outil de construction vers votre répertoire de travail ou vous passerez un mauvais moment. Ma télécommande a été définie sur un chemin de fichier vers mon répertoire de travail, il a donc naturellement signalé tout à jour lorsque j'ai essayé de pousser les modifications avec la même source et destination.


1

Une autre possibilité est que vous ayez nommé un répertoire dans votre fichier .gitignore qui a été exclu. Les nouveaux commits ne seraient donc pas poussés. Il m'est arrivé que j'ai nommé un répertoire pour ignorer "recherche", mais c'était aussi un répertoire dans mon arbre source.


1

Il y a un moyen rapide que j'ai trouvé. Accédez à votre dossier .git, ouvrez le HEADfichier et changez la branche sur laquelle vous vous trouviez pour le master. Par exemple, ref:refs/heads/master


En fait, il a refs/heads/mastercassé mon référentiel. Mais la mise à ce que je pensais être la tête allouent a donné le message suivant: Warning: you are leaving 1 commit behind, not connected to any of your branches. J'ai pu reprendre le commit dans une nouvelle branche et le fusionner de nouveau au maître.
schmijos

1

J'ai eu le même problème. Dans mon cas, cela a été dû au fait d'avoir à nommer la même télécommande. Cela a créé l '«origine» standard, mais j'utilise depuis longtemps «github» comme télécommande, donc c'était là aussi. Dès que j'ai retiré la télécommande «origine», l'erreur a disparu.


1

Je l'ai fait (les commits dans mon journal git n'étaient pas sur GitHub même si git a dit que tout était à jour) et je suis convaincu que le problème était Github. Je n'ai reçu aucun message d'erreur dans git, mais GitHub a eu des erreurs de statut et mes commits étaient là plusieurs heures plus tard.

https://status.github.com/messages

Les messages d'état GitHub étaient:

  • Nous enquêtons sur les rapports d'indisponibilité de service.
  • Nous étudions les problèmes d'accès à GitHub.com.
  • Nous basculons sur un système de stockage de données afin de restaurer l'accès à GitHub.com.

1

Une autre erreur très simple mais noobish de ma part: j'ai simplement oublié d'ajouter un -mmodificateur de message dans mon commit. J'ai donc écrit:

git commit 'My message'

Au lieu de corriger:

git commit -m 'My message'

REMARQUE: il ne génère aucune erreur! Mais vous ne pourrez pas pousser vos commits et toujours obtenir à la Everything up to dateplace


0

ici, ma solution est différente de la précédente. je n'ai pas compris comment ce problème se produit, mais je l'ai résolu. un peu de façon inattendue.

vient maintenant:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

la commande qui fonctionne pour moi est

$git push origin HEAD:use_local_cache

(J'espère que vous sortirez de ce problème le plus tôt possible)


0

Je sais que c'est super ancien, mais dans mon cas, je l'ai réparé assez rapidement.

J'obtenais cette même erreur tout en étant un commit d'avance master. Ensuite, j'ai trouvé le message Stack Overflow actuel. Cependant, avant de poursuivre avec les idées suggérées, j'ai juste décidé de faire un nouveau commit et d'essayer à nouveau avec le push to origin et cela a fonctionné en douceur.

Je ne sais pas pourquoi, mais c'est peut-être utile pour quelqu'un d'autre.


Il ne fournit pas réellement de réponse à la question. Une fois que vous gagnez assez réputation , vous gagnerez des privilèges à Upvote réponses que vous aimez. De cette façon, les futurs visiteurs de la question verront un nombre de votes plus élevé sur cette réponse, et le répondeur sera également récompensé par des points de réputation. Voir Pourquoi le vote est-il important .
Waqar UlHaq

1
Ok, merci pour la clarification. Mais pourquoi ne peut-il pas être considéré (si vous le souhaitez) comme une «solution de contournement» au problème? Ce n'est pas la solution, mais elle peut être utile à d'autres de toute façon.
Cisco

0

Une autre possibilité est que vous ayez des commits qui n'affectent pas le répertoire que vous poussez. Donc dans mon cas, j'avais une structure comme

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

Et je me suis engagé à maîtriser la modification README.md, puis git subtree push --prefix client heroku-client masterj'ai couru et j'ai reçu le messageEverything up-to-date


0

Je travaillais avec Jupyter-Notebook lorsque j'ai rencontré cette erreur trompeuse.

Je n'ai pas pu résoudre les problèmes ci-dessus car je n'avais ni tête détachée ni noms différents pour mon référentiel local et distant .

Mais ce que je n'ai été ma taille de fichier ont été légèrement supérieure à 1 Mo et le plus grand était presque ~ 2MB . J'ai réduit la taille du fichier à l'aide de Comment puis-je réduire la taille du fichier de mon bloc-notes iPython?technique. Cela a aidé à réduire la taille de mon fichier en effaçant les sorties. J'ai pu pousser le code, désormais car il a apporté ma taille de fichier en Ko.


0

Nous devons ajouter les fichiers et valider les fichiers déjà modifiés / ajoutés exécuter les commandes ci-dessous

git add. ou git add nameoffile #it ajoutera les fichiers existants dans le projet

git commit -m "first commit" # commit tous les fichiers du projet

git push origin master

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.