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

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

В вопросе чувствуется какой-то подвох.
Что именно у вас не получается?
Что имелось в виду под

Разделили по папкам

Когда вы делате pull из main, то эти папки не появляются у вас локально?

git commit -m "first commit"
git push -u origin main

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

Сообщение говорит о том, что последний коммит был сделан шесть часов назад. Даже если Push сделан вот только что.
Если вы что-то делали в рабочем каталоге и забыли закоммитить, то push эту работу никуда отправлять не будет.
Отправляется только то, что закоммичено. Сам рабочий каталог не находится в репозитории.

Зачем вы лезете в папку src? Там же исходники, а не собранный проект.
Сделайте сборку не в dist/, а в папку docs/
При активации GitHub Pages выберите источником не корень проекта /, а папку docs/
Тогда заработает нормальная ссылка https://sivlvy.github.io/

# Откатиться на шаг назад
git reset HEAD~1
# Удалить из проекта ненужное
git rm -r --cached "node_modules" # это точно мусор
git rm -r --cached "src" # вы уверены что это не часть проекта?
# Создать коммит заново
git commit 
# Отправить изменения
git push --force

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

Сообщение говорит о том, что вы просите отравить ветку master в репозиторий origin, но в вашем репозитории нет ветки с таким названием. Гит не нашел что отправлять и сказал об этом. Проверьте какие ветки у вас есть и в куда вы коммитили git branch -vv

Этот вопрос неоднократно поднимался тут. Почему вы не пользуетесь поиском?

Поменялась схема https-авторизации. Чтобы заново авторизоваться, нужно лишь отменить предыдущую авторизацию. И при повторном push ввести полученный на гитхабе «ключ/токен» вместо пароля. Но я бы посоветовал просто авторизоваться через браузер, это проще.

Параметры вашей подписи коммитов user.name и user.email вообще никакого отношения к авторизации не имеют. А сама она не хранится в конфиге гита и к самому гиту никакого отношения не имеет. Вы же не имя и мыло вводили когда авторизовались? В гите вообще нет понятия авторизации. Вы авторизуете на внешнем сервере не гит, а пользователя компьютера. За хранение паролей отвечает credential manager, а сами пароли хранятся в недрах операционной системы, независимо от гита и хорошо спрятаны.

«Забыть» авторизацию текущего пользователя можно такой командой.

echo "url=https://github.com" | git credential reject

Также можно очистить вашу подпись для текущего пользователя компьютера

git config --unset user.name
git config --unset user.email

Но это не имеет отношения к авторизации

1. Форкнуть репозиторий: Создать копию репозитория в своем GitHub аккаунте.
   
2. Сделать изменения: Сделать необходимые изменения в форкнутом репозитории.
   
3. Создать pull request: Отправить запрос на слияние (pull request) в основной репозиторий, описав ваши изменения.
   
4. Ожидать рецензии: Ожидать, пока разработчики проекта или модераторы просмотрят ваши изменения и выскажут свое мнение.
   
5. Поправить замечания: Если требуется, внести исправления в свои изменения в соответствии с комментариями.
   
6. Влить изменения: Если все в порядке, ваши изменения могут быть влиты в основной репозиторий модераторами.
   

Берёте и добавляете отдельные файлы в отслеживаемые репозиторием. Способ добавления всегда один.

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

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

GitHub тут не при чём, он лишь хранит репозиторий как есть, и не умеет игнорировать папки.

Не путайте сайт GitHub с программой GitHub Desktop, которая у вас на скрине.

VSCode уже умеет работать с Git, зачем вам дополнительный клиент?

Игнор действует только на те файлы, которых ещё нет в Git-репозитории.
Но если вы уже закоммитили файлы, то Git в любом случае будет показывать их изменения.
Юра подсказал правильно — вам нужно удалить файлы из репозитория, если вы больше не хотите их отслеживать.

git rm --cached -r .lh/ 
git commit -m "Delete files"
git push

Это значит что ваша ветка не имеет отличий от той, в которую вы делаете пиар. Гитхаб не будет отправлять пустоту, это не имеет смысла. Смотрите внимательно, может коммит на самом деле не создался.

Либо вы перепутали целевую ветку и отправляете изменения не туда.

PS. Так и есть. Вы перепутали ветки. Пытаетесь отправить изменения не в ту ветку, от которой создали свою тематическую. Вы забыли отправить на гитхаб ветку main, которую собственно и хотите менять. А ветка main что сейчас на гитхабе, это совершенно левая ветка.

Не создавайте пустой репозиторий, а клонируйте сразу с гитхаба.
И замените в вашем алгоритме https на ssh и всё заработает.
Только ссылка ssh выглядит чуть иначе и придется создать ключи.

Судя по документации, GitFlowPersistenceProvider не привязан к какому-то конкретному хостингу и позволяет отправлять реестр в любой внешний репозиторий.

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

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

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

Вы наверное хотите скрыть не сам Pull Request, а код, который виден там.
Но ведь этот код студенты отправляют из своих открытых проектов в ваш открытый проект. Значит код в любом случае виден всем в интернете, причем даже без создания PR.
Единственный способ скрыть код — публиковать его в закрытые проекты.
Пусть студенты создают приватные репозитории и дают вам доступ туда.

Проверяйте файл .gitmodules
Смотрите откуда подгружается подмодуль и доступен ли его репозиторий из GitHub.

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

Просто скопируйте закрытый ключ с одного компа на другой и всё. Либо создайте новую пару на втором компе и добавьте ещё один открытый ключ на гитхаб.

Эти желтые плашки не являются основным способом создания PR. Это просто эвристические подсказки, они могут появиться, а могут и нет. Ведь не всегда после пуша требуется создать PR. И не факт, что GitHub угадает, в какую ветку на самом деле надо делать слияние.
Те способы что вы указали, они и являются правильными, и не вижу в них ничего неудобного. Есть и другие способы создания PR, например через команду gh pr create, это тоже корректно.