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

Держите всё в одном репозитории. Для каждой версии API своя долгоиграющая ветка.
Изменения между версиями легко перекидывать через cherry-pick, например.
Зачем усложнять себе жизнь ручным копированием изменений, когда есть Git?
Ну а разные рабочие ветки с разными API распаковываете каждую в свою рабочую папку если хочется.
Git поддерживает множественные worktree.

Либо в каждой папке свой собственный репозиторий и cherry-pick используем для обмена коммитами между версиями. Вообще никаких проблем нет, главное связи настроить. Git — распределённая система.

Rebase это по сути cherry-pick нескольких коммитов за раз — пакетный режим.
Вот и вся разница.

Против идиотских правительственных запретов пока спасают VPN-сервисы. Работайте через них.

Ошибка «cannot overwrite multiple values» ровно это и означает.
Нельзя переписать уже существующий в другом месте уже псевдоним. Вам нужно либо использовать ключ, который Git предлагает в сообщении, которое вы процитировали, либо руками удалить дубли.

Эта команда покажет в каких они файлах.
git config --show-origin --list
Найдите дубль и просто удалите через текстовый редактор.

Любой Git-клиент, например SmartGit, если включить опцию показа неизменённых файлов в панели Files.

Коммиты удалить нельзя, но можно переключить указатель ветки на один шаг назад
git reset --hard HEAD~1
Тогда последующий коммит «исчезнет» из истории.
Но на скрине вы вообще не находитесь ни в какой ветке. Не забудьте создать ветку в этом месте, чтобы не потерять работу.

Вы путаете теплое с мягким. На первом скрине лог событий отправки ВЕТОК на сервер. Там не отображаются коммиты и авторы коммитов. На второй лог КОММИТОВ. Авторство коммитов не меняется во время Push и зависит только от того, кто их создал. Никаких противоречий в скрине нет. Авторство коммитов могло быть изменено любым из инструментов пересборки истории. Например amend или filter-repo.

В интерфейсе GitHub есть специальная кнопка для этого.

Конфликт означает, что после того, как вы ответвили от мастера свою тематическую ветку, сам мастер во внешнем репозитории изменился. Кто-то тоже успел добавить в мастер новые коммиты и изменить эту же самую строку либо соседнюю.
Скорее всего в мастере уже нет строки 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

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