Git Push говорит, что все в курсе, хотя у меня есть локальные изменения
У меня есть удаленный сервер Gitosis и локальный репозиторий Git, и каждый раз, когда я делаю большие изменения в своем коде, я также отправляю изменения на этот сервер.
Но сегодня я обнаружил, что, хотя у меня есть некоторые локальные изменения и коммит в локальный репозиторий, при запуске git push origin master он говорит "Все актуально", но когда я использую git clone для извлечения файлов на удаленном сервере, он не содержит последних изменений. И у меня есть только одна ветка с именем 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
36 ответов
Вы не будете работать с отстраненной головой случайно?
Как в:
показывая, что ваш последний коммит не является веткой ветки.
$ 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 Страница man (выделено мной):
Иногда полезно иметь возможность извлекать коммит, который не находится на кончике одной из ваших веток.
Самый очевидный пример - проверить коммит в официальной точке релиза с тегом, например так:
$ 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
Эээ.. Если ты мерзавец, ты уверен, что у тебя есть git commit до git push? Я сделал эту ошибку в первый раз!
Может быть, вы продвигаете новую местную ветку?
Новая локальная ветвь должна быть выдвинута явно:
git push origin your-new-branch-name
Просто одна из тех вещей, связанных с 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/)
$ git push origin local_branch:remote_branch
объяснение
У меня была та же ошибка, и я часами пытался ее выяснить. Наконец я нашел это. Чего я не знал, так это толкания git push origin branch-x попытается найти ответвление x локально, а затем нажать на удаленный ответвление x.
В моем случае у меня было два удаленных URL. Я сделал проверку от Branch-X до Branch-Y, когда пытался передать с локального Y на удаленный X Я получил сообщение, что все в порядке, что является нормальным, потому что я нажимал на X второго пульта.
Короче говоря, чтобы не попасть в эту ловушку, вам нужно указать исходную ссылку и целевую ссылку:
$ git push origin local_branch:remote_branch
Еще одна важная ситуация, о которой необходимо знать: тип состояния по умолчанию для git - это то, что вы работаете в ветке "master". И для многих ситуаций вы будете просто тусоваться в этом как ваша основная рабочая ветвь (хотя некоторые люди увлекаются и занимаются другими делами).
Во всяком случае, это только одна ветвь. Таким образом, ситуация, в которую я могу попасть:
Моя активная ветвь на самом деле НЕ является основной ветвью.... но я обычно делаю команду git push (и я ранее сделал git push origin masterтак что это ярлык для ТО).
Поэтому я обычно помещаю ветку master в общий репозиторий... что в моем случае, вероятно, очень хорошая вещь...
Но я забыл, что изменения, над которыми я работал, еще не в ветке master!!!
Поэтому каждый раз, когда я пытаюсь git pushи я вижу "Все в курсе", я хочу кричать, но, конечно, это не вина GIT! Это мое.
Вместо этого я объединяю свою ветку с мастером, а затем делаю push, и все снова становится счастливым.
Я столкнулся с такой же проблемой. Поскольку я не вносил изменений в область подготовки. И я напрямую попытался отправить код в удаленное репо с помощью команды:
git push origin master
И показывает сообщение Everything up-to-date.
чтобы решить эту проблему, попробуйте следующие шаги
git add .git commit -m "Bug Fixed"git push -u origin master
Смотрите ответ 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и на этот раз это сработало.
Гит перестал говорить "все актуально" - и перестал жаловаться на "быстрые форварды".
Еще одна очень простая, но нубийская ошибка: я просто забыл добавить сообщение -m Модификатор в моем коммите. Итак, я написал:
git commit 'My message'
Вместо правильного:
git commit -m 'My message'
ПРИМЕЧАНИЕ: он не выдает никаких ошибок! Но вы не сможете выдвигать свои коммиты и всегда получать Everything up to date вместо
Я столкнулся с подобной ситуацией; когда я внес изменения и попытался git push origin masterбыло сказано, что все было в курсе.
Мне пришлось git add измененный файл, а затем git push origin master, Это начало работать с тех пор.
Очень редко - но все же: в Windows может быть так, что упакованные ссылки имеют ветку с одним регистром букв (например, dev/mybranch), в то время как в папке refs есть другой регистр (то есть dev/mybranch), когда для core.ignorecase установлено значение true,
Решение состоит в том, чтобы вручную удалить соответствующую строку из упакованных ссылок. Не нашел более чистого решения.
У меня была эта проблема сегодня, и она не имела ничего общего с другими ответами. Вот что я сделал и как я это исправил:
Мой репозиторий недавно переехал, но у меня была локальная копия. Я разветвлялся из своей локальной "главной" ветки и внес некоторые изменения, а затем вспомнил, что хранилище перенесено. я использовал git remote set-url origin https://<my_new_repository_url> чтобы установить новый URL, но когда я нажал, он просто сказал бы "Все в курсе" вместо того, чтобы подтолкнуть мою новую ветку к мастеру.
Я закончил тем, что решил, перебравшись на origin/master а затем нажмите с явными именами веток, как это:
$ git rebase <my_branch> origin/master
$ git push origin <my_branch>
Надеюсь, это поможет любому, у кого была такая же проблема!
Из вашего статуса git вы, вероятно, отличаетесь от моей.
Но в любом случае, вот что случилось со мной.. Я столкнулся со следующей ошибкой:
fatal: The remote end hung up unexpectedly
Everything up-to-date
Более информативным сообщением здесь является то, что пульт повесил трубку. Выяснилось, что это связано с превышением размера буфера http post. Решение состоит в том, чтобы увеличить его с
git config http.postBuffer 524288000
У меня была ситуация, когда я работал в функциональной ветке, и мой коллега также создал свою собственную функциональную ветку. Я побежал
Я исправил это, выполнив проверку в <coworkers_branch>, а затем вытащив из своей ветки функций, а затем зафиксировав и отправив обратно в <coworkers_branch>.
Я искренне надеюсь, что это кому-то поможет, потому что я потратил на это гораздо больше времени, чем следовало бы.
В моем случае у меня было 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 не работал!) Исправил проблему для меня.
Моя ошибка отличалась от всего, что упоминалось ранее. Если вы не знаете, почему у вас оторванная голова, то, вероятно, нет. Я работал на автопилоте с 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 где я обычно делаю:
[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'
Я столкнулся с этим сам, когда слил ветку на Github и продолжал развиваться в ней локально. Мое исправление немного отличалось от других, которые были предложены.
Сначала я разветвлял новую локальную ветку от моей старой локальной ветки (которую я не мог нажать). Затем я перенес новую локальную ветку на исходный сервер (Github). Т.е.
$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch
Это заставило изменения появиться на Github, хотя и в newlocalfranch, а не в oldlocalfranch.
Есть быстрый способ, который я нашел. Перейдите в папку.git, откройте HEAD файл и измените любую ветвь, на которой вы были, обратно на master. Например, ссылка: refs/heads/master
Я работал с Jupyter-Notebook, когда столкнулся с этой обманчивой ошибкой.
Я не смог решить с помощью решений, представленных выше, поскольку у меня не было отдельной головы, и у меня не было разных имен для моего локального и удаленного репо.
Но что у меня было, так это то, что размеры моих файлов были немного больше 1 МБ, а самый большой был почти ~2 МБ. Я уменьшил размер файла с помощью Как уменьшить размер файла моего ноутбука iPython? техника. Это помогло уменьшить размер моего файла за счет очистки выходных данных. Отныне я смог протолкнуть код, поскольку он увеличивал размер моего файла в килобайтах.
Другая возможность состоит в том, что вы назвали каталог в вашем файле.gitignore, который был исключен. Таким образом, новые коммиты не будут выдвинуты. Со мной случилось, что я назвал каталог, чтобы игнорировать "поиск", но это также был каталог в моем дереве исходных текстов.
У меня было несколько пультов. Все, кроме одного, нажаты правильно, поэтому я знал, что у меня не было отключенной HEAD или проблем с фиксацией.
Вместо этого я случайно дал двум пультам дистанционного управления один и тот же URL-адрес. Пульт с дублированным URL-адресом не удалось, потому что я нажимал на URL-адрес, который уже был отправлен!
С помощью git remote -v показал мой список пультов и их URL-адресов, где я понял проблему.
Сброс неисправного пульта ДУ на правильный URL-адрес устранил проблему:git remote set-url <remote-name> <correct-url>
Убедитесь, что вы не указали свой удаленный URL.
Я просто хотел также упомянуть, что столкнулся с этим после включения Git в качестве CVS в локальной конфигурации сборки Jenkins. Похоже, что Дженкинс проверил самый последний коммит из ветви, которую я дал, а также сбросил мой пульт, чтобы он соответствовал путям, которые я дал ему в репо. Пришлось снова проверить мою ветку функций и исправить исходный URL-адрес с помощью 'git remote set-url'. Не направляйте инструмент сборки в свой рабочий каталог, иначе у вас будет плохое время. Для моего пульта был задан путь к файлу в моем рабочем каталоге, поэтому он, естественно, сообщал обо всем обновленном, когда я пытался отправить изменения с тем же источником и местом назначения.
Я была такая же проблема. В моем случае это было вызвано необходимостью имен для одного и того же пульта. Он создал стандартную "origin", но я давно использовал "github" в качестве пульта, так что это тоже было там. Как только я удалил пульт "origin", ошибка исчезла.
Здесь мое решение отличается от приведенного выше. Я не понял, как это случилось, но исправил. немного неожиданно.
теперь приходит путь:
$ 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:команда, которая работает для меня, это
$git push origin HEAD:use_local_cache
(Надеюсь, вы, ребята, как можно скорее выберетесь из этой проблемы)
Еще одна довольно неприятная ситуация, о которой следует знать: когда вы проверили все остальное, а она все еще сохраняется, вы можете страдать отbranch.autoSetupMerge=always. Из документов:
всегда — автоматическая настройка выполняется, когда отправной точкой является либо локальная ветка, либо ветка удаленного отслеживания;
При использовании этой настройки проверка новой локальной ветки на основе main будет отмечать ваш восходящий поток как отправную точку (в моем случае — main). Поэтому каждый раз, когда я пытался нажать, я получалEverything up to date.
Исправление:git config --global branch.autoSetupMerge simple. Согласно документам,
просто — автоматическая настройка выполняется только в том случае, если начальной точкой является ветка удаленного отслеживания, а новая ветка имеет то же имя, что и удаленная ветка. По умолчанию этот параметр имеет значение true.
Используя эту и остальную часть моей конфигурации, а также исправив удаленное отслеживание затронутых веток, я могу возобновить отправку новых локальных веток на свой удаленный компьютер.
У меня было такое (коммиты в моем журнале git не были на GitHub, хотя git сказал, что все было в курсе), и я уверен, что проблема была в Github. Я не получил никаких сообщений об ошибках в git, но GitHub имел ошибки состояния, и мои коммиты были там через несколько часов.
https://status.github.com/messages
Сообщения о состоянии GitHub были:
- Мы расследуем сообщения о недоступности сервиса.
- Мы расследуем проблемы с доступом к GitHub.com.
- Мы отказываемся от системы хранения данных, чтобы восстановить доступ к GitHub.com.
Я знаю, что он очень старый, но в моем случае я исправил его довольно быстро.
Я получал ту же ошибку, будучи на один коммит раньше master. Затем я нашел текущую запись о переполнении стека. Однако, прежде чем приступить к предложенным идеям, я просто решил сделать новую фиксацию и попробовать еще раз с push to origin, и все прошло гладко.
Не знаю почему, но, может быть, кому-то это пригодится.
Глупая ошибка/напоминание: я отформатировал компьютер, переустановил vscode и забыл включить автосохранение :).
Надеюсь, вы сможете это реализовать быстрее и сэкономите 10 минут на отладке!
Нам нужно добавить файлы и зафиксировать уже измененные / добавленные файлы, выполните следующие команды
git add . или git add nameoffile # он добавит существующие файлы в проект
git commit -m "first commit" # фиксация всех файлов в проекте
git push origin master