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



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



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



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
3080   18  

18 ответов:

вы не будете работать с отрезанная голова случайно ?

в:

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 не позволяли этого и просили Вас создать временную ветку с помощью , но начиная с версии 1.5.0, приведенная выше команда отсоединяет ваш HEAD из текущей ветви, и прямо указывает на совершение им тег (v2.6.18 в примере выше).

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

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

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

может быть, вы толкаете новый местный филиал?

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

git push origin your-new-branch-name

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

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

в любом случае, это только одна ветвь. Поэтому ситуация, в которую я могу попасть, такова:

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

поэтому я обычно толкаю главную ветвь к общему РЕПО ... что, вероятно, хорошая чистая вещь, в моем случае ...

но я забыл, что изменения, над которыми я работал, еще не находятся в главной ветке !!!

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

поэтому я слить мою ветку в мастер, а затем сделать толчок, и все снова счастливы.

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

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

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

$ git push origin local_branch:remote_branch

объяснение

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

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

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

$ git push origin local_branch:remote_branch

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

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

из вашего статуса git у вас, вероятно, другая ситуация, чем у меня.

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

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

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

git config http.postBuffer 524288000

у меня была эта проблема сегодня, и она не имела ничего общего с любым из других ответов. Вот что я сделал и как я это исправил:

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

I в конечном итоге решить его путем перебазирования на origin/master а затем нажимать с явными именами ветвей, например:

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

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

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

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

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

моя ошибка отличалась от всего, что до сих пор упоминалось. Если вы не знаете, почему вы бы отрезанная голова, то вы, вероятно, не. Я работал на автопилоте с git commit и git push, и не читал выход из git commit. Оказывается, это было сообщение об ошибке, потому что я забыл -я.

[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 где я обычно делаю:

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

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

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

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

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

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

это заставило изменения появиться на Github, хотя и в newlocalbranch, а не в oldlocalbranch.

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

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

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

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

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

Comments

    Ничего не найдено.