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

Верно. Если не делать коммит, то он и не получится.

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

Permission to {repo} denied to {user}

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

Параметры user.name и user.email не имеют никакого отношения в вашим GitHub-аккаунтам.
Это лишь реквизиты, которыми будут подписаны новые коммиты на вашем компьютере и всё.
Вы же не думаете, что достаточно знать ваше полное имя и мыло, чтобы войти в аккаунт?

Если интересно, какой параметр в каком файле сохранён, воспользуйтесь командой.
git config --list --show-origin
system лежат в каталоге самого гита и действуют глобально на репозитории всего компьютера.
global хранятся в каталоге пользователя и влияют на все репозитории текущего пользователя.
local сохраняются в каталоге репозитория и действуют только на этот репозиторий.
Одинаковые параметры могут дублироваться в разных конфигах и тогда используется самый локальный.

Но! Ваша ошибка при push связана лишь с неправильной авторизацией. Разбирайтесь с ней, а не с тем, как подписаны коммиты.

Авторство коммитов на авторизацию не влияет вообще, от слова совсем. Можете подписаться хоть как Билл Гейтс. После отправки коммитов на гитхаб они не изменятся. Коммиты вообще в принципе никогда не изменяются, по определению. Можно лишь их пересоздать заново с другим содержимым и описанием.

Команда git remote prune origin удалит ссылки на вышестоящие ветки, которых уже нет на сервере origin, но не тронет соответствующие локальные ветки, которые были с ними связаны.

Удалить локальные ветки, которые связаны с несуществующими внешними можно примерно таким скриптом:

#!/bin/bash

# Получить список веток, которых уже нет на внешнем сервере
missing_branches=$(git branch -vv | grep ': gone]' | awk '{print $1}')

# Удалить каждую локальную ветку, у которой удалена её вышестоящая ветка.
for branch in $missing_branches; do
    git branch -D $branch
done

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

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

У Git нет команды «подключиться к репозиторию». Да и как к нему подключаться, если репозиторий это просто каталог? Вы наверное пытаетесь утилитой ssh подключиться к какому-то серверу, на котором лежит репозиторий. А зачем? Git-хостинги не предоставляют доступа к командной оболочке своих серверов, это же не vps.

Восстановить очень легко, так как гит ничего не удаляет из репозитория, по крайней мере сразу.
Команда reset лишь переместила указатель ветки. Полностью удалить что-то крайне сложно.
Вы можете посмотреть через git reflog где был указатель до этого и вернуть его туда обратно.
git reset --hard HEAD@{1}
Данная команда вернёт ветку на состояние, помеченное на вашем скрине как HEAD@{1}
Либо можно скопировать непосредственно sha-хэш места, куда хотите вернуться.

Затем повторить отмену последнего коммита, но уже правильно:
git reset HEAD~1
Такая команда не будет изменять рабочий каталог, а значит ничего из него не удалит.

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

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

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

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

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

Гит не умеет врать. Вы уверены, что отправляете именно в ту ветку, которую потом проверяете на гитхабе?
Покажите вывод команд

git status
git branch -vv
git config --list --show-origin

ЗЫ. Так и оказалось. Вы коммитили в безымянную ветку, а отправляли другую. Поэтому вам и пишет, что отправлять нечего. Если бы вы пушили просто текущую ветку, т. е. без указания имени (git push), то сразу бы получили ошибку и поняли, что не так. Вы не должны каждый раз указывать куда и что отправлять. Достаточно в первый раз добавить ключик -u и ветка будет знать, с какой внешней веткой она связана.

Изменение автора каждого коммита в локальном репозитории с использованием инструмента git filter-repo может выглядеть следующим образом:

#!/bin/bash

authors=("test <test@gmail.com>" "another <another@example.com>")

for commit in $(git rev-list --all); do
    author=${authors[$RANDOM % ${#authors[@]}]}
    git filter-repo --commit-callback "commit.author_name = '$author'; commit.author_email = '$author'" --path-commit $commit
done

В этом примере массив authors содержит список новых авторов в формате "Имя <адрес-электронной-почты>". Скрипт выбирает случайного автора из этого списка для каждого коммита и использует инструмент git filter-repo для изменения автора коммита.

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

Примечание: Убедитесь, что у вас установлена последняя версия git filter-repo, поскольку инструмент может быть доступен как отдельный пакет или как часть Git.

И код я не проверял, не обещаю что он заработает.

При обновлении мастера, нужно обновить и эту локальную ветку, сейчас я это делаю в *dev

git switch master & git pull & git switch - & git merge master

Зачем усложняете? Достаточно одной команды
git pull origin master

читал что так делать не стоит

Эти писатели сами не понимают что пишут. Если тематическая ветка короткоживущая, то наоборот лучше не засорять её коммитами слияния, а каждый раз лучше пересаживать на вершину мастера.
git pull --rebase origin master

А ещё можно задать глобальный параметр
git config --global pull.rebase true
И тогда простой pull сразу будет делать rebase без отдельных напоминаний

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

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

Если вы эти пароли не записали в заметках или каком нибудь другом незашифрованном месте, то никто их и не украдёт. А мастер в сервисе сможет залогиниться под гостем если понадобится. Только не забудьте разблокировать Гостя если он выключен.

Хотя чтобы увидеть что батарея работает, не требуется заходить в систему. Просто не давайте паролей и всё.
И любой сервис заставит вас подписать бумажку о том, что они не отвечают за сохранность ваших данных. Поэтому резервная копия в Time Machine у вас должна быть по определению.

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

Вангую, что ветка main не содержит ни одного коммита: src refspec main does not match any. Отправлять просто нечего.

Вы, наверное, вслепую выполнили заклинания git add и git commit, но проигнорировали предупреждение, в котором говорилось, что у вас там, наверное, подмодуль в каталоге my-app и он должен отслеживаться в собственном репозитории. Команда git status должна подтвердить мою догадку.

Разве корень проекта не должен находиться в каталоге my-app?

Удалите ваш ещё пустой репозиторий (папку .git), который вы создали в каталоге react-code, и откройте в WebStorm каталог my-app, в котором репозиторий уже есть. Он инициализировался, когда вы делали create-react-app.

Либо удалите папку my-app/.git и тогда сможете закоммитить каталог my-app в ваш текущий репозиторий. Предварительно попросив «забыть» про фиктивный подмодуль git rm --cached "my-app"

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

git checkout -
Отменит предыдущий checkout

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

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

Решение предельно простое. Допустим у нас есть проект в котором ветке main лежат две папки: client и server

Команда git subtree push --prefix client origin client отправляет ваш клиент из подкаталога client в локальном репозитории в ветку client внешнего репозитория origin.

Конкретно в этом случае:

git subtree push — запускает команду Git для отправки изменений из подкаталога во внешний репозиторий.
--prefix client — указывает на подкаталог client, который необходимо отправить во внешний репозиторий.
origin — имя внешнего репозитория, куда будет отправлено содержимое подкаталога.
client — название ветки, в которую будут отправлены изменения.

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

Аналогично с сервером git subtree push --prefix server origin server