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

Вы наверное невнимательно читали документацию к SubGit.
Он подключается к голому репозиторию напрямую, и затем синхронизация происходит автоматически.

As soon as initial translation is completed, repos.git is ready to serve users. Pushes to repos.git will be translated to SVN and commits to SVN will be translated to Git.
Note, that repos.git is so called ‘bare’ Git repository, i.e. it does not contain working tree.

Никакой рабочий каталог он не синхронизирует.

Скрипт svn2git собирает Git-репозиторий локально, уже затем вы его отправляете в любой внешний репозиторий. Например, в GitLab.

Даже в инструкции просят устанавливать скрипт на ваш локальный компьютер, а не на сервер GitLab.

Install svn2git on a local workstation rather than the GitLab server

А вы зачем-то заходите в консоль гитлаба и там что-то делаете. Это ошибка, используйте свой компьютер.

Pull Request в GitHub-репозитории можно только закрыть. Удалить созданный ранее PR невозможно.

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

Аккаунт, под которым вы делали push, никак не отразится на самих коммитах. Каким именем вы их подписали при создании, то имя и останется в них навсегда.

Клонирование с заменой файлов не делается никак. В гите нет такой команды.

Вы должны либо очистить целевой каталог перед клонированием, либо как правильно подсказал Василий — просто отменить изменения, ничего не скачивая заново.

Зачем вам Pull? Делайте Clone и всё автоматом свяжется.

exists and is not an empty directory

Клонировать мы должны либо в пустой каталог, либо в ещё не существующий.

Если вы этого не понимаете, то вам нужно срочно учить Git. Это важный навык для программиста.

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

git reset --hard

#### LibGit2Sharp
using (var repo = new Repository("path/to/your/repo"))
{
    Commit currentCommit = repo.Head.Tip;
    repo.Reset(ResetMode.Hard, currentCommit);
}

Что-то не очень понятно что вы хотите сделать.
Если надо просто переключиться в старое состояние, то сбросьте ветку до этого состояния.
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). Никакого коммита слияния при этом не создаётся и конфликтам возникнуть в принципе неоткуда.
Кто с кем должен конфликтовать по вашему мнению?