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

У меня есть удаленный сервер gitosis и локальный репозиторий git, и каждый раз, когда я вношу большие изменения в свой код, я также нажимаю изменения на этом сервере.

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

PS: Это то, что отображает git при запуске ls-remote, я не уверен, помогает ли он

$ 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
152
задан ZelluX 16 июня '09 в 10:01
источник поделиться
14 ответов

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

Как в:

detached head

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

$ 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
190
ответ дан VonC 16 июня '09 в 10:32
источник поделиться

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

80
ответ дан Laz 19 мая '12 в 23:06
источник поделиться

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

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

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

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

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

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

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

26
ответ дан Chris Burbridge 11 апр. '11 в 22:54
источник поделиться

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

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

git push origin your-new-branch-name

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

23
ответ дан Roman Starkov 10 марта '15 в 19:32
источник поделиться

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

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

9
ответ дан camden 05 апр. '17 в 22:24
источник поделиться

См. ответ 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 прекратил говорить "все в актуальном состоянии" - и он переставал жаловаться на "быстрые форварды".

4
ответ дан user2079491 17 февр. '13 в 3:11
источник поделиться

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

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

2
ответ дан Srikanth Kyatham 27 июля '11 в 16:27
источник поделиться

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

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

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

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

git config http.postBuffer 524288000

2
ответ дан samwize 04 мая '13 в 10:06
источник поделиться

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

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

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

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

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

2
ответ дан Noah 02 июня '17 в 20:45
источник поделиться

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

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

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

0
ответ дан Asim K T 06 авг. '17 в 5:59
источник поделиться

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

0
ответ дан desmond 13 янв. '16 в 5:55
источник поделиться

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

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

0
ответ дан Kyle 20 июля '13 в 0:19
источник поделиться

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

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

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

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

0
ответ дан Elliotte Rusty Harold 24 сент. '16 в 20:00
источник поделиться

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

-2
ответ дан widdlepuke 27 апр. '17 в 17:27
источник поделиться

Другие вопросы по меткам