Git push говорит все актуальное, хотя у меня есть локальные изменения

Ответ 1

Вы не могли бы работать с отсоединенным голосом случайно?

Как в:

указывающий, что ваша последняя фиксация не является ветвью ветки.

$ 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>

Как упоминалось в git checkout странице руководства (выделено мной):

Иногда полезно иметь возможность проверять фиксацию, которая не находится на кончике одной из ветвей.
Наиболее очевидным примером является проверка фиксации в помеченной официальной точке выпуска, например:

$ git checkout v2.6.18

В более ранних версиях git этого не разрешалось и попросил создать временную ветку с помощью параметра -b, но начиная с версии 1.5.0 приведенная выше команда отделяет ваш HEAD от текущего ветвь и непосредственно указывает на фиксацию, названную тегом (v2.6.18 в приведенном выше примере).

Вы можете использовать все команды git, находясь в этом состоянии.
Вы можете использовать git reset --hard $othercommit для дальнейшего перемещения, например.
Вы можете вносить изменения и создавать новую фиксацию поверх отсоединенной HEAD.
Вы даже можете создать слияние с помощью git merge $othercommit.

Состояние, в котором вы находитесь, когда ваш HEAD отсоединен, не записывается ни одной веткой (что естественно - вы не находитесь в какой-либо ветке).
Это означает, что вы можете отменить свои временные коммиты и слияния, переключившись на существующую ветвь (например, git checkout master), а более поздняя git prune или git gc будет собирать мусор.
Если вы сделали это по ошибке, вы можете запросить reflog для HEAD, где вы были, например.

$ git log -g -2 HEAD

Ответ 2

Err.. Если вы git noob, вы уверены, что у вас есть git commit до git push? Я сделал эту ошибку в первый раз!

Ответ 3

Возможно, вы нажимаете новую локальную ветвь?

Новая локальная ветвь должна быть явно нажата:

git push origin your-new-branch-name

Только одна из этих вещей о git... Вы клонируете репо, создаете ветку, совершаете некоторые изменения, нажимаете... "Все в актуальном состоянии". Я понимаю, почему это происходит, но этот рабочий процесс крайне недружелюбен для новичков.

Ответ 4

Моя проблема заключалась в том, что мой локальный филиал имел другое имя, чем удаленная ветка. Я смог нажать, выполнив следующее:

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

(кредит https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/)

Ответ 5

Еще одна ситуация, которая важна для понимания: Тип состояния по умолчанию для git заключается в том, что вы работаете в ветке "master". И для многих ситуаций вы просто будете входить в это как свою основную рабочую ветвь (хотя некоторые люди получают фантазию и делают другие вещи).

Во всяком случае, это только одна ветка. Таким образом, ситуация, в которой я могу попасть, - это:

Моя активная ветвь фактически не является главной ветвью.... Но я обычно выполняю команду: git push (и ранее я сделал git push origin master, поэтому это ярлык для THAT).

Итак, я обычно нажимаю ведущую ветвь на общий репо... что, вероятно, является хорошей чистой вещью, в моем случае...

Но я забыл, что изменения, над которыми я работал, еще не вошли в мастер-ветку!!!

Поэтому каждый раз, когда я пытаюсь git push, я вижу "Все в актуальном состоянии", я хочу кричать, но, конечно, это не ошибка git! Это мое.

Поэтому вместо этого я объединяю свою ветку в мастер, а затем нажимаю, и все снова радует.

Ответ 6

$ git push origin local_branch:remote_branch

Объяснение

У меня была такая же ошибка & провел часы, пытаясь понять это. Наконец я нашел это. Чего я не знал, так это того, что нажатие git push origin branch-x попытается найти локальную ветвь-x, а затем нажать удаленную ветвь-x.

В моем случае у меня было два удаленных URL. Я сделал извлечение из branch-x в branch-y, когда пытался переместить с y локально на x remote. У меня было сообщение, что все обновлено, что является нормальным, потому что я нажимал на х второго пульта.

Короче говоря, чтобы не попасть в такую ловушку, вам нужно указать исходную ссылку и целевую ссылку:

$ git push origin local_branch:remote_branch

Обновление:

Если вам нужно запускать эту команду каждый раз, когда вы нажимаете на свою ветку, вам, возможно, потребуется установить восходящий поток между вашим локальным & удаленная ветка со следующим:

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

Или

$ git push -u origin local_branch:remote_branch

Ответ 7

См. ответ VonC выше - мне нужен дополнительный шаг:

$ 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>

Я сделал это, но когда я попытался git push remoterepo master, он сказал, что "Ошибка: не удалось нажать несколько ссылок. Чтобы вы не потеряли историю, обновления без быстрой пересылки были отклонены. Снова объедините удаленные изменения (например," git pull ").

Итак, я сделал git pull remoterepo master ', и он нашел конфликт. Я снова сделал git reset --hard <commit-id>, скопировал конфликтующие файлы в папку с резервной копией, снова сделал git pull remoterepo master, скопировал конфликтующие файлы обратно в мой проект, сделал git commit, затем git push remoterepo master, и на этот раз он сработал.

Git прекратил говорить "все в актуальном состоянии" - и он переставал жаловаться на "быстрые форварды".

Ответ 8

Я столкнулся с подобной ситуацией; когда я внес изменения и попытался git push origin master, он говорил, что все было в курсе.

Мне пришлось git add измененный файл, а затем git push origin master. С тех пор он начал работать.

Ответ 9

В вашем статусе git у вас, вероятно, есть другая ситуация. Моя работа.

Но так или иначе, вот что со мной произошло. Я столкнулся со следующей ошибкой:

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

Более информативное сообщение здесь заключается в том, что удаленный пользователь повесил трубку. Оказалось, это связано с превышением размера почтового буфера http. Решение состоит в том, чтобы увеличить его с помощью

git config http.postBuffer 524288000

Ответ 10

У меня была эта проблема сегодня, и она не имела никакого отношения к каким-либо другим ответам. Вот что я сделал и как я его исправил:

Недавно меня удалил репозиторий, но у меня была локальная копия. Я отделился от своей локальной "мастерской" ветки и внес некоторые изменения, а затем вспомнил, что хранилище переместилось. Я использовал git remote set-url origin https://<my_new_repository_url>, чтобы установить новый URL-адрес, но когда я его нажал, он просто сказал бы "Все в актуальном состоянии" вместо того, чтобы подталкивать мою новую ветвь к мастеру.

В итоге я решил его перезагрузить на origin/master, а затем нажав явные имена ветвей, например:

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

Я надеюсь, что это поможет любому, у кого была такая же проблема!

Ответ 11

Очень редко - но все же: в Windows может быть так, что упакованные ссылки имеют ветку с одним регистром букв (например, dev/mybranch), тогда как в папке refs есть другой регистр (например, dev/mybranch), когда для core.ignorecase установлено значение true,

Решение состоит в том, чтобы вручную удалить соответствующую строку из упакованных ссылок. Не нашел более чистого решения.

Ответ 12

Я столкнулся с этим сам, когда я объединил ветку на Гитубе и продолжал развиваться в ней локально. Мое исправление было немного иным, чем другие, которые были предложены.

Сначала я разветкил новую локальную ветку с моей старой локальной ветки (которую я не мог нажать). Затем я переместил новую локальную ветвь на исходный сервер (Github). То есть.

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

Это привело к появлению изменений в Github, хотя и в newlocalbranch, а не oldlocalbranch.

Ответ 13

В моем случае у меня было 2 удаленных РЕПО.

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

Оба репо были такими же. Только один был https другим был ssh. Так что удаляем ненужный (в моем случае ssh, так как я использовал https, потому что ssh не работает!) Исправил проблему для меня.

Ответ 14

Моя ошибка отличалась от всего, что упоминалось ранее. Если вы не знаете, почему у вас оторванная голова, то, вероятно, нет. Я работал на автопилоте с git commit и git push и не читал вывод git commit. Оказывается, это было сообщение об ошибке, потому что я забыл -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

-am это, поставив -am там, где я обычно делаю:

[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'

Ответ 15

Убедитесь, что вы не удалили свой удаленный URL.

Я просто хотел упомянуть, что я столкнулся с этим после включения Git в качестве CVS в локальной конфигурации сборки Jenkins. Похоже, что Дженкинс проверил самую последнюю фиксацию ветки, которую я ей дал, а также reset мой пульт, чтобы соответствовать путям, которые я дал ему в репо. Пришлось снова проверить мою ветку свойств и исправить исходный удаленный URL с 'git remote set-url'. Не указывайте инструмент сборки в рабочий каталог, иначе у вас будет плохое время. Мой пульт был установлен в путь к файлу моего рабочего каталога, поэтому он, естественно, сообщал обо всех актуальных моментах, когда я пытался нажимать изменения с тем же источником и местом назначения.

Ответ 16

Другая возможность заключается в том, что вы назвали каталог в вашем .gitignore файле, который был исключен. Таким образом, новые коммиты не будут толкаться. Случилось со мной, что я назвал каталог, чтобы игнорировать "поиск", но это также был каталог в моем исходном дереве.

Ответ 17

Я нашел быстрый способ. Перейдите в свою папку .git, откройте файл HEAD и измените любую ветвь, на которой вы были на сервере. Например. ref: refs/heads/master

Ответ 18

Я была такая же проблема. В моем случае это было вызвано необходимостью имен для одного и того же пульта. Он создал стандартную "origin", но я давно использовал "github" в качестве пульта, так что это тоже было там. Как только я удалил пульт "origin", ошибка исчезла.

Ответ 19

У меня было такое (коммиты в моем журнале git не были на GitHub, хотя git сказал, что все было в курсе), и я уверен, что проблема была в Github. Я не получил никаких сообщений об ошибках в git, но GitHub имел ошибки состояния, и мои коммиты были там через несколько часов.

https://status.github.com/messages

Сообщения о состоянии GitHub были:

• Мы расследуем сообщения о недоступности сервиса.
• Мы расследуем проблемы с доступом к GitHub.com.
• Мы отказываемся от системы хранения данных, чтобы восстановить доступ к GitHub.com.

Ответ 20

Еще одна очень простая, но нубийская ошибка: я просто забыл добавить модификатор сообщения -m в свой коммит. Итак, я написал:

git commit 'My message'

Вместо правильного:

git commit -m 'My message'

ПРИМЕЧАНИЕ: он не выдает никаких ошибок! Но вы не сможете выдвигать свои коммиты и всегда обновлять Everything up to date

Ответ 21

здесь мое решение отличается от вышеупомянутого. Я не понял, как эта проблема происходит, но я исправил ее. немного неожиданно.

теперь приходит путь:

$ 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: