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

Конфликт означает, что после того, как вы ответвили от мастера свою тематическую ветку, сам мастер во внешнем репозитории изменился. Кто-то тоже успел добавить в мастер новые коммиты и изменить эту же самую строку либо соседнюю.
Скорее всего в мастере уже нет строки value: test-1
Git теперь резонно спрашивает что делать. Вы не должны тупо затирать чужую работу, а скачать её себе, сравнить со своей и разрешить конфликт, если он есть.

Git это модульная система. Некоторые компоненты нужно устанавливать дополнительно, в том числе Git LFS for GitHub

Но зачем ты пихаешь в репозиторий архивы с резервными копиями?

GitHub показывает тебе текущее состояние проекта. Если ты раньше видел файлы, которых сейчас не видишь, значит ты эти файлы удалил. Тут невозможна ситуация, когда файлы есть, но скрыты.
Но файлы по прежнему остались в репозитории, так как история хранит ВСЁ.

git log --name-status --diff-filter=D # посмотри какие коммиты удалили файлы
git revert 0c76ed82d8a98bb9cae19a74fe4733c4f0c650d5 # отмени операцию удаления

Судя по сообщениям, указатель 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

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