В моей ветке у меня были файлы в .gitignore
В другой ветке эти файлы не являются.
Я хочу объединить другую ветку в мою, и мне все равно, если эти файлы больше не игнорируются или нет.
К сожалению, я получаю следующее:
Следующие неиспользуемые рабочие файлы дерева будут перезаписаны с помощью merge
Как мне изменить мою команду pull, чтобы перезаписать эти файлы, без необходимости самостоятельно находить, перемещать или удалять эти файлы?
Проблема заключается в том, что вы не отслеживаете файлы локально, но идентичные файлы отслеживаются удаленно, поэтому для "вытягивания" ваша система будет вынуждена перезаписывать локальные файлы, которые не контролируются версией.
Попробуйте запустить
git add *
git stash
git pull
Это будет отслеживать все файлы, удалять все локальные изменения этих файлов, а затем получать файлы с сервера.
Вы можете попробовать команду, чтобы очистить неотслеживаемые файлы от локальных
Git 2.11 и более новые версии:
git clean -d -f .
Старые версии Git:
git clean -d -f ""
Где -d можно заменить следующим:
-x игнорируемые файлы также удаляются, как и файлы, неизвестные Git.
-d удаляет неотслеживаемые каталоги в дополнение к неотслеживаемым файлам.
-f требуется, чтобы заставить его работать.
Вот ссылка, которая также может быть полезна.
Единственными командами, которые работали для меня, были:
git fetch --all
git reset --hard origin/{{your branch name}}
Если это одноразовая операция, вы можете просто удалить все необработанные файлы из рабочего каталога, прежде чем делать pull. Прочитайте Как удалить локальные (не проверенные) файлы из текущего рабочего дерева Git? для получения информации о том, как удалить все невоспроизводимые файлы.
Не забудьте случайно удалить необработанный файл, который вам по-прежнему нужен;)
Вы можете попробовать эту команду
git clean -df
Удалить все неотслеживаемые файлы:
git clean -d -fx .
git merge -f не существует, но git checkout -f существует. В приведенном ниже примере FOI означает "представляющие интерес файлы": файлы, которые существуют в ветки-доноре, не существуют в ветки-получателе и блокируют слияние, поскольку они присутствуют и не отслеживаются в вашем рабочем каталоге. Это шаги, чтобы удалить эти файлы, представляющие интерес, чтобы ваше слияние прошло нормально.
# FOI is the 'files of interest', the untracked files blocking the merge.
# 1. This forcibly replaces untracked FOI with tracked versions of
# the donor branch (as well as updating the rest of the working dir).
git checkout -f donor-branch
# 2. This removes the FOI because they they are tracked in our current
# (donor) branch, and absent in the 'receiving-branch' we switch to.
git checkout receiving-branch
# 3. Now that the FOI are absent, merging in the donor branch will not
# overwrite any untracked files, so we get no errors.
git merge donor-branch
В своем вопросе вы спрашиваете: "Как бы я изменил свою команду pull чтобы перезаписать эти файлы"?
Pull - это не что иное, как git fetch (получение удаленной истории) + автоматическое слияние ветки upstream. Таким образом, вы бы изменили свою команду извлечения так, чтобы она стала (а) извлекать удаленную историю, (б) использовать трюк извлечения -f для перезаписи файлов, (в) объединить удаленную историю. Шаги будут выглядеть следующим образом:
git fetch origin
git checkout -f origin/mybranch
git checkout mybranch
git merge origin/mybranch
Чем этот ответ отличается от других ответов?
Представленный здесь метод удаляет только файлы, которые будут перезаписаны слиянием. Если в каталоге есть другие неотслеживаемые (возможно, игнорируемые) файлы, этот метод не удалит их.
Решение
Этот фрагмент извлечет все неотслеживаемые файлы, которые будут перезаписаны git pull и удалит их.
git pull 2>&1|grep -E '^\s'|cut -f2-|xargs -I {} rm -rf "{}"
а затем просто сделайте:
git pull
Это не команда git porcelain, поэтому всегда проверяйте, что она будет делать:
git pull 2>&1|grep -E '^\s'|cut -f2-|xargs -I {} echo "{}"
Объяснение - потому что один вкладыш страшен:
Вот разбивка того, что он делает:
git pull 2>&1 - git pull вывод git pull и перенаправить его на стандартный вывод, чтобы мы могли легко перехватить его с помощью grep.grep -E '^\s - намеревается захватить список неотслеживаемых файлов, которые будут перезаписаны git pull. Перед именами файлов стоит группа пробельных символов, поэтому мы используем их для их получения.cut -f2- - удалить пробел из начала каждой строки, захваченной в 2.xargs -I {} rm -rf "{}" - мы используем xargs для перебора всех файлов, сохраняем их имя в "{}" и вызываем rm для каждого из них. Мы используем -rf для принудительного удаления и удаления неотслеживаемых каталогов.Было бы здорово заменить шаги 1-3 фарфоровой командой, но я не знаю ни одного эквивалента.
Если вы считаете, что используете флаг -f, вы можете сначала запустить его как сухой. Просто, что вы заранее знаете, какую интересную ситуацию вы закончите следующим: -P
-n
--dry-run
Don’t actually remove anything, just show what would be done.
В дополнение к принятому ответу вы можете, конечно, удалить файлы, если они больше не нужны, указав файл:
git clean -f '/path/to/file/'
Не забудьте сначала запустить его с флагом -n, если вы хотите увидеть, какие файлы git clean будут удалены. Обратите внимание, что эти файлы будут удалены. В моем случае я все равно не заботился о них, так что это было лучшим решением для меня.
Один из способов сделать это - сохранить локальные изменения и вытащить из удаленного хранилища. Таким образом, вы не потеряете свои локальные файлы, так как файлы попадут в тайник.
git add -A
git stash
git pull
Вы можете проверить ваши локальные спрятанные файлы с помощью этой команды - git stash list
Для тех, кто не знает, git игнорирует различия в именах файлов и папок в верхнем и нижнем регистре. Это оказывается кошмаром, когда вы переименовываете их в одно и то же имя с другим регистром.
Я столкнулся с этой проблемой, когда переименовал папку из "Petstore" в "petstore" (от прописной до строчной). Я отредактировал свой файл .git/config, чтобы перестать игнорировать регистр, внес изменения, уничтожил мои коммиты и спрятал свои изменения, чтобы перейти в другую ветку. Я не мог применить свои спрятанные изменения к этой другой ветке.
Исправление, которое я нашел, сработало, чтобы временно отредактировать мой файл .git/config, чтобы снова временно игнорировать регистр. Это вызвало git stash apply к успеху. Затем я изменил ignoreCase обратно на false. Затем я добавил все, за исключением новых файлов в папке petstore, которые, как ни странно утверждают, были удалены по какой-либо причине. Я зафиксировал свои изменения и запустил git reset --hard HEAD чтобы избавиться от этих неотслеживаемых новых файлов. Мой коммит выглядел точно так, как ожидалось: файлы в папке были переименованы.
Я надеюсь, что это поможет вам избежать моего же кошмара.
Ни очистка/сброс/жесткая проверка/ребазирование не помогли мне. Файлы, на которые жаловался git, где вообще нет на диске (после чистого/жесткого сброса), но git все еще жаловался.
Поэтому я просто удалил их, запустив, и это решило мою проблему:
rm /path/to/files/that/git/complained/about
Примечание. Если вы получите эту ошибку в Xcode, возможно, вы просто забыли зафиксировать некоторые файлы.