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

Судя по сообщениям, указатель HEAD ссылается на master, но указатель на сам master повреждён/утерян
Можно восстановить указатель на мастер 'refs/heads/master' заменив его содержимым файла 'refs/remotes/origin/master' . Там хранится последний адрес мастера на момент последней синхронизации (fetch)

Нет запрета на русский язык. Требования к коммитам оговариваются заранее в команде. Но желательно использовать единый стиль в проекте. В гите принято использовать императив в заголовках сообщений. Даже автоматические сообщения пишутся в формате «Merge...», а не «Merged...». На русском языке мы пишем аналогично в повелительном наклонении.
«Добавить фичу...»
«Исправить ошибку...»
Потому что коммит, это не констатация факта изменения проекта, а лишь предложение об изменении, которое в нормальных компаниях не идёт сразу в продукт, а сначала попадает на проверку и лишь потом принимается в проект.

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

Пересади созданную ветку или даже её кусок на мастер.
Либо через интерактивный ребейз склей test+function и удали лишние коммиты из своей ветки.
git rebase --interactive HEAD~5

Проект скачивается командой
git clone адрес_проекта
При этом связь с гибхабом настраивается автоматически

Отключить связь локальной и внешней ветки. Эта связь у каждой ветки своя.
git branch --unset-upstream [локальная_ветка]

Удалить псевдоним адреса внешнего репозитория от которого мы клонировались
git remote remove origin

Ну либо через меню Git — Manage Remotes...


В принципе достаточно последней команды.
Если удалить origin, то очищаются и все связи между ветками, в которых упоминался origin.

Постановка вопроса довольно запутанная. Я понял так:

Как восстановить файлы, которые успели индексировать через git add но затем удалили не закоммитив?

Отменить все неиндексированные изменения позволит команда:
git restore :/

Удалите папку .git — это репозиторий с вашей веткой master в том числе.
Удалите другие ненужные файлы в рабочем каталоге.
Начните новый проект обычным способом.

Файл .gitignore создают не при отправке готовой работы во внешний репозиторий, а задолго до того. Желательно даже вообще до создания первого локального коммита. Это обычный текстовый файл и он создаётся как и любой другой файл с кодом. Мак тут ничем не отличается от винды или линукса. Разве что Finder не показывает имена начинающиеся с точки. Если нажать command + shift + ., то увидишь скрытые файлы. Но мы всё равно создаём файлы в текстовом редакторе или в IDE, а не в проводнике. И редактор и Git этот файл видят в любом случае.

Вот несколько фактов, которые помогут понять как работает Git.

• Файл .gitignore действует только на ещё не отслеживаемые файлы.
  
• Файл .gitignore предназначен для описания того, что мы не хотим СЛУЧАЙНО добавить в репозиторий. Либо не хотим случайно удалить переключив ветку.
  
• Мы можем ПРИНУДИТЕЛЬНО добавить в репозиторий ЛЮБОЙ файл, даже если он описан в .gitignore.
  
• Добавление файла в .gitignore не удалит сам файл из репозитория. Если файл УЖЕ в репозитории, то он продолжит отслеживаться, независимо от наличия .gitignore.
  
• Если больше не хотим отслеживать какой-то файл, то просто удаляем его из репозитория. Ключ --cached позволит оставить файл в рабочем каталоге текущего репозитория если он нужен.
  

git rm --cached -- '.DS_Store'
git commit

Но последний рецепт сработает только на одном компьютере. Если коллеги переключатся на этот коммит, то файл удалится у них из рабочего каталога.

перед коммитов я селектил файлы которые не должны попасть на гитлаб/гитхаб - заносил их в стеш

Зачем так сложно?
Что мешает перед коммитом индексировать только нужные файлы? Зачем ты коммитишь всё?

уже их пушил
Ты хотел сказать «коммитил»?
Пушится всегда вся ветка целиком, коммиты, а не отдельные файлы.

А после разрешения конфликтов ты завершил сбойнувший pull? Изменения то подтянулись в рабочий каталог, но надо бы ещё сам коммит слияния зафиксировать.
Что-то вроде:
git merge --continue

Отменить изменения = внести изменения, противоположные этому.
Например через git revert <хеш>

Эти символы абсолютно идентичны. Используются для относительных ссылок назад в историю от какой либо точки.
Например git reset HEAD^3 переключит текущую ветку на три коммита назад относительно текущего состояния.

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

Репозиторий не хранит права доступа на файлы, как и другие атрибуты тоже. Коммит это не копирование файлов в новое место, а анализ и сохранение их исходного состояния в базу.
Единственный атрибут, который хранит гит — признак исполняемого файла.

core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.

А под кем ты коммитил, совершенно не важно. И уж точно не важно, кто отправлял коммиты во внешний репозиторий (push). Коммиты подписаны хешем и точно не изменятся при передаче.
Права файлов устанавливаются во время извлечения их в рабочий каталог (checkout), и владельцем будет тот пользователь, который извлекал.

А ещё можно попробовать команду
git checkout -
Это вернёт указатель HEAD в предыдущее состояние, в данном случае на вершину вашей ветки.

переадресовал на новый репозиторий

Не понимаю этой фразы. Какая команда такое выполняет?

выполнении команды git push origin master

Если локальный репозиторий склонирован из внешнего, то автоматически создаются связи между ветками.
Не нужно указывать в какой репозиторий (origin) и в какую ветку (master) отправлять текущую ветку.
Достаточно просто git push

выдает сообщение everything up-to-date

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

Но вы точно уверены что текущая ветка называется master, а не main? Давайте узнаем.
Покажите вывод команд
git branch -vv
и
git status

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

Мне нравится актуализировать свои форки через rebase. Так история выглядит прозрачнее.

ЗЫ
В русском языке нет приставки «саб». Надо говорить подпроекты и подмодули. Но они тут не нужны. Обновление прекрасно работает через слияние либо перебазирование.

Откатиться на три коммита назад:
git reset --hard HEAD~3

А вообще не стоит вслепую повторять команды. Лучше прочитать документацию и работать осмысленно.

обязательно ли в названии голого репозитория прописывать в конце .git?

Это не название репозитория, а название папки. Оно может быть любым.

Далее я пользовался документацией 4.2 Git на сервере — Установка Git на сервер

Главой не ошибся? Если у тебя уже есть сервер GitLab, то и читай про него: 4.8 Git на сервере — GitLab

Мне непонятна часть user@git.example.com:/srv/Git

user — имя, под которым ты авторизован через ssh на внешнем компьютере
git.example.com — адрес этого внешнего компьютера
/srv/Git — путь к папке с репозиторием внутри внешнего компьютера

Но это всё тебе не нужно если уже есть сервер. А GitLab это именно сервер.
Не выдумывай ничего и делай по документации.

там первоначально нужно создать пустой проект

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

нажал на синюю кнопку Clone и мне высветились два варианта ссылки

Если работать через https-протокол, то создавать ключи не придётся. Всё станет намного проще.

Дальше ты либо клонируешь его себе на комп через

git clone git@gitlab.com:potemkin277/test-project.git

Либо связываешь свой уже существующий репозиторий с ним

git remote add origin git@gitlab.com:potemkin277/test-project.git

Затем отправляешь свою ветку туда и связываешь локальную и внешнюю ветки -u
git push -u origin ветка