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

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

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

# Сохранить адрес шаблона в переменную 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 появился в любом каталоге, он сразу начинает работать. Специально ничего делать не нужно.

GitHub Pages предназначен для статических сайтов и не поддерживает серверные языки, включая Node.js. Если ваш Next.js проект использует Node.js для серверной логики, рассмотрите альтернативные платформы хостинга, такие как Vercel, Netlify или Heroku.

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

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/"

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 ветка # отправить текущую ветку в ветку «ветка» и связать их