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

В файл 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 ссылки на расшаренные папки с репозиторием.

Зачем писать сообщение коммита через терминал? В самом IDE же нормальный интерфейс для коммитов? Через терминал вы всё равно не сможете больше одной строки вставить в сообщение.

Git Bash внутри IDE он абсолютно такой же, как тот что запускается отдельным окном.
Но там почему-то настройки локализации не передаются.
Помогает правка .bashrc, добавьте туда строки

LANG="ru_RU.UTF-8"; export LANG
LC_ALL="ru_RU.UTF-8"; export LC_ALL

Возможно станет получше.

Наверное так
repo.delete_remote(remote)

Нельзя. В веб-интерфейсе нет инструментов перебазирования или доступа к консоли.
Но вы можете легко откатить изменения к тому состоянию, которое осталось локально.
git push --force

Единственно правильного способа нет, их несколько и все могут быть правильными, в зависимости от того, чего вы хотите добиться и как принято работать в вашем проекте/команде.

Итак, сейчас вы находитесь в своей тематической ветке #1234 и вызвали контекстное меню основной ветки develop.

Compare with "#1234"

— сравнить ветку на которую вы кликнули (это develop) с текущей веткой #1234

Rebase "#1234" onto "develop"

— пересоздать/пересобрать тематическую ветку #1234 поверх (onto) актуальной ветки develop. Будет выглядеть как если бы вы создали свою ветку только что, и она по определению будет содержать все актуальные изменения основной ветки. Этот способ годится только если вы работаете один в тематической ветке, потому что мы фактически удаляем её и создаём новую. Если ветка общая, то в репозиториях коллег ничего автоматом не перестроится.

Merge "develop" into "#1234"

— забрать изменения из develop в нашу (into) ветку #1234 путем создания коммита слияния (merge commit). Такой способ способ обычно используют для синхронизации долгоживущих общих веток.