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

Очевидно, что нужно извлечь эту определенную ветку в тот рабочий каталог, в котором вы делаете сборку проекта.

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

Но можно склеить принудительно:

# Сохранить адрес шаблона в переменную template 
git remote add template https://github.com/OWNER/TEMPLATE.git
# Скачать все обновления
git fetch template
# Попробовать сделать слияние ветки BRANCH-NAME шаблона с нашей текущей веткой
git merge --allow-unrelated-histories template/BRANCH-NAME

Опция --allow-unrelated-histories нужна, так как истории веток никак не связаны.

Вот правильный .gitignore

/*
!/test
!.gitignore

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

Прямым текстом написано

You are not allowed to force push code to a protected branch on this project

— у вас нет прав пересоздавать защищенные ветки.

С какой целью вы пытаетесь затереть другой репозиторий, вместо отправки в новый ПУСТОЙ проект?

Git и не удаляет ваши локальные правки. Если вы что-то изменили в рабочем каталоге и не собираетесь это коммитить, то оно и останется в таком состоянии даже после pull. Чаще наоборот спрашивают — почему pull не обновляет такие файлы.

Но всё равно лучше создать отдельный dev-конфиг — так надежнее.

Credential Manager забыли установить.

Рабочий каталог удаляйте таким-же способом.

cd .. # разумеется надо выйти из него
rm -r "название каталога"

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

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

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

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

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

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

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

Неважно, что вы делали, гит перед каждым изменением записывает хэш указателя текущей ветки в специальный журнал — 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.

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

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

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

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

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

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

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

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

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