Git pull не работает

Git pull не работает

Я создал webhook в моем репозитории github, который публикует URL-адрес ловушки на моем работающем сервере, чтобы запустить команду pull для обновления файлов репо на сервере.

Проблема в том, что файл хука, который я создал, находится в /var/www/site/web/hookfile.php (туда отправляется почтовый запрос. Я также получаю ответ от тела)

и мои файлы репо находятся в / var / www / git-repo /

это не обновляет git-repo, когда я помещаю что-либо в свой репозиторий github.
Я запускаю эту команду, используя терминал и он работает.

Но через мой php файл не работает

Решение

shell_exec () завершается с ошибкой, потому что только отчет STDOUT, а не STDERR.

Обычно это ошибка разрешения, и она может быть исправлена ​​добавлением разрешения пользователю, выполняющему php (apache?)

Но может быть и ошибка подключения к удаленному хранилищу (аутентификация, ssh-ключи, …).

Другие решения

Прежде всего, в вашем php-файле я запускаю тест для вашего экземпляра сервера, чтобы получить какие-либо сообщения об ошибках, выводимые на экран, потому что семейство функций exec () просто завершается с ошибкой и только сообщает STDOUT, а не STDERR:

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

он вернул (далее называется YOU_FULL_GIT_BINARY_PATH_HERE):

Полный путь с помощью команды git, например ‘/ usr / local / git / bin / git status’ теперь хорошо выполняет команды git.

Другое дело, чтобы пользователь вашего веб-сервера имел достаточно прав для чтения / записи в вашу папку / файлы репо. Я установил, что мой принадлежит пользователю apache (другие версии Centos 6.8 могут быть www: www или www-data: www-data и т. Д.):

Чтобы гарантировать, что все добавленные файлы наследуют правильные разрешения, выполните:

Выше должен получить ваш скрипт для запуска команд сейчас. Хотя это не преодолевает приглашение пароля git использовать команду git pull для пользователя git, установленного в файле YOUR_WEB_OR_REPO_FODLER / .git / config. Выполнение команды ниже в репо:

команда запросит пароль и позволит вам сохранить его локально. Обратите внимание, что ваш сохраненный пароль не будет зашифрован и защищен только файловой системой, например, в /root/.git-credentials. Это позволит запускать «git pull» без запроса пароля.

Это не идеально для моей полностью автоматизированной среды непрерывной интеграции, в которой развертывается тестовый VPS по требованию, поскольку для этого требуется хотя бы один раз вручную ввести пароль пользователя git (определенный в репозитории .git / config git).

Поскольку моя среда всегда должна выполняться на коде из исходной / главной копии удаленного компьютера, я также запускаю

перед вызовом ‘git pull’, чтобы гарантировать, что любые локальные изменения будут потеряны навсегда, или сделайте полный сброс вместо этого, используя:

Создан git clone репозитория.
В нем удаляем несколько файлов
делаем git pull этого же репозитория
пишет все уже обновлено, и удаленные файлы не добавляются, никаких изменений или ошибок не происходит. В том числе и измененный репозиторий все равно пишет что обновлен и всё.
В чем может быть дело?

1 ответ 1

Откатитесь до состояния прошлого коммита git reset —hard HEAD

Либо можно восстановить отдельный файл. Для этого 1. Ищем последний коммит где файл существовал git rev-list -n 1 HEAD — имя_файла 2. Восстанавливаем нужный файл git checkout найденный_коммит^ — имя_файла

Как принудительно перезаписать локальные файлы в git pull ?

  • Член команды модифицирует шаблоны для сайта, над которым мы работаем
  • Они добавляют некоторые изображения в каталог изображений (но забывают добавить их под контролем исходного кода)
  • Они отправляют изображения по почте, позже, мне
  • Я добавляю изображения под контроль исходного кода и помещаю их в GitHub вместе с другими изменениями.
  • Они не могут получать обновления из GitHub, потому что Git не хочет перезаписывать свои файлы.

Это ошибка, которую я получаю:

ошибка: неотслеживаемый файл рабочего дерева ‘public/images/icon.gif’ будет перезаписан слиянием

Как заставить Git перезаписать их? Этот человек дизайнер. Обычно я разрешаю все конфликты вручную, поэтому на сервере установлена самая последняя версия, которую им просто необходимо обновить на своем компьютере.

git git-pull git-fetch version-control overwrite

38 ответов

7980 Решение RNA [2012-01-17 03:02:00]

Важно: если у вас есть какие-либо локальные изменения, они будут потеряны. С опцией —hard или без —hard все локальные коммиты, которые не были переданы, будут потеряны. [*]

Если у вас есть файлы, которые не отслеживаются Git (например, загруженный пользовательский контент), эти файлы не будут затронуты.

Читайте также:  10 Первых натуральных чисел оканчивающихся на 7

Я думаю, что это правильный путь:

Тогда у вас есть два варианта:

ИЛИ Если вы находитесь в другой ветке:

Объяснение:

git fetch загружает последние данные с удаленного компьютера, не пытаясь объединить или переместить что-либо.

Затем git reset сбрасывает основную ветвь к тому, что вы только что получили. Опция —hard изменяет все файлы в вашем рабочем дереве в соответствии с файлами в origin/master

Поддерживать текущие локальные коммиты

[*] : Стоит отметить, что можно сохранить текущие локальные коммиты, создав ветку от master до сброса:

После этого все старые коммиты будут храниться в new-branch-to-save-current-commits .

Незавершенные изменения

Однако незафиксированные изменения (даже поэтапные) будут потеряны. Убедитесь, что вы спрятали и передали все, что вам нужно Для этого вы можете запустить следующее:

А затем повторно применить эти незафиксированные изменения:

Он должен делать то, что вы хотите.

ВНИМАНИЕ: git clean удаляет все ваши неотслеживаемые файлы/каталоги и не может быть отменен.

Иногда просто clean -f не помогает. Если у вас нет отслеживаемых каталогов, опция -d также необходима:

ВНИМАНИЕ: git clean удаляет все ваши неотслеживаемые файлы/каталоги и не может быть отменен.

Попробуйте -n использовать -n ( —dry-run ). Это покажет вам, что будет удалено, фактически ничего не удаляя:

Как Ежик, я думаю, что ответы ужасны. Но хотя ответ Hedgehog может быть лучше, я не думаю, что он такой же изящный, как может быть. Способ, которым я нашел это, — использовать "выборку" и "слияние" с определенной стратегией. Это должно сделать так, чтобы ваши локальные изменения сохранялись до тех пор, пока они не являются одним из файлов, которые вы пытаетесь принудительно перезаписать.

Сначала сделайте фиксацию изменений

Затем извлеките изменения и перезапишите, если есть конфликт

"- X" — это имя опции, а "theirs" — значение для этой опции. Вы предпочитаете использовать "свои" изменения вместо "ваших" изменений, если есть конфликт.

248 Johanneke [2013-04-26 16:48:00]

Я бы посоветовал сделать следующее:

Не нужно брать все пульты и ветки, если вы идете на reset в ветку origin/master справа?

Похоже, что лучше всего сделать это:

Чтобы удалить все неиспользуемые файлы, а затем продолжить с обычным git pull .

102 Hedgehog [2012-02-12 02:00:00]

Некоторые ответы кажутся ужасными. Ужасно в смысле того, что случилось с @Lauri, следуя предложению Давида Авсаджанишвили.

Скорее (мерзавец> v1.7.6):

Позже вы можете очистить тайник истории.

Вручную, один за другим:

Жестоко, все сразу:

Конечно, если вы хотите вернуться к тому, что вы спрятали:

88 Vishal [2010-08-05 21:06:00]

Вы можете найти эту команду полезной для удаления локальных изменений:

И затем выполните очистку (удаляет необработанные файлы из рабочего дерева):

Если вы хотите удалить ненужные каталоги в дополнение к файлам без следа:

Вместо слияния с git pull попробуйте это:

git reset —hard origin/master .

Единственное, что сработало для меня, было:

Это вернет вам пять коммитов, а затем

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

Вот самое чистое решение, которое мы используем:

Первая команда извлекает новейшие данные.

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

Третья команда проверяет все файлы, которые были локально изменены.

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

У меня такая же проблема. Никто не дал мне это решение, но оно сработало для меня.

  1. Удалить все файлы. Оставьте только каталог .git .
  2. git reset —hard HEAD
  3. git pull
  4. git push

Теперь это работает.

33 kenorb [2012-10-26 12:17:00]

Прежде всего, попробуйте стандартный способ:

Предупреждение: вышеуказанные команды могут привести к потере данных/файлов, только если они не зафиксированы! Если вы не уверены, сначала сделайте резервную копию всей вашей папки репозитория.

Тогда потяните это снова.

Если вышеперечисленное не поможет и вам не нужны ваши неотслеживаемые файлы/каталоги (на всякий случай сделайте резервную копию сначала), попробуйте выполнить следующие простые шаги:

Читайте также:  Hp deskjet f4180 замена картриджа

Это удалит все файлы git (за исключением .git/ dir, где у вас есть все коммиты) и извлечет его снова.

Почему git reset HEAD —hard может не работать в некоторых случаях?

Пользовательские правила в .gitattributes file

Наличие правила eol eol=lf в .gitattributes может привести к тому, что git изменит некоторые изменения файлов, преобразовав окончания строк CRLF в LF в некоторых текстовых файлах.

Если это так, вы должны зафиксировать эти изменения CRLF/LF (просмотрев их в git status ) или попробуйте: git config core.autcrlf false чтобы временно игнорировать их.

Несовместимость файловой системы

Когда вы используете файловую систему, которая не поддерживает атрибуты разрешений. Например, у вас есть два репозитория, один для Linux/Mac ( ext3 / hfs+ ) и другой для файловой системы на основе FAT32/NTFS.

Как вы заметили, существует два разных типа файловых систем, поэтому та, которая не поддерживает разрешения Unix, в основном не может сбросить разрешения для файлов в системе, которая не поддерживает такие разрешения, поэтому независимо от того, как —hard вы попробуйте, git всегда обнаруживает некоторые "изменения".

Бонус:

Говоря о pull/fetch/merge в предыдущих ответах, я хотел бы поделиться интересным и продуктивным приемом:

Эта команда является самой полезной командой в моей жизни в Git, которая сэкономила много времени.

Перед отправкой вашего нового коммита на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с выборкой + слиянием) и поместит ваш коммит наверху в журнале Git. Нет необходимости беспокоиться о ручном извлечении/слиянии.

Я обобщил другие ответы. Вы можете выполнить git pull без ошибок:

Предупреждение. Этот script очень мощный, поэтому вы можете потерять свои изменения.

27 Ryan [2011-01-14 18:18:00]

У меня была аналогичная проблема. Я должен был сделать это:

Основываясь на моих собственных подобных опытах, решение, предлагаемое Strahinja Kustudic выше, является безусловно лучшим. Как отмечали другие, просто выполнение жесткого reset удалит все не проверенные файлы, которые могут включать в себя множество вещей, которые вы не хотите удалять, например, файлы конфигурации. Что более безопасно, нужно удалить только файлы, которые должны быть добавлены, и, в этом отношении, вы, вероятно, также захотите проверить любые локально модифицированные файлы, которые должны быть обновлены.

Именно поэтому я обновил Kustudic script, чтобы сделать именно это. Я также исправил опечатку (отсутствует в оригинале).

23 tiho [2011-12-12 22:54:00]

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

Локальные файлы, которые не отслеживаются, должны быть удалены вручную (безопаснее) или, как предложено в других ответах, на git clean -f -d

Локальные коммиты, которые не находятся в удаленной ветке, также должны быть удалены. ИМО — самый простой способ добиться этого: git reset —hard origin/master (замените "мастер" любой веткой, над которой вы работаете, и сначала запустите git fetch origin )

20 maximus 69 [2015-05-05 11:03:00]

Более простой способ:

Это переопределит ваш локальный файл с файлом на git

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

Основываясь на сочетании ответа РНК и ответ torek на аналогичный вопрос, я пришел с великолепной работой:

Запустите это из ветки, и она будет только reset вашей локальной ветвью в восходящую версию.

Это может быть удобно помещено в псевдоним git ( git forcepull ):

git config alias.forcepull "!git fetch ; git reset —hard @"

Или в файле .gitconfig :

19 Tierlieb [2011-08-03 12:23:00]

У меня была такая же проблема, и по какой-то причине даже git clean -f -d не сделал бы этого. Вот почему: По какой-то причине, если ваш файл игнорируется Git (через запись .gitignore, я предполагаю), он по-прежнему беспокоится о том, чтобы перезаписать это с последующим отключением, но чистый не удалит его, если только вы добавьте -x .

18 Simon B. [2010-12-03 18:00:00]

Я просто решил это сам:

где последняя команда дает список ваших локальных изменений. Продолжайте модифицировать ветвь "tmp" до тех пор, пока она не будет приемлемой, а затем слейте обратно на master с помощью:

Читайте также:  8Gadgetpack что это за программа

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

17 Chen Zhang [2011-09-19 17:18:00]

У меня странная ситуация, что ни git clean ни git reset работают. Я должен удалить конфликтующий файл из git index , используя следующий скрипт для каждого неотслеживаемого файла:

Тогда я могу тянуть просто отлично.

Я знаю гораздо более простой и менее болезненный метод:

Эти четыре команды работают для меня.

Чтобы проверить/вытащить после выполнения этих команд

Я много пробовал, но, наконец, добился успеха в этих командах.

12 Snowcrash [2014-10-22 20:31:00]

Несмотря на исходный вопрос, верхние ответы могут вызвать проблемы для людей, у которых есть аналогичная проблема, но не хотят потерять свои локальные файлы. Например, см. Комментарии Al-Punk и crizCraig.

Следующая версия фиксирует ваши локальные изменения во временной ветке ( tmp ), проверяет исходную ветвь (которая, как я предполагаю, master ), и объединяет обновления. Вы можете сделать это с помощью stash , но я нашел, что обычно проще просто использовать подход branch/merge.

где мы предполагаем, что другой репозиторий — origin master .

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

11 [2013-02-15 16:41:00]

Reset указатель и head на origin/master , но не reset рабочее дерево:

9 vezenkov [2015-09-02 02:00:00]

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

    Скрыть локальные изменения.

Получить с чистой файлами и , игнорируя .gitignore и жесткий reset в происхождение.

Я прочитал все ответы, но я искал одну команду для этого. Вот что я сделал. Добавлен псевдоним git в .gitconfig

Не используйте git reset —hard . Это уничтожит их изменения, которые вполне могут быть совершенно нежелательными. Вместо этого:

Конечно, вы можете использовать git fetch вместо git pull , поскольку он явно не собирается сливаться, но если вы обычно тянете, имеет смысл продолжать здесь тянуть.

Итак, что происходит, это то, что git pull обновляет исходную/основную ссылку; git reset обновляет ссылку на локальную ветку на том же уровне, что и исходный/основной, без обновления каких-либо файлов, поэтому ваше состояние выписки не изменилось; то git checkout восстанавливает файлы в состояние локального отраслевого индекса по мере необходимости. В тех случаях, когда точно такой же файл был добавлен в режиме реального времени и на ведущем сервере, индекс уже соответствует файлу, указанному ниже reset, поэтому в общем случае вам вообще не нужно делать git checkout .

Если ветвь вверх по течению также содержит коммиты, которые вы хотите применить автоматически, вы можете следовать тонкой вариации процесса:

Это лучшая практика для отмены изменений:

  • git commit Примите ваши поэтапные изменения, чтобы они были сохранены в reflog (см. ниже)
  • git fetch Получить последние изменения в вышестоящей версии
  • git reset —hard origin/master Хард git reset —hard origin/master главную ветку

reflog записывает ветки и другие ссылки, которые обновляются в локальном хранилище. Или проще говоря — reflog — это история ваших изменений.

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

5 Glutexo [2015-10-07 12:03:00]

Я использовал эту команду, чтобы избавиться от локальных файлов, мешающих мне делать pull/merge. Но будь осторожен! Сначала запустите git merge … , чтобы увидеть, есть ли только те файлы, которые вы действительно хотите удалить.

  • git merge содержит список всех этих файлов. Они добавляются в какое-то белое пространство.
  • 2>&1 >/dev/null перенаправляет вывод ошибки на стандартный, поэтому он подбирается grep .
  • grep ^[[:space:]] фильтрует только строки с именами файлов.
  • sed s/^[[:space:]]//g обрезает белое пространство с самого начала.
  • xargs -L1 rm вызывает rm в каждом из этих файлов, удаляя их.

Обращайтесь с осторожностью: какие бы то ни было выходы git merge , rm будет вызываться для каждой строки, начинающейся с пробела.

5 Helzgate [2016-07-27 19:17:00]

Я пытался использовать ветвь Material2 на Angular2 -Webpack-Starter и имел чертовски время. Это был единственный способ загрузить и использовать эту ветку.

Откройте папку проекта и удалите все не скрытые файлы и папки. Оставьте все скрытые.

(Когда редактор появится, нажмите ‘: wq’, а затем нажмите Enter )

Ссылка на основную публикацию
Adblock detector