git Push dit tout à jour même si j'ai des changements locaux
J'ai un serveur gitosis distant et un référentiel git local, et chaque fois que je modifie mon code de façon importante, je transmettrai également les modifications à ce serveur.
Mais aujourd’hui, je constate que, même si j’ai des modifications locales et que je m’engage dans un référentiel local, lors de l’exécution de maître d’origine git Push, il est indiqué "Toutes les mises à jour", mais lorsque j’utilise git clone pour extraire les fichiers sur le serveur distant, il ne contient pas les dernières modifications. Et je n'ai qu'une branche nommée maître et un seul serveur distant nommé Origin.
PS: Voici ce que git affiche lors de l'exécution de ls-remote, je ne suis pas sûr que 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
Vous ne voudriez pas travailler avec un tête détachée par hasard?
Un péché:
indiquant que votre dernier commit n'est pas une tête de branche.
$ 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 indiqué dans la git checkout page de manuel (emphase mienne):
Il est parfois utile de pouvoir extraire un commit qui ne se trouve pas à l'extrémité de l'une de vos branches .
L’exemple le plus évident est de vérifier le commit à un point de sortie officiel marqué, 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'option
-b, mais à partir de la version 1.5.0, la commande ci-dessus détache votreHEADde la branche courante et pointe directement sur la validation nommée par la balise (v2.6.18dans l'exemple ci-dessus).Vous pouvez utiliser toutes les commandes git dans cet état.
Vous pouvez utilisergit reset --hard $othercommitpour continuer à vous déplacer, par exemple.
Vous pouvez apporter des modifications et créer un nouveau commit sur une HEAD séparée .
Vous pouvez même créer une fusion en utilisantgit merge $othercommit.L’état dans lequel vous vous trouvez alors que votre HEAD est détaché n’est enregistré par aucune branche (ce qui est naturel - vous n’êtes sur aucune branche).
Cela signifie que vous pouvez ignorer vos validations et fusions temporaires en basculant vers une branche existante (par exemple,git checkout master), et ungit Pruneougit gcultérieur les récupérerait.
Si vous avez fait cela par erreur, vous pouvez demander au reflog pour HEAD où vous étiez, par exemple.
$ git log -g -2 HEAD
Euh .. Si vous êtes un noit git, êtes-vous sûr d'avoir git commit avant git Push? J'ai fait cette erreur la première fois!
Peut-être que vous poussez une nouvelle branche 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, validez des modifications, Push ... "Tout est à jour". Je comprends pourquoi cela se produit, mais ce flux de travail est extrêmement hostile pour les nouveaux arrivants.
Mon problème était que ma branche locale avait un nom différent de celui de la branche distante. J'ai pu pousser en procédant comme suit:
$ git Push Origin local-branch-name:remote-branch-name
(Nous remercions 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 dans de nombreuses situations, vous y resterez comme branche principale (bien que certaines personnes aient l’impression d’agir et fassent autre chose).
Quoi qu'il en soit, ce n'est qu'une branche. Donc, une situation dans laquelle je pourrais entrer est la suivante:
Ma branche active n'est en réalité PAS la branche principale. ... Mais je fais habituellement la commande: git Push (et j'avais déjà fait git Push Origin master, alors c'est un raccourci pour CELA).
Je pousse donc habituellement la branche principale vers le dépôt partagé ... ce qui est probablement une bonne chose de propre, dans mon cas ...
Mais j'ai oublié que les changements sur lesquels je travaillais ne sont pas encore DANS la branche maître !!!
Donc donc à chaque fois que j'essaie git Push, et que je vois "Tout est à jour", j'ai envie de crier, mais bien sûr, ce n'est pas la faute de git! C'est à moi.
Alors au lieu de cela, je fusionne ma branche en maître, puis je fais du Push, 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 comprendre. Finalement, je l'ai trouvé. Ce que je ne savais pas, c'est que le fait de pousser comme ceci git Push Origin branch-x tentera de rechercher localement une branche-x puis de pousser vers une branche distante.
Dans mon cas, j'avais deux URL distantes. J'ai fait une commande de branche-x à branche-y en essayant de pousser de y localement vers x distant, j'avais le message que tout est à jour, ce qui est normal car je poussait à x de la deuxième télécommande.
Longue histoire courte pour ne pas tomber dans ce genre de piège, vous devez spécifier le ref source et le ref cible:
$ git Push 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>
Je l'ai fait, mais quand j'ai ensuite essayé de git Push remoterepo master, il a dit "erreur: échec de l'envoi de certaines références. Pour vous éviter de perdre l'historique, des mises à jour non avancées ont été rejetées, Fusionner les modifications distantes (par exemple," git pull ") avant d'appuyer à nouveau."
Alors j'ai fait 'git pull remoterepo master', et ça a trouvé un conflit. J'ai refait git reset --hard <commit-id>, copié les fichiers en conflit dans un dossier de sauvegarde, puis git pull remoterepo master, copié les fichiers en conflit dans mon projet, fait git commit, puis git Push remoterepo master, et cette fois cela a fonctionné.
Git a cessé de dire "tout est à jour" - et il ne s'est plus plaint des "avancées rapides".
J'ai eu ce problème aujourd'hui et cela n'avait 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 séparé de ma branche "maître" locale et ai apporté quelques modifications - puis je me suis rappelé que le référentiel avait été déplacé. J'ai utilisé git remote set-url Origin https://<my_new_repository_url> pour définir la nouvelle URL, mais lorsque je l'ai poussé, il ne faisait que mentionner "Tout à jour" au lieu de pousser ma nouvelle branche à maîtriser.
J'ai fini par le résoudre en rebasonnant sur Origin/master puis en poussant avec des noms de branches explicites, comme ceci:
$ git rebase <my_branch> Origin/master
$ git Push Origin <my_branch>
J'espère que cela aide tous ceux qui ont eu le même problème!
De par votre statut de git, vous avez probablement une situation différente de la mienne.
Quoi qu'il en soit, 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 est que la télécommande a raccroché. En fait, cela est dû au dépassement de la taille du tampon post-http. La solution consiste à l'augmenter avec
git config http.postBuffer 524288000
J'ai fait face à une situation similaire; Quand j'ai fait les modifications et essayé de git Push Origin master, il disait que tout était à jour.
Je devais git add le fichier modifié, puis git Push Origin master. Cela a commencé à fonctionner à partir de là.
Super rare - mais quand même: Sous Windows, il se peut que emballé-refs ait une branche avec une casse de lettre (c'est-à-dire dev/mybranch), tandis que refs dossier a un autre cas (c.-à-d. Dev/mybranch) lorsque core.ignorecase est défini sur true.
La solution consiste à supprimer manuellement la ligne correspondante de hidden-refs. Je n'ai pas trouvé de solution plus propre.
Mon erreur était différente de tout ce qui a été mentionné jusqu'à présent. Si vous ne savez pas pourquoi vous auriez une tête détachée, alors vous n'en avez probablement pas. Je travaillais sur le pilote automatique avec git commit et git Push, et je n'avais pas lu le résultat de git commit. Il s'est avéré que c'était un message d'erreur parce que 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 -am où je fais habituellement:
[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'
Dans mon cas, j'ai eu 2 repos à distance.
git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
Origin ssh:[email protected]:...
Origin ssh:[email protected]:...
Les deux repo était la même. Un seul était https l'autre était ssh. Donc, supprimer le plus indésirable, (dans mon cas ssh. Depuis que j'ai utilisé https parce que ssh ne fonctionnait pas!), Le problème a été résolu pour moi.
Je me suis heurté à cela quand j'ai fusionné une branche sur Github et que j'ai continué à me 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 sur le serveur Origin (Github). C'est à dire.
$ git checkout -b newlocalbranch oldlocalbranch
$ git Push Origin newlocalbranch
Cela a amené les changements à apparaître sur Github, bien que dans newlocalbranch plutôt que oldlocalbranch.
Une autre possibilité est que vous ayez nommé un répertoire dans votre fichier .gitignore qui a été exclu. Donc, les nouveaux commits ne seraient pas poussés. Il m'est arrivé de nommer un répertoire pour ignorer "recherche", mais c'était également un répertoire dans mon arbre source.
Vérifiez que vous n'avez pas gaffé votre URL distante.
Je voulais simplement mentionner que je me suis heurté à cette situation après avoir activé Git en tant que CVS dans une configuration de construction Jenkins locale. Il semble que Jenkins ait vérifié la dernière mise à jour de la branche que je lui ai donnée et réinitialisé ma télécommande pour qu'elle corresponde aux chemins que je lui ai donnés. J'ai dû vérifier à nouveau ma branche de fonctionnalités et réparer mon adresse URL d'origine avec "git remote set-url". Ne pointez pas un outil de construction sur votre répertoire de travail, sinon vous passerez un mauvais moment. Ma télécommande était définie sur un chemin de fichier menant à mon répertoire de travail. Elle a donc naturellement tout mis à jour lorsque j'ai tenté d'insérer des modifications avec les mêmes sources et destinations.
C'est ce qui m'est arrivé (les commits de mon journal git n'étaient pas sur GitHub, bien que git ait 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 présentait des erreurs d'état et mes validations y étaient quelques heures plus tard.
https://status.github.com/messages
Les messages d'état de GitHub étaient:
- Nous enquêtons sur des rapports d'indisponibilité du service.
- Nous enquêtons sur les problèmes d'accès à GitHub.com.
- Nous échouons sur un système de stockage de données afin de restaurer l'accès à GitHub.com.
Il y a un moyen rapide que j'ai trouvé. Allez dans votre dossier .git, ouvrez le fichier HEAD et changez la branche que vous étiez sur dos. Par exemple. ref: refs/heads/master
J'ai eu le même problème. Dans mon cas, cela était dû à des noms pour la même télécommande. Il a créé le standard 'Origin', mais j'utilise depuis longtemps 'github' comme télécommande, alors c'était là aussi. Dès que j'ai enlevé la télécommande 'Origin', l'erreur a disparu.
Une autre erreur très simple mais néanmoins noble: j’ai simplement oublié d’ajouter un message -m modificateur dans mon commit. Alors j'ai écrit:
git commit 'My message'
Au lieu de corriger:
git commit -m 'My message'
NOTE: Il ne jette aucune erreur! Mais vous ne pourrez pas pousser vos commits et toujours obtenir Everything up to date à la place