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

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

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

Un péché:

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

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!

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.

Mon problème était que ma branche locale avait un nom différent de la branche distante. J'ai pu pousser en faisant ce qui suit:

$ git push origin local-branch-name:remote-branch-name

(Crédit à https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/ )

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.

$ 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

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

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

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

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!

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.

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.

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

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:[email protected]:...
origin  ssh:[email protected]:...

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.

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'

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

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.

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.

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

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.

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.

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

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)

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.

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

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.

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