После git push origin файлы в репозитории не обновились

Обновлено: 03.07.2024

PS: Я стараюсь --force максимально избегать использования этой опции.

Похоже, что кто-то вставил новые коммиты между вашими предыдущими git fetch и git push . В этом случае вам нужно повторить эти шаги и my_feature_branch еще раз переустановить .

После git fetch рекомендую ознакомиться с ситуацией с gitk --all .

Что делать, чтобы включить git pull origin master: master, который по умолчанию должен объединяться. Это конфликт слияния или нет. Это единственный вопрос, который задают. Это решает мою проблему: когда я зафиксировал свой код, я выполнил перебазирование (слишком поздно, изменения уже были, следует сделать это до фиксации). Тогда даже конфликта не было, я не мог толкнуть. После применения вышеуказанной магии это сработало. Спасибо.

У меня была такая проблема! Я пробовал: git fetch + git merge, но не решил! Я пробовал: git pull, но тоже не решил

Затем я попробовал это и решил свою проблему (аналогично ответу инженера):

Это меня напортачило, я отправил материал прямо в мастеринг и продвинул развертывание за целый день . и все в ярости . УДИВИТЕЛЬНЫЕ СОВЕТЫ! Вероятно, вы хотите вкратце объяснить, что вы делаете, прежде чем давать кому-то опасный инструмент.

У меня была аналогичная проблема, и я решил ее: git pull origin

Помог мне, когда я получил указанную ошибку при вытягивании удаленной ветки.

Я опаздываю на вечеринку, но я нашел несколько полезных инструкций на странице справки github и хотел бы поделиться ими здесь.

Иногда Git не может внести изменения в удаленный репозиторий без потери коммитов. Когда это произойдет, ваш толчок будет отклонен.

Или вы можете просто использовать git pull для одновременного выполнения обеих команд:

попробуйте эту команду

$ git push -f -u origin <name of branch>

т.е. $ git push -f -u origin master

В моем случае это сработало, когда другие - нет. Иногда вам просто нужно указать git -f -u

Блокировка записи в общем локальном репозитории

У меня была эта проблема, и ни один из вышеперечисленных советов мне не помог. Я смог получить все правильно. Но толкать всегда не удавалось. Это был локальный репозиторий, расположенный в каталоге Windows, и несколько клиентов работали с ним через драйвер общей папки VMWare. Оказалось, что одна из систем заблокировала репозиторий Git для записи. После остановки соответствующей системы VMWare, вызвавшей блокировку, все немедленно было восстановлено. Было почти невозможно выяснить, какая система вызывает ошибку, поэтому мне приходилось останавливать их одну за другой, пока не удалось.

Я пытаюсь переместить в удаленный пустой репозиторий. Я успешно выполняю локальные коммиты, но всякий раз, когда я нажимаю на origin / master, изменения не отражаются в удаленном репо.

Редактировать: я считаю, что ветвь fix-detached-HEAD была чем-то, что я создал в попытке решить эту проблему после некоторого поиска в Google.

Изменить: Подтверждение удаленного доступа:

4 ответа

Исходя из нашего чата, в конечном итоге проблема заключается в том, что вы настраиваете пульт странным образом, сначала копируя файлы исходного кода к нему, запустив git init , затем преобразовав его в голый (и клонируя в локальный). Однако кажется, что вы забыли удалить файлы при конвертации в голые, поэтому, когда вы нажали и ожидали, что они будут обновлены, они не были. Git игнорирует ошибочные файлы в голом хранилище, но продолжает обновлять объекты и другие компоненты. (Как отметил jthill в комментариях были получены толчки на основе редакция 2 вопроса.)

Если вы действительно хотите, чтобы файлы исходного кода существовали на удаленном компьютере, см. eis's answer , но это более продвинутое использование, и, как новичок, вы, вероятно, захотите просто обычное репо с голым торсом. Чтобы избежать путаницы в будущем, я мог бы предложить удалить существующий пульт и начать заново, но сначала сделайте резервную копию.

Ваши результаты показывают, что вы на самом деле не продвигаетесь в удаленный репозиторий.

Вам нужно добавить апстрим.

Затем проверьте git remote -v еще раз. Вы должны увидеть что-то вроде

Когда вы нажимаете сейчас, он должен идти в это место.

Возможно, вам также придется сделать

Вместо «git push» попробуйте «git push -u origin master» в этом -u означает обновление, возможно, это решит вашу проблему.

Основываясь на комментариях, вы просматриваете некоторые файлы на удаленном компьютере, которые не являются частью вашего репо или частью отдельной проверки. Это объясняет, почему они не обновляются, потому что вы обновляете пустое хранилище с объектами на удаленном компьютере, а не с файлами, которые вы просматриваете.

Если вы хотите, чтобы git push фактически развернул файлы на удаленном сервере, один из способов сделать это - установить ловушку на удаленном сервере, как описано в эта ссылка:

Выполнил команду push :

После выполнения этой команды появляется следующее:

После выполнения данной команды появляется следующий текст:

И как можно защититься от возможной потери данных?


9,309 5 5 золотых знаков 21 21 серебряный знак 50 50 бронзовых знаков


Походу вы делали git pull без указания репо и ветки. На это вам git дал подсказку "Please specify which branch you want to merge with.", но вы не вчитались в этот текст. Вам нужно указать репо и ветку. А @AivanF. вам правильно сказал: гляньте какие у вас ветки есть через git remote -v . Думаю, ваша проблема решится через git pull origin master , если все правильно настроено. И как можно защититься от возможной потери данных? . В гите все уже есть. Вы не потеряете ничего, если умышленно не будете делать этого. Если запутаетесь в своих действиях, git reflog , затем git checkout и т.д. Благодарю. Решил проблему следующим образом - удалил удаленный репозиторий, создал еще один с таким же названием и запушил в него.

Судя по выводу, мастер на сервере ушёл по коммитам дальше, и автомерж сделать никак, поэтому просто пуш не работает. Получилась ситуация вроде этой:

Диаграмма коммитов

  1. Подтянуть изменения в локальный мастер, git pull
  2. Разрешить конфликты, гит о них сообщит
  3. Запушить слитую ветку на удалённый мастер, git push

Чтобы не потерять текущие данные, можно заранее локальный мастер сохранить в отдельную локальную ветку в качестве бекапа, git checkout -b backup . Или даже запушить на сервер как отдельную ветку, чтобы всё точно было в сохранности.

PS: советую почитать теоретические материалы по теме, вот хорошая статья: Ветвление в Git – Удалённые ветки

Как я могу сделать это с Git?

Неясно, хотите ли вы переопределить только файлы .git или связанную с ними рабочую копию. Если это git-репозиторий, то git push - это ответ. Если вы хотите обновить удаленную рабочую копию, вы должны использовать ловушку после получения @ Майк, который почему-то работает на меня . интересно, что Вероятная причина, принудительное принудительное нажатие не работает, состоит в том, что он мог быть явно отключен в удаленном репо (чтобы гарантировать, что ничего не будет потеряно из-за идиотских и / или злостных участников): используйте, config receive.denyNonFastforwards чтобы узнать.

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

(например git push -f origin master ). Уход <remote> и <branch> заставит толкнуть все локальные ветви, которые установили --set-upstream .

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

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

Обновление 2 : из-за растущего числа зрителей я хотел бы добавить дополнительную информацию о том, что делать, когда вы upstream испытываете принудительный толчок.

Скажем, я клонировал ваш репо и добавил несколько коммитов так:

Это может показаться заманчивым в использовании, git pull --force но будьте осторожны, потому что это оставит вас с мельчайшими коммитами:

Так что, вероятно, лучший вариант - это сделать git pull --rebase . Это потребует от меня разрешения любых конфликтов, как раньше, но для каждого шага вместо фиксации я буду использовать git rebase --continue . В итоге история коммитов будет выглядеть намного лучше:

Обновление 3: Вы также можете использовать эту --force-with-lease опцию в качестве «более безопасного» принудительного толчка, как упомянул Кексейк в своем ответе :

Читайте также: