Ну вот, Иван был прав. Вы внутрь вашего репозитория пытаетесь добавить вложенный репозиторий. Только в терминах гита это называется поддерево. Зачем вам это?
Возможно удаление подпапки .git там исправит ситуацию. И покажите gitignore оттуда.
Корне репозитория у вас нет случайно файла .gitmodules?
Если есть сеть, то он пытается найти контроллер домена, который проверит пароль.
Попробуйте не входить в домен, а логиниться в локальную учётку. Тогда вход будет быстрый.
TemaKam, в базу залезать не надо, всё намного проще.
Reflog это просто текстовый файл, в котором пишутся значения указателей веток.
И стандартной командой эти указатели можно вывести на экран и «вспомнить» удалённую ветку.
TemaKam
Можно считать что коммит потеряется, но если не было сборки мусора, то через команду reflog мы всё равно сможем добраться до коммита при желании.
В гите ну очень сложно что-то удалить умышленно.
TemaKam, коммит же может принадлежать нескольким веткам.
И как я уже сказал, ветка это не цепочка коммитов с именем.
Ветка это просто именованый указатель на определённое место в дереве коммитов.
Такой же указатель как и тег, но только тег не двигается при добавлении новых коммитов.
Более того, коммиты это неизменяемые сущности. В гите в принципе нет команды «удалить коммит». Едиственный способ избавиться от коммита, это удалить всё что указывало на него, и затем запустить сборку мусора, которая удалит из базы все беспризорные коммиты.
Да, проблема. Попробуйте задать вопрос по-русски, пожалуйста.
git add для третьего компонента вроде как проходит без проблем
Как вы поняли что без проблем? Там обычно никаких сообщений не выдаёт.
Покажите полностью команду git add...
И интересно взглянуть что внутри каталога ls -la "./mainapp-ui/"
Надо понимать, что в гите ничего не удаляется, но лучше запомнить ту точку, в которой вы сейчас оказались. Т. е. поставить на вершине новой цепочки коммитов указатель новой временной ветки. Тогда ваши новые коммиты будут на виду и никуда не «пропадут».
Потом отменить rebase чтобы указатель мастера вернулся на изначальное место. И через cherry-pick перенести новые коммиты из временной ветки.
И работать лучше не в терминале, а в нормальном графическом клиенте, чтобы всегда видеть перед глазами всю картину.
Новоселов Андрей, отмена не удалит никаких коммитов существовавших до начала rebase! Только если вы не решили добавить новых коммитов в этом состоянии. Тогда можно завершить.
Новоселов Андрей, при продолжении произойдёт ровно то, что вы заказали. Один коммит дропнется. Но что будет результатом revert-коммита я предсказать не могу. Скорее всего получится ерунда. Как можно описать дейстивие отмены того, чего не было?
Если уж дропать в данной ситуации, то дропать оба коммита вместе.
И вы в курсе последствий изменения истории ветки master? Если вы работаете не один, то так просто мастер вы не сможете пересобрать. Так как всё это происходит только у вас локально, а на компьютерах коллег останется старый мастер, до того, как вы своими действиями его удалили у себя и создали новый. Коллегам придется у себя его удалять и скачивать заново новый. Спасибо они вам точно не скажут.
Veeam всё это умеет в бесплатной версии. Надёжен и быстр. Бэкапит виртуалки vSphere и Hyper-V, физические компы Windows и Linux, умеет бэкапить NAS. Умеет immutable репозитории и быстрые синтетические бэкапы.
Дело в том что у вас локальная main и main на гитхабе, это совершенно разные ветки. Вы создали тематическую ветку от локального main, а пытаетесь влить её теперь на гитхабовский main. Но эти ветки не имеют общей истории.
Зелёный ярлык это локальная main и эта ветка никак не связана с внешней origin/main с гитхаба.
Вы забыли запушить локальную main на гитхаб. А на гитхабе сейчас не ваша main, а та, которую создал гитхаб когда вы создали непустой репозиторий (поставили галку создать readme)
Переключитесь на локальную main и отправьте её тоже на гитхаб. Но придется отправлять принудительно, так как там уже есть другая ветка с таким же названием. git push --force
И тогда всё наладится.