Сергей Кузнецов

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

git rm "delete_file_old/*"
git commit --amend

Если добавили в старых коммитах, то через git filter-repo

git rm "путь/import_1*.csv"

А вообще, никогда не было проблем с именами в юникоде, даже в Windows.
Но я предпочитаю отключать экранирование при выводе
git config --global core.quotePath false

И работать проще в SmartGit, чем в голой консоли. Особенно если файлы с русскими именами, да ещё в какой нибудь древней кодировке Windows-1251.

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

➜ git branch -vv
* main 0e02250 [origin/dev] Commit Message

➜ git push -u origin main:main
branch 'main' set up to track 'origin/main'.
Everything up-to-date

➜ git branch -vv              
* main 0e02250 [origin/main] Commit Message

Чтобы PhpStorm увидел изменения, наверное придётся его перезапустить.

Первый способ


Второй способ

Пересадить ветку в новое место
git rebase --onto develop master feature

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

git branch feature/menu # создать ветку, новые коммиты уже окажутся в ней
git reset HEAD~5 # откатить мастер на 5 шагов назад

Чтобы файл не пушился во внешний репозиторий, не коммитьте его в локальный репозиторий.

8.1 Настройка Git — Конфигурация Git

git config --system receive.denyNonFastForwards true
git config --system receive.denyDeletes true

Tailscale — позволяет поднять туннели до любых устройств за шлюзом.
Множество компов в разных подсетях объединятся в одну виртуальную сеть.
Поддерживает macOS, Linux, Windows, Android, iOS. Используется движок WireGuard.
Быстрый и нетребовательный к ресурсам. Для личного использования бесплатно.
И что самое удобное, не требуется ничего пробрасывать на роутерах и работает с динамическими IP.

Если

неверно ввел логин и пароль

Удалить ошибочную авторизацию можно командой

echo "url=https://github.com" | git credential reject

Нельзя восстановить файл, если вы его как минимум не индексировали. Если удалённый файл индексирован, но ещё не закоммичен то git restore :/ вытащит его из индекса. Если файл уже закоммичен, то простой git restore -- file его восстановит уже из репы.

Если вы называете сервером тот компьютер куда загружаются коммиты с "гита", то нет, пропустить коммиты при pull нельзя.
Чините гит , запустив git rebase --interactive HEAD~2 на компе, который вы назвали гитом.

Чтобы сообщить что мы разрешили конфликт, нужно индексировать файл повторно
git add файл
Встроенный инструмент PHPStom делает это автоматически

Другой вариант:

git checkout F1^ # переместить HEAD на C3
git commit –m "C10" # добавить коммит
git rebase --onto HEAD master F3 # пересадить сюда кусок ветки F3
git cherry-pick F1 # скопировать коммит С4 с вершины ветки F1

Ничего лишнего и обошлось без временной ветки и без возни с хешами – только имена веток в командах. Алгоритм на четыре шага короче.

Вы банально путаете файлы в репозитории и файлы в рабочем каталоге. Это две большие разницы. Файлы нормально скачиваются из одного репозитория в другой, но Pull никогда не убивает те файлы в рабочей директории, которые ещё не были закоммичены. И это хорошо на самом деле. Файлы останутся как есть, но вы будете видеть что они якобы изменены.

Как вы сами уже поняли в другом своём вопросе эти "изменения" нужно откатить принудительно через reset --hard

Всё корректно, так и должно быть.
Команда Pull не ЗАМЕНЯЕТ незакоммиченные изменённые файлы в рабочем каталоге.
Нужно делать reset --hardчтобы привести файлы в актуальное состояние ветки.

При клонировании в рабочий каталог распаковывается не ветка master, а текущая ветка.
Единственный способ изменить это поведение – при клонировании указать какая конкретно ветка вам нужна.
git clone --branch <branchname> <remote-repo-url>
Либо вообще ничего не распаковывать сразу. Распаковывать можно позже.
git clone --no-checkout <remote-repo-url>

Если ничего не получается, прочтите наконец инструкцию

git config --global core.editor "ваш любимый редактор"

Консольные команды вы обязаны знать и понимать что они делают, это не обсуждается. Но пользоваться лучше тем инструментом, который есть под рукой. Если среда разработки включает поддержку контроля версий, то нужно пользоваться. Это здорово ускоряет работу и позволяет визуализировать процессы. Глупо строчить команды в терминал, когда IDE позволяет то же самое сделать одним кликом мыши или вообще автоматически. Также вы не сможете одной только консолью так качественно разрешать конфликты слияния, как это позволяет тот же JetBrains. Из автономных графических клиентов безусловный лидер – SmartGit, сложные rebase делаю только в нём. Но некоторые вещи всё равно без консоли никак не сделать.

Файлы никак не могли удалиться в результате push. Вы сделали что-то ещё, что привело к этому результату. В вопросе нет никаких подробностей, так что ответа не будет.