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

В 2023 году рекомендованным методом является использование пакета filter-repo
Задача решается буквально одной командой

# Клонируем репо в соседний каталог
git clone --no-local . "../repo2" # тут будет новый репозиторий
# Перейдем в новый репо 
cd ../repo2 
# Оставим в проекте только содержимое подкаталога folder2, 
# сделав его новым корнем проекта
git filter-repo --subdirectory-filter "folder2/"

Veeam Backup полностью удовлетворяет вашим условиям.
1) 2) Копируются только изменения. Первый полный бэкап можно и потерпеть (либо использовать переносной диск), дальше создаются синтетические полные копии быстро если надо.
3) Управление всеми копиями из единой админки
4) Поддерживаются репозитории на ReFS под Windows и XFS на Linux. Оба варианта поддерживают быстрое виртуальное клонирование секторов. У меня на одном архивном томе в 5ТБ помещается 18ТБ бэкапов. Каждый день инкрементный снапшот, один комп вообще каждые два часа сохраняю. Раз в неделю создаются полные копии на основе предыдущих инкрементов.
5) Сервер управления там только под Windows, но на Linux можно хранить репозиторий в XFS, что даёт так же дополнительную фичу неизменяемых бэкапов. Чтобы даже в случае компрометации сервера, вирус не смог бы удалить бэкапы.

В любой непонятной ситуации смотрите git status — там будут все подсказки.

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

Чаще всего люди спрашивают об обратном — почему такая подсказка у них не вылезла, так как они не знают других способов создать Pull Request. Они привыкли, что гитхаб обычно додумывает за них.

Ещё вы можете нажать на кнопку, но запрос не создавать. Плашка больше не появится.

Серый цвет у вас скорее всего означает что эти объекты подпадают под игнор.
Желательно вывести их из игнора, иначе придется индексировать принудительно каждый файл с опцией force
И не забывайте, что используемый вами ключ --all не будет добавлять в репо новые файлы, обработаются только уже существующие но измененные файлы.

Эти папки у вас существуют только в рабочем каталоге и их нет в репозитории, потому что гит отслеживает только файлы. Невозможно закоммитить пустой каталог. Каталоги фигурируют лишь как часть полного пути к файлам.

Если вам нужно непременно сохранить структуру каталогов, то поместите в них любой файл. Стандартная практика — создавать пустой файл с именем .gitkeep

Вы же не на пустом месте ветку создали? В момент создания ветки «в неё» сразу попадают все предыдущие коммиты вниз по истории дерева коммитов. И после отправки, в ветке внешнего репозитория появится ровно столько коммитов, сколько было в локальном.

Другими словами — ветка это не какое-то хранилище, в которое складываются коммиты. Ветка это указатель на точку на дереве коммитов проекта. А дерево уже содержит все коммиты проекта.

Неважно, что вы делали, гит перед каждым изменением записывает хэш указателя текущей ветки в специальный журнал — reflog. Соответственно вы можете этот журнал посмотреть командой git reflog
А можно просто сослаться на порядковый номер в журнале и откатить текущую ветку на два шага назад:
git reset --hard HEAD@{2}
Как-то как.

Если вы под головным коммитом имеете в виду самый последний и нужно «удалить» предыдущий коммит, то можно использовать опцию --onto, предназначенную для перемещения произвольных цепочек коммитов на новое место:

git rebase --onto <новая база> <старая база> <конец цепочки>

или для вашего случая:
git rebase --onto HEAD~2 HEAD~1 HEAD

o———A ← HEAD~2
     \
      B ← HEAD~1
       \
        C ← HEAD

Получим:

o———A ———С' ← HEAD
     \
      B

Единственный такой проект, о котором я слышал — это разработка ядра Linux. Там изначально велась разработка по почте. Да и сейчас кажется ничего не изменилось. На гитхабе мы видим лишь зеркало проекта. Гит изначально был придуман Торвальдсом специально так, чтобы он максимально прозрачно интегрировался в такой процесс. Даже коммиты при просмотре выглядят как электронные письма — там есть имя и мыло автора, тема, тело с подробным описанием изменений…

А ответ на вопрос «как?» вы найдете в официальной книге Pro Git. Там этому посвящена целая глава. Учебник продолжает дополняться и переписываться сообществом, в том числе и на русском.

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

git branch ветка # придумать название вашего проекта
git switch ветка # сделать эту ветку текущей
git push -u origin ветка # отправить текущую ветку в ветку «ветка» и связать их

Последний коммит отмените, а первый пересоздайте

git reset HEAD~1
git commit --amend

Либо этими командами в терминале, либо мышкой в интерфейсе PhpStorm.

Если задали пароль ключа, при его создании, то он спрашивается при использовании.
Настройки GitHub Desktop тут никак не влияют.

Вы путаете консоль с терминалом. Мы не используем консоль, а лишь смотрим что там выводится. Это не командная оболочка.

Консоль, это то место, куда попадает вывод команд гита которые вызывает сам PyCharm. Это удобно в процессе обучения, так как вы видите, что на самом деле означают кнопки в интерфейсе программы.

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

Оба способа правильные и мы используем тот, что ускоряет работу и делает её удобнее. Намного проще нажать одну кнопку на панели, чем вбивать длинные заклинания в терминал.

Ну а по поводу оторванной головы вам подробно ответил Андрей.

Автор коммитов задаётся этими параметрами

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

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

Если вы изменяете файл в рабочем каталоге, но не хотите, чтобы это изменение попало в ветку, то просто не отправляйте изменение в ветку. Коммитьте только те изменения, которые должны попасть в проект.
Если вы уже успели в тематической ветке изменить файл, который изменять было нельзя, то отмените его изменение в этой ветке. Только так вы сможете исключить этот файл из Pull Request.

Всё очень просто. На портах 80/443 вешаете не сайт, а обратный прокси.
Для Proxmox уже есть готовый контейнер Nginx Proxy Manager LXC
В нем разруливаете сколько угодно сайтов на вашем белом IP, там управление мышкой в веб-интерфейсе.
И сертификаты для https там создаются легко.

Если нужно вытащить отдельные файлы из другой ветки, используйте checkout
git checkout ветка -- путь/к/файлу
Это извлечет файл в рабочий каталог. Останется только его закоммитить в текущей ветке.

remote amvera already exists

Вы пытаетесь добавить remote с именем amvera,

git remote add amvera https://git.amvera.ru/<имя-пользователя>/<транслитерированное-имя-проекта>

Если вам пишет, что такой remote уже существует, значит вы ранее уже это сделали.
Зачем вы пытаетесь добавить адрес повторно?

Подскажите, что с этим можно сделать?

Если вы хотите заменить ранее добавленный адрес, то либо предварительно удалите предыдущий remote
git remote remove amvera
либо используйте команду замены
git remote set-url amvera ...

Почитайте, что делает опция --hard команды reset.