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

5420

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

Сценарий следующий:

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

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

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

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

  • 11
    Любой, кто читает это, кто думает, что они могут потерять файлы, я был в этом положении и обнаружил, что буфер Sublime Text спас меня - если я над чем-то работаю, то случайно удалите все, пытаясь решить проблему, подобную этой, или используя ответ на этот вопрос и если файлы будут открыты в Sublime (что есть хорошие шансы), то файлы все еще будут там, есть Sublime, либо просто там, либо в истории отмены
  • 14
    git reset --hard origin/branch_to_overwrite
Показать ещё 3 комментария
Теги:
git-pull
version-control
overwrite
git-fetch

39 ответов

7581
Лучший ответ

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

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


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

git fetch --all

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

git reset --hard origin/master

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

git reset --hard origin/<branch_name>

Объяснение:

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

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


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

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

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

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

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

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

git stash

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

git stash pop
  • 7
    Осторожно! Если у вас есть локальные unpressed коммиты, это удалит их из вашей ветки! Это решение сохраняет неотслеживаемые файлы не в хранилище без изменений, но перезаписывает все остальное.
  • 431
    Это популярный вопрос, поэтому я хотел бы уточнить в верхнем комментарии здесь. Я только что выполнил команды, как описано в этом ответе, и он не удалил ВСЕ локальные файлы. Только удаленно отслеживаемые файлы были перезаписаны, и каждый локальный файл, который был здесь, остался нетронутым.
Показать ещё 24 комментария
837

Попробуйте следующее:

git reset --hard HEAD
git pull

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

  • 12
    Я сделал это, и некоторые локальные файлы, которые больше не были в репо, остались на диске.
  • 21
    Я не думаю, что это правильно. Выше будет выполнено слияние, а не перезапись, которая была запрошена в вопросе: «Как заставить git перезаписать их?» У меня нет ответа, я сейчас его ищу .. в данный момент я переключаюсь на ветку с кодом, который хочу сохранить "git checkout BranchWithCodeToKeep", затем делаю "git branch -D BranchToOverwrite" и затем наконец msgstr "git checkout -b BranchToOverwrite". Теперь у вас будет точный код из BranchWithCodeToKeep в ветви BranchToOverwrite без необходимости выполнять слияние.
Показать ещё 10 комментариев
426

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


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

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull

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

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

git clean -n -f -d

Пример вывода:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...
  • 0
    Вы можете дать git clean аргумент пути, чтобы быть более точным и избегать удаления неотслеживаемых файлов, которые не конфликтуют.
  • 29
    Круто ... Запустил это против моего репозитория dotfiles ... В моем домашнем каталоге. Хорошо, что у меня там не было ничего важного ...
Показать ещё 8 комментариев
364

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

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

 git add *
 git commit -a -m "local file server commit message"

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

 git fetch origin master
 git merge -s recursive -X theirs origin/master

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

  • 53
    Это лучший ответ, который я когда-либо видел. Я не пробовал, но в отличие от других ответов, это не попытка уничтожить все ваши неотслеживаемые файлы, что очень опасно по очевидным причинам.
  • 4
    То же самое - это работало для меня, когда я выполнял очень большое слияние (GitHub pull request), когда я просто хотел принять все это поверх того, что у меня было. Хороший ответ! В моем случае последние две команды были: 1) get fetch other-repo ; 2) git merge -s recursive -X theirs other-repo/master
Показать ещё 6 комментариев
236

Вместо этого:

git fetch --all
git reset --hard origin/master

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

git fetch origin master
git reset --hard origin/master

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

  • 3
    Ваш ответ как раз то, что вам нужно для вашего представителя. Я должен спросить, это также удаляет все неотслеживаемые файлы?
  • 5
    Да, большая часть моего представителя пришла отсюда :) Это также удалит все неотслеживаемые файлы. Что-то, о чем я забыл и мне до боли напомнили всего 2 дня назад ...
Показать ещё 4 комментария
125

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

git clean

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

  • 3
    Я пытался использовать «git clean» для решения той же проблемы, но она не разрешила. git status говорит: «Ваша ветвь и« origin / master »разошлись, # и имеют 2 и 9 разных коммитов соответственно». и git pull говорит что-то похожее на то, что у вас есть выше.
  • 0
    не нужно ли ему перейти на главную ветку, а затем сделать git clean для его работы? Затем он может вернуться к любой ветке разработки, из которой он работал.
Показать ещё 9 комментариев
102

Внимание, это навсегда удалит ваши файлы, если у вас есть какие-либо записи каталога /* в вашем файле gitignore.

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

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

git stash --include-untracked
git pull

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

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

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}

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

$ git stash clear

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

$ git stash list
...
$ git stash apply stash@{5}
  • 0
    Разве вы не предполагаете, что коммит никогда не выполнялся? В моем случае я сделал несколько коммитов в свою локальную ветку, но хотел «сбросить» все обратно в удаленную ветку
  • 1
    Нет, я так не думаю. Копирование просто удаляет незафиксированные файлы. Выше также перемещает (прячет) файлы, которые git не отслеживает. Это предотвращает удаление файлов, которые были добавлены на удаленный компьютер, которые еще не были загружены на ваш компьютер, но которые вы создали (!). Все без разрушения незавершенной работы. Надеюсь, что имеет смысл?
Показать ещё 5 комментариев
92

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

git checkout <your-branch> -f

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

git clean -f

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

git clean -fd
  • 0
    Я думаю, что описание сценария проясняет, что он действительно не хочет выбрасывать контент. Скорее всего, он хочет прекратить мерзавец перезаписывать файлы. Смотрите мое предложение.
  • 3
    Хотя этот ответ может не полностью соответствовать описанию, он все же избавил меня от разочарования, связанного с мерзостью возврата каретки (событие с autocrlf false). Когда git reset --hard HEAD не оставляет измененных файлов «no», эти флаги «-f» весьма полезны. Огромное спасибо.
85

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

git fetch --all

с последующим:

git reset --hard origin/master.

54

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

git reset --hard HEAD~5

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

git pull

Я обнаружил, что, посмотрев как отменить Git merge.

  • 0
    Это было то, что в конечном итоге сработало для меня, так как я принудительно подтолкнул свою ветку к исходному репо и продолжал получать конфликты слияния при попытке перенести его в мое удаленное репо ...
  • 0
    Привет, на самом деле это трюк для work around но действительно эффективный. Поскольку некоторые конфликты могут возникать всего за несколько коммитов, то отмена 5 коммитов обеспечит отсутствие конфликтов с удаленным кодом.
51

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

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

# Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull
  • Первая команда извлекает новейшие данные.

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

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

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

  • 0
    Использование «git merge origin / master» в качестве последней строки (как вы говорите в заметке) вместо «git pull» будет быстрее, так как вы уже отменили любые изменения в git-репо.
  • 1
    Да, конечно, git merge origin/master будет быстрее и, возможно, даже безопаснее. Поскольку, если кто-то внес изменения во время удаления файлов этого сценария (что, скорее всего, не произойдет, но возможно), вся попытка может завершиться неудачей. Единственная причина, по которой я pull туда pull заключается в том, что кто-то может не работать над основной веткой, но какая-то другая ветка и я хотели, чтобы скрипт был универсальным.
Показать ещё 1 комментарий
39

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

Я решил это:

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

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

  • 1
    Тоже самое. Иногда работает только очень сложное решение, часто бывает так, что недостаточно только перезагрузки и очистки ...
33

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

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!

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

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

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

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again

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


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

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

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

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

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

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

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

32

Бонус:

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

git pull --rebase

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

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

Найти детали в Что делает "git pull --rebase"? ,

27

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

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

#/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull
  • 0
    Использование «git merge origin / master» в качестве последней строки (как вы говорите в заметке) вместо «git pull» будет быстрее, так как вы уже отменили любые изменения в git-репо.
  • 0
    Требуется извлечение измененных файлов, так что это работает 100% раз. Я обновил свой сценарий с этим давно, но забыл обновить здесь. Я также использую это немного по-другому, чем вы. Я извлекаю файлы, которые имеют любой тип модификации, не только M, поэтому он работает постоянно.
27

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

git reset --hard HEAD
git clean -f
git pull
  • 5
    используйте git clean с осторожностью
26

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

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull

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

  • 2
    Это перезапишет измененные файлы (файлы, которые были ранее зарегистрированы) и удалит неотслеживаемые файлы (файлы, которые никогда не были возвращены). Именно то, что я искал, спасибо!
  • 3
    Я подозреваю, что третья строка git reset --hard HEAD может быть избыточной; моя локальная git reset --hard origin/master страница (2.6.3) говорит, что reset во второй строке git reset --hard origin/master «по умолчанию HEAD во всех формах».
Показать ещё 1 комментарий
22

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

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

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

19

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

git checkout --theirs /path/to/file.extension
git pull origin master

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

19

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

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

git fetch
git reset --hard @{u}

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

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

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

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

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"

Наслаждайтесь!

  • 0
    Этот ответ также хорош, потому что он работает независимо от того, в какой ветке вы находитесь!
19

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

18

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

git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp

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

git checkout master && git merge tmp

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

17

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

git rm [file]

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

16

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

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp

Это!

13

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

git reset --hard HEAD
git checkout origin/master
git branch -D master
git checkout -b master

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

git pull origin master

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

  • 2
    "git branch -D master" удалить ветку. так что будь осторожен с этим. Я предпочитаю использовать «git checkout origin / master -b <новое имя ветви>», которое создает новую ветку с новым именем, и вам нужно 3,4 строки. Также рекомендуется использовать "git clean -f".
12

Просто сделай

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname

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

12

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

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

git checkout -b tmp
git add *; git commit -am "my temporary files"
git checkout master

git fetch origin master
git merge -s recursive -X theirs origin master

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

11

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

git reset origin/master
  • 0
    Я лично нашел это наиболее полезным. Затем он сохраняет ваше рабочее дерево, чтобы вы могли проверить его снова. Для моей проблемы у меня были те же самые файлы, которые были добавлены, так что он застрял. Странно, я знаю.
9

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

[alias]
      fp = "!f(){ git fetch ${1} ${2} && git reset --hard ${1}/${2};};f"

Запустите команду

git fp origin master

эквивалентно

git fetch origin master
git reset --hard origin/master
9

Требования:

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

Решение:

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

    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
7

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

git pull
git reset origin/master
git checkout <file1> <file2> ...

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

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

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

git pull
git merge <commit before problem commit>
git reset <problem commit>
git checkout <file1> <file2> ...
git pull
6

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

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

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

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

5

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

git clone --depth 1 https://github.com/angularclass/angular2-webpack-starter.git

cd angular2-webpack-starter/

git checkout -b material2

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

git add .

git commit -m "pokemon go"

git reset --hard

git pull origin material2

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

Теперь вы готовы.

5

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

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

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

3

В Windows выполните эту единственную команду:

git fetch --all & git reset --hard origin/master
  • 0
    Почему он будет отличаться от, например, в Linux? Какую конкретную реализацию / пакет git вы используете? И / или какая среда (например, MinGW)?
  • 0
    Я не уверен, только уверен, что работает в Windows. В Linux, что такое разделитель для объединения двух команд в одну строку? (не труба, вялое сцепление, не передавая OUTPOUT)
3

Вы можете игнорировать этот файл с файлом в своей базовой папке проекта:

.gitignore

public/images/*

Затем вытащите изменения, а затем удалите эту строку из файла gitignore.

  • 0
    Это противоречит Tierlieb в ответ .
0

1: сброс до предыдущего коммита

git reset --hard HEAD

2: Удалить неотслеживаемые файлы

git clean -f

3: Потяните коммиты

git pull

Источники:

0

если вы хотите выполнить общий сброс в ветке удаленного отслеживания, используйте:

git fetch
git reset --keep origin/$(git rev-parse --abbrev-ref HEAD)

если вы хотите сбросить локальные изменения тоже:

git fetch
git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)
0
git clean -dfx
git pull
git push

Установлен

Я являюсь пользователем SVN старого стиля в течение стольких лет, как идея удаления файла и выполнения новой проверки, чтобы получить исходные файлы. Я хотел бы повторить то же самое с git, но не работает точно в SVN. Итак, git clean -dfx и git stash --include-untracked являются моим оружием, чтобы воспроизвести это.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню