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

Пароль нигде не посмотреть. GitLab не позволяет аутентифицироваться по паролю при использовании протокола SSH. Вместо этого GitLab использует криптографию с открытым ключом для аутентификации по SSH.

Чтобы аутентифицироваться по SSH с помощью GitLab, вам нужно сгенерировать пару ключей SSH на локальной машине и добавить открытый ключ в свою учетную запись GitLab. После добавления вашего открытого ключа в учетную запись вы можете клонировать репозитории GitLab и выполнять другие операции Git с использованием протокола SSH, не запрашивая пароль.

Добавление ключа SSH в свою учетную запись GitLab

Если не хочется возиться с ключами — используйте HTTPS-протокол.

Скачиваются всегда все файлы, но вам нужно их ещё вытащить из репозитория в рабочий каталог. Если вы что-то ранее удалили в рабочей копии, то команда pull это не восстановит. Pull не предназначен для этого.
Сделайте git reset --hard чтобы очистить рабочий каталог от ваших незакоммиченных изменений/удалений и увидеть что на самом деле сейчас в ветке.

Такая практика называется вандализмом и не является приемлемой.

Создать коммит Х2, который отменит все новые изменения master можно например так

# Вредоносные действия делаем в своей ветке, 
# так как не можем коммитить напрямую в master
git switch feature
# Якобы подтягиваем изменения из master, но по факту отменяем.
git merge --ff $(git commit-tree -p master -p feature1 -m "X2" feature1^{tree})
# Отправляем Pull Request обратно в master

Но зачем? Практика перезатирания чужих правок ненормальна, если только это не исправление ошибок.

Чтобы бороться с вандализмом используется рецензирование, когда Pull Request не вливается в основную ветку пока другие люди не просмотрят изменения и не одобрят.

Локально откатили правильно, о чем статус и сообщает. Только нужно наверное было делать reset --hard, чтобы рабочий каталог тоже откатился. Вам осталось только отправить это на гитхаб.

Ветка меняет название только если вы сами её переименуете командой переименования.
И эта команда не reset.

Сообщение говорит о том, что вы просите отравить ветку master в репозиторий origin, но в вашем репозитории нет ветки с таким названием. Гит не нашел что отправлять и сказал об этом. Проверьте какие ветки у вас есть и в куда вы коммитили git branch -vv

Вы не авторизовались на GitHub. Либо авторизовались неправильно.
Если уставлен актуальный официальный Git, то при первом push должно было спросить как вы хотите авторизоваться, через браузер или через токен.
Если сразу спрашивает имя и пароль, то вводить надо не тот пароль, с которым вы заходите на сайт, а вставлять токен.

Этот вопрос неоднократно поднимался тут. Почему вы не пользуетесь поиском?

Поменялась схема 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

Но это не имеет отношения к авторизации

Команда git-show не открывает файлы, а показывает содержимое коммита.
И не в Vim, а в программе-пейджере less

Промежуточные подкаталоги тоже нужно добавлять в исключения

/parent/folder/*
!/parent/folder/child
/parent/folder/child/*
!/parent/folder/child/css
/parent/folder/child/css/*
!/parent/folder/child/css/something.css
!/parent/folder/child/js
/parent/folder/child/js/*
!/parent/folder/child/js/something.js

Но с такими цепочками правил есть смысл заморачиваться только ради исключения целых подкаталогов. А отдельные файлы можно начать отслеживать принудительно используя опцию --force

Чтобы сделать исключение для одного файла или папки, которые игнорируются в .gitignore, необходимо добавить путь к этому файлу или папке на новой строке в файл .gitignore с префиксом «!» (без кавычек). Например:

# .gitignore
/folder_to_ignore/
!/folder_to_ignore/important_file.txt

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

# игнорируем весь каталог
/folder_to_ignore/ 
# кроме его подкаталога
!/folder_to_ignore/subfolder 
# всё равно игнорируем содержимое подкаталога
/folder_to_ignore/subfolder/* 
# кроме одного файла
!/folder_to_ignore/subfolder/important_file.txt

Если такой файл лишь один, то можно не заморачиваться с правилами, а просто один раз индексировать файл принудительно. Тогда он начнёт отслеживаться.
git add --force "path/to/file.txt"

Команда 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. А потом смотрите что получилось.