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

Что-то не очень понятно что вы хотите сделать.
Если надо просто переключиться в старое состояние, то сбросьте ветку до этого состояния.
git reset --hard адрес_старого_состояния
Тут нет нужды отменять какие-то коммиты.

Нет никакой разницы, переименовываете вы руками или через команду git mv.
А вот пихать все эти манипуляции в один коммит — неправильно.
Сначала удалите первую папку и закоммитьте.
Затем переименуйте на диске вторую папку и снова закоммитьте новое состояние.

Вы наверное хотите скрыть не сам Pull Request, а код, который виден там.
Но ведь этот код студенты отправляют из своих открытых проектов в ваш открытый проект. Значит код в любом случае виден всем в интернете, причем даже без создания PR.
Единственный способ скрыть код — публиковать его в закрытые проекты.
Пусть студенты создают приватные репозитории и дают вам доступ туда.

Сначала влить мастер к себе в ветку, чтобы у вас папка тоже переименовалась.
git merge master mybranch
Потом свою ветку влить в мастер, чтобы уже ваши правки ушли в мастер.
git merge mybranch master

В файл ORIG_HEAD перед началом операций записывается указатель на вершину текущей ветки. Видимо этот файл у вас испортился.
Удалите его вручную.

Проверяйте файл .gitmodules
Смотрите откуда подгружается подмодуль и доступен ли его репозиторий из GitHub.

Файл .gitignore не предназначен для удаления файлов из репо, он лишь помогает не добавить случайно лишнее в репо. А если уже закоммитили, то игнор не поможет.

Самый надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

# клонируем репозиторий в соседний каталог
# иначе придётся использовать ключ --force
git clone --no-local . ../clonerepo/
# переходим в свежий клон
cd ../clonerepo
# чистим
git filter-repo --path "path/to/file" --invert-paths
# проверим что файл исчез
git log --oneline --name-status -- "path/to/file"

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

После нажатия «Войти через браузер» должен открыться собственно браузер со страницей гитхаба, где вы должны нажать кнопочку «Разрешить».
Если вы не разрешили или что-то пошло не так, то только тогда вылезет предложение ввести пароль в терминале. Но там вместо пароля нужно вводить не ваш гитхабовский пароль, а текст токена, который вы должны были заранее создать. Токен вам покажут только один раз, поэтому скопируйте его в буфер и сохраните где-нибудь.
И вставляйте его в терминале тоже через буфер обмена, чтобы не ошибиться. При вводе паролей с терминале их никогда не видно, не пугайтесь и просто жмите Enter после ввода.

Для тестирования единственного .gitignore, лежащего в корне проекта, используют команду
git check-ignore **/*

Если файлы .gitignore раскиданы по подкаталогам, то сработает такой способ
git ls-files --others -i --exclude-standard

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

git config --global alias.ignore-list "! cd -- \"\${GIT_PREFIX:-.}\" && git ls-files -v \${1:-.} | sed -n -e \"s,^[a-z] \(.*\)$,\${GIT_PREFIX:-./}\1,p\" && git status --ignored --porcelain \${1:-.} 2>/dev/null | sed -n -e \"s/^\(\\!\\! \)\(.*\)$/\2/p\" #"

Использование:
git ignore-list

Просто скопируйте закрытый ключ с одного компа на другой и всё. Либо создайте новую пару на втором компе и добавьте ещё один открытый ключ на гитхаб.

Если ветка на origin не защищена от удаления, то
git push --force
А на других компьютерах, например на VPS
git pull --rebase
Чтобы ветка там тоже удалилась и пересобралась заново.

последовательная разработка и задачи

Поясните, что вы имели в виду под «последовательная». Предыдущая задача полностью замораживается при начале следующей? Это какой-то странный рабочий процесс.
Либо вы чего-то недоговариваете.
Несколько долгоживущих веток подразумевают именно параллельную разработку, а не последовательную.

1. Создавать новую ветку на основании feature3 и продолжить работу.
2. Создать новую ветку на основании master и слить в нее все 3 ветки.

Ветки на самом деле создаются не от других веток, а от конкретных состояний (коммитов).
Оба варианта дадут совершенно идентичный результат. И в обоих случаях желательно будет делать синхронизацию. Только зачем вам во втором случае сливать в новую ветку три предыдущих, если вы говорите что feature3 уже содержит в себе работу из предыдущих?

Если у веток будет один родитель, то git сможет сделать перемотку вперед.

Нет. У любых двух веток в любом случае есть какой-то общий родитель. Быстрая перемотка возникает лишь если в одной из веток ничего не делали после ответвления от неё. Если ветки разошлись, то обязательно получится коммит слияния, но не факт что возникнут конфликты.

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

Python-пакет не является Git-репозиторием, поэтому вы не сможете делать в него коммиты. И тот индекс, откуда вы скорее всего скачали пакет тоже не имеет никакого отношения к Git его репозиториям.

Или нужно устанавливать пакет через пип, а модернизировать и делать коммиты с помощью отдельного гит клона этого пакета?

Верно. Найдите исходный репозиторий пакета и отправляйте свои доработки в него, а потом попросите автора принять исправления и обновить пакет в индексе в котором он опубликован. Либо устанавливайте пакет напрямую из гита.

Push отправляет во внешний репозиторий origin ваши новые коммиты, которых там ещё нет. А указатель ветки origin/master просто передвинется на новую вершину цепочки коммитов (fast-forward). Никакого коммита слияния при этом не создаётся и конфликтам возникнуть в принципе неоткуда.
Кто с кем должен конфликтовать по вашему мнению?

git merge develop master

Если сливать весь develop пока рано, сделайте cherry-pick только фикса.

Если репозитории идентичны, как вы говорите, то merge ничего не изменит.
Лишние файлы удаляют командой git clean -f -d
Это очистит рабочий каталог от всех неотслеживаемых файлов, кроме игнорируемых.

В мастере установки есть пункт — добавить пути в переменную PATH.
Либо вы забыли добавить, либо не перезагрузили компьютер после установки.

ВАЖНО! Git Bash должен быть установлен в папку C:\Program Files. При установке в другую папку подключить Git Bash к VSCode не получится. Так пишут в интернете.

В терминале запустился редактор vi, управлять им не сложно, но команды придётся выучить.
Нажмите Escape, затем : x Enter

Вам показалось. Изменения рабочего каталога не принадлежат никакой ветке, это просто каталог с файлами. Если вы что-то изменили, не закоммитили, и переключитесь на main, то гит не уничтожает эти изменения а оставляет их в рабочем каталоге и попытается слить с файлами из main. Это не значит что они попали в main. Без коммита они никуда не попадут.
Если вы сейчас сделаете git status, то увидите что файлы в рабочем каталоге изменены, т. е. в рабочем каталоге не содержимое main, а какие-то другие файлы.
Если сбросить рабочий каталог git reset --hard, то увидите реальное содержимое main, а ваши изменения окончательно потеряются.

Не пытайтесь запихнуть папку .git в гуглодиск, вы так легко угробите репозиторий!

Чем не нравится штатный механизм гита — fetch?
Можно и на компе и на ноуте настроить auto-fetch хоть каждую минуту и не париться. Всё что закоммичено — автоматом будет во всех связанных репозиториях.
Это легко и надёжно позволит перемещаться.
А связать можно любые два репозитория напрямую, просто указав в remote ссылки на расшаренные папки с репозиторием.