Как удалить файл с именем. css из всех веток в git - PullRequest
Новая
       81

Как удалить файл с именем. css из всех веток в git

1 голос
/ 03 августа 2020

Я работаю с репозиторием git, в котором каким-то образом есть файл с именем .css. Это вызывает ошибку при проверке в Windows (но в Linux он работает нормально).

Как мне удалить этот файл из всех веток в git, без случайно удаления всех css файлов из всех веток?

Ответы [ 2 ]

4 голосов
/ 03 августа 2020

Вот как вы можете сделать это для одной ветки, так как «все ветки» довольно неоднозначны, я оставил часть автоматизации / итераций для всех ветвей, чтобы вы могли делать то, что вы предпочитаете (я предлагаю сделать это вручную, если вы этого не сделаете) У меня слишком много ветвей с этой проблемой (c файл) 

# First checkout the branch - WARNING - Note I use
# --force here to make sure `git status` is clean. 
# I'm relying on it later when doing `git add -A`.
# The --force flag will delete any uncommited local changes,
# so make sure you don't have any of those before running
# the following command
git checkout --force my_branch

# Now delete the `*.css` file. Note the single quotes, they
# are crucial to prevent the shell from doing expansion on the asterisk:
rm -- '*.css'

# Add "all" the changes (The deletion of the file should be the only change):
git add -A

# Now commit
git commit -m 'Removed evil *.css file'

# And push
git push origin my_branch

Я специально не использовал git rm (который объединяет удаление и git add в одной команде), потому что я не мог заставить его игнорировать * как символ, он попытался сообразить и удалить все .css файлы в проекте. РЕДАКТИРОВАТЬ: См. ответ Торека , чтобы узнать, как указать буквальные звездочки в git командах

1 голос
/ 03 августа 2020

Как мне удалить этот файл из всех веток в git, не удаляя случайно все css файлы из всех веток?

Ответ Омера показывает в одну сторону; вот еще один.

Примечание: вы не удаляете файл из веток . Вы делаете новых коммитов, в которых отсутствует файл , который каждый новый коммит делает в определенной ветке. Это важное различие, потому что существующие коммиты продолжают существовать и сохранять файл. Ни один существующий коммит не может быть изменен! Вы просто останавливаете , используя эти коммиты. Но пока у вас все еще есть эти более ранние коммиты, любая попытка извлечь один из них на Windows вызовет у вас такую ​​же изжогу. 1

Чтобы совершить новый коммит на ветка, мы (конечно) будем использовать git commit как обычно. Чтобы получить в определенной ветке, мы будем использовать git checkout или git switch как обычно. Как и в ответе Омера, важно убедиться, что вы начинаете с чистой установки, хотя я не буду показывать здесь какой-либо конкретный метод, гарантирующий это.

Учитывая список ветвей, в которых есть файл, чей name буквально *.css, теперь нам нужен al oop, написанный на любом языке сценариев, который вы предпочитаете. Поскольку Git включает sh (или bash), и это хороший мощный язык сценариев, я бы здесь использовал именно его: 

for name in br1 br2 br3 master; do
    git checkout $name &&
    git rm -f -- ":(literal)*.css" &&
    git commit -m "remove file named *.css" ||
    echo "failed to update branch $name"
done

Префикс :(literal) является частью pathspe c и предотвращает расширение git rm *.css для соответствия всем файлам .css. Это задокументировано в gitglossary , хотя и довольно хорошо скрыто. (Флаг -f здесь разрешает git rm даже на Windows, хотя на Windows шаг git checkout, вероятно, завершится ошибкой, поэтому вам придется изменить цепочку &&. Если вы делаете это на в системе Linux, вам здесь не нужен флаг -f.)

Вы можете продолжить это с помощью одной git push из всех рассматриваемых ветвей: 

git push origin br1 br2 br3 master

например.

1 Это - это возможность «перезаписать историю» в репозитории Git, чтобы не просто остановить использование фиксации, но и прекратить сохранение это вообще в репозитории. Обратной стороной этого является то, что каждый последующий номер фиксации (ha sh -ID) также изменяется, так что новый репозиторий никогда не может быть смешан с исходным репозиторием: если он смешан вместе, все старые коммиты возвращаются. Иногда это стоит усилий, но не так уж часто. Количество проблем зависит от количества и важности копий репозитория, которые существуют и имеют исходные коммиты, предварительно перезаписанные.

...