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

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

Пересади созданную ветку или даже её кусок на мастер.
Либо через интерактивный ребейз склей 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 ветка

Inline Parameters for VSCode добавляет аннотации встроенных параметров при вызове функции, как в JetBrains.

могут выкладывать в проект свои версии

Не могут. Гит это не какой-то FTP-сервер, куда можно выкладывать файлы. Ты можешь только синхронизировать свою локальную ветку и внешнюю на сервере.

в команде непонятно как сохранятся и объединятся правки

Почитай инструкцию к гиту и всё станет понятно. Если вышестоящая ветка (сервер) содержит коммиты, которых ты ещё не видел, то ты просто не сможешь отправить (push). Тебе придётся сначала скачать серверную версию ветки (fetch) и потом объединить на своём компьютере две версии кода (merge).
Если вы работали над разными фрагментами файла, то слияние произойдёт автоматически и ничего не затрётся.
Получится новый файл, который содержит общую работу. Потом ты сможешь отправить уже свою работу во внешний репозиторий (сервер).

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

Не совсем понимаю, как настроить синхронизацию папок именно с сайтом через гитхаб

Это называется CI/CD. Доставка файлов на собственно на сайт настраивается отдельно. Не надо ставить гит на сервер.

Нормально ли в гитхаб завести репозиторий типа песочницы, и хранить там разные куски кода

Репозиторий заводить для этого не очень удобно. Лучше храни куски кода на https://gist.github.com.