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

Команда git push origin master означает «отправить локальную ветку master в репозиторий origin». Если в ответ вам выдало сообщение, что нечего отправлять (Everything up-to-date), значит вы сейчас не находитесь в ветке master, а работаете в какой-то другой ветке, либо вообще вышли из всех веток (Detached HEAD). Поэтому команда git commit добавляет коммит не в master, а куда-то ещё, и соответственно отправлять из мастера нечего.

В таких случаях только git status поможет узнать точную причину и подскажет решение.

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

установил msys2 и git

VS Code наверное не видит эту вашу конструкцию.
Попробуйте установить Git for Windows.

Хотя что вы имели в виду под «не видит»?
Если создаёт и клонирует, значит уже видит.

Команда npx create-react-app по умолчанию инициализирует репозиторий внутри каталога приложения. Так как обычно приложение разрабатывают в отдельном репозитории, а не встраивают в другой проект. Говорят есть ключик --skip-git, который помогает не создавать репозиторий, но я не проверял.

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

Вам нужно сделать две вещи:
1. Избавиться от вложенного репозитория, удалив каталог .git внутри mainapp-ui
2. Удалить из репозитория информацию о каталоге, если ранее успели добавить
git rm --cached mainapp-ui
Затем снова попробовать индексировать каталог
git add mainapp-ui
Теперь он уже должен добавиться как каталог, а не как поддерево (subtree)

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

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

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

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

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

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

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

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

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

Гит не просто «что-то говорит», а конкретно сообщает что вы находитесь в состоянии незаконченного перебазирования и сообщает «как убрать».
Вы должны либо продолжить и довести перебазирование до конца
git rebase --continue
Либо отменить процесс через
git rebase --abort

Я бы на вашем месте как раз отменил, так как вы делаете что-то странное. Сначала дропнули из истории один коммит, потом попытались применить его отмену и скорее всего получили сложный конфликт. Что вообще пытаетесь добиться?

Если вы, не осознав что rebase ещё не закончился, продолжили добавлять новые коммиты, то тогда завершите rebase. А потом смотрите что получилось.

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

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

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

Проще всего удалить локальный master, тогда и запрещать ничего не придётся.
Нет master — нет проблемы. А новые ветки создавайте от origin/master

В гите ничего нельзя удалить.
Чтобы отменить какое-то действие, можно создать новый коммит, который делает противоположное изменение.
Либо просто передвинуть указатель ветки назад, на состояние до слияния.
Всё это делается на локальной копии репозитория и затем отправляется на GitLab.

Cвоим amend вы фактически удалили тематическую ветку и создали новую версию.
После этого надо было отменить предыдущее слияние через reset.

Но текст ошибки говорит о том, что вы делаете новое слияние не завершив предыдущее.
Возможно слияние остановилось на конфликте, но вы проигнорировали это.
Определитесь что именно хотите сделать.
Либо разрешить конфликт и затем завершить слияние git merge --continue
Либо отказаться от слияния и всё отменить git merge --abort

Можно и не создавать, но будет неудобно. Особенно если вы привыкли коммитить всё без разбору, а не только нужные файлы. Файлы игноров уменьшают вероятность закоммитить мусор.

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

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

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

Git заточен на отслеживание только текстовых файлов. Они будут храниться эффективно, без дублирования. Двоичные файлы будут сохраняться в репо каждый раз целиком, даже если изменили один байт.

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

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

Другое дело что у Bitbucket/GitHub/GitLab есть API, позволяющие вытаскивать информацию через него. И если эти API требуют авторизации, то вы наверное не сможете без авторизации обойтись. Это тоже к самому гиту не имеет отношения. Тут вы работаете лишь с API этих сайтов.

Rebase это всегда повторная сборка ветки. Старая ветка как бы удаляется и собирается новая, с таким же названием но новым содержимым. Вы точно уверены что хотите проделать это с общей веткой? Ведь тогда коллегам тоже у себя придётся удалить эту ветку и скачать заново вашу новую.

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

Вы наверное невнимательно читали документацию к SubGit.
Он подключается к голому репозиторию напрямую, и затем синхронизация происходит автоматически.

As soon as initial translation is completed, repos.git is ready to serve users. Pushes to repos.git will be translated to SVN and commits to SVN will be translated to Git.
Note, that repos.git is so called ‘bare’ Git repository, i.e. it does not contain working tree.

Никакой рабочий каталог он не синхронизирует.