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

Другом ответе показали обходное решение с переходом на 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

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

Ваша проблема в том, что при изначальном создании приложения командой 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

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

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

Перед запуском тестов вы должны подгрузить из main все обновленияк к себе: git merge main
Так вы заранее решите конфликты и их не будет когда уже вашу ветку будете вливать в main. И тесты будут прогоняться на актуальной кодовой базе, а не на устаревшей.

Нет, каталог Applications не нужно коммитить в Git. Судя по скрину, вы уже закоммитили его. Удалите каталог из репозитория и пропишите его в игнор, чтобы снова не закоммитить случайно.

И переформулируйте вопрос. Ответ на вопрос «как правильно добавить в игнор» уже содержится на вашем скрине.

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

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

SpckEditor поддерживает только персональные токены, но GitFlic похоже не умеет с ними работать. Там OAuth-авторизация.. Если вы только начинаете изучать Git, то попробуйте использовать что-то стандарное, типа GitGub или GitLab. Там можно создать токены персонального доступа. Токены развертывания это другое.

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

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