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

Question

У меня есть удаленный сервер 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

Answer 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

Answer 2

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

Answer 3

Может быть, вы открываете новую локальную ветку?

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

git push origin your-new-branch-name

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

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

Answer 5

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

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

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

Так что я обычно толкаю основную ветку в общий репозиторий ... что, наверное, неплохо, в моем случае ...

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

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

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

Answer 6

$ git push origin local_branch:remote_branch

Объяснение

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

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

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

$ git push origin local_branch:remote_branch

Answer 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, и на этот раз это сработало.

Гит перестал говорить «все актуально» - и перестал жаловаться на «быстрые форварды».

Answer 8

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

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

В итоге я решил ее, перебрав на origin/master, а затем нажал с явными именами веток, например:

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

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

Answer 9

Из вашего статуса git вы, вероятно, отличаетесь от моего.

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

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

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

git config http.postBuffer 524288000

Answer 10

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

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