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

Под памятью тут имеется в виду оперативная память. Видимо на хостинге она сильно ограничена.
Тут написано что клонирование прошло успешно и сбой прошел уже на этапе распаковки файлов в рабочий каталог.
Вы пробовали узнать что проиходит через git status?
Ну и сделать как советуют
git restore --source=HEAD :/

Permission to {repo} denied to {user}

Это говорит о том, что авторизация прошла успешно, но данному пользователю не предоставлено прав на запись в репозиторий. Ошиблись при создании токена.

GitHub Pages поддерживает только статические сайты, а EJS является шаблонизатором, работающим на стороне сервера. Вместо того, чтобы использовать EJS для рендеринга на клиентской стороне, вы можете предварительно сгенерировать HTML-файлы с помощью EJS на вашем локальном компьютере, а затем разместить их на GitHub Pages. Если ваш сайт зависит от серверных операций или динамического контента, вам нужно будет найти другой хостинг.

не позволяет использовать 1 ключ в нескольких репозиториях

Также наверное нельзя одновременно несколько разных ключей использовать для доступа к одному серверу.

Скорее всего нужно подсказать хосту, какой именно ключ использовать для каждого из подмодулей.
Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github.com-module-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-1_deploy_key

Host github.com-module-2
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-2_deploy_key

И поправьте ссылку на подмодуль в .gitmodules используя псевдоним виртуального хоста
git@github.com-module-1:OWNER/repo-submodule-1.git

Сам не проверял, пишу основываясь на официальной документации GitHub:
Authentication / Connect with SSH / Managing deploy keys

Другом ответе показали обходное решение с переходом на SSH-протокол.
Оно конечно сработает, но что, если нужно-таки работать через HTTPS?

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

Предварительно придется отменить старую неудачную авторизацию,
особенно если вы зачем-то ранее ввели пароль вместо токена.

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

На рабочем компе предпочитаю HTTPS, так как он удобнее и надежнее. Причем без токенов, достаточно OAuth-авторизации через браузер. После первого push вход происходит буквально в один клик.
Не надо никуда ходить, не надо создавать ключи или токены, всё работает автоматически.
Если у вас не предлагает такой авторизации, значит гит старый, либо неполный, установлен без credential manager.

Нажав кнопку Edit, вы сможете не только название PR отредактировать, но и сменить целевую ветку.

Если вам именно видосы заходят, то посмотрите серию мультиков Git: курс — там максимально наглядно.
Но просмотра видео или прочтения статей недостаточно чтобы начать понимать.
Рекомендую пройти бесплатный курс Введение в Git из 16 уроков с практическими упражнениями.

Есть официальная книга Pro Git, она сложновата для новичков, но её тоже стоит прочитать позже.

Как так получилось, что вы обнаружили проблему только при отправке на гитхаб? Вы вообще не используете гит в локальной разработке?

Ваша проблема в том, что при изначальном создании приложения командой create-react-app сразу инициализируется Git-репозиторий внутри каталога с приложением. Если вы решили не работать в этом репозитории, а отслеживать изменения client и server в другом общем репозитории, то вам нужно удалить тот вложенный репозиторий из папки client. Иначе гит будет игнорировать изменения там и подумает что это вы подключили подмодуль (submodule).

# удалите папку .git, которая внутри каталога client
rm -rf "client/.git"
# скажите гиту, чтобы он забыл, что перед этим видел там вложенный репозиторий 
git rm --cached "client/"
# теперь получится добавить приложение в ваш основной проект
git add "client/"

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

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

Например пересадить вашу локальную ветку поверх того коммита с гитхаба
git pull --rebase origin main

Либо через коммит слияния
git pull --allow-unrelated-histories origin main

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

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

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

Когда вы делате 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 что сейчас на гитхабе, это совершенно левая ветка.