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

Есть экспериментальная команда sparse-checkout, которая распаковывает в рабочий каталог только некоторые папки, но сам локальный репозиторий всё равно будет содержать весь проект.

Удалить файл из репозитория, при этом не удаляя его из рабочего каталога, можно командой

git rm --cached package-lock.json
git commit

Но после подобной манипуляции файл удалится у всех коллег которые подгрузят к себе этот коммит )) вы должны это понимать.

А хранить или нет в репозитории файл package-lock.json это уже другая история. Вопрос не так однозначен.

Если вы ещё не успели ничего закоммитить, то изменения просто лежат в рабочем каталоге и ещё не принадлежат никакой ветке. Достаточно просто переключиться в ветку Б. Если не возникнет конфликта, то продолжите работать как ни в чём не бывало.

Информация о репозитории не хранится в репозитории. В репозитории есть лишь коммиты с вашим кодом.
Информация о связях между репозиториями хранится в конфигах. Ничто не мешает её редактировать без изменения самого репозитория. Не очень понятна задача. Зачем вам перемещать код в другой репозиторий? Зачем избавляться от старых коммитов? Но если надо:

git clone старый_репо #скачать код
git reset $(git commit-tree HEAD^{tree} -m "Init") # очистить историю
git remote set-url origin новый_репо # подготовиться к отправке в новый внешний репо
git push -u origin main # отправить текущую ветку и связать ветки

Не можно, а нужно. Предположим что код у вас хранится в общем репозитории, который обозначен как origin. Первым делом не забудь забрать обновления на свой комп.
git fetch
Затем есть как минимум два способа применить обновление к своей ветке.
1. Влить обновлённый stage к себе
git merge origin/stage
2. Перебазировать свою тематическую ветку на актуальный stage
git rebase origin/stage

Файл .gitignore не поможет игнорировать изменения в уже отслеживаемом файле.
Но временно игнорировать изменения в файле можно командой:
git update-index --assume-unchanged <file>
Это защитит файл от случайной индексации и попадания правок в коммиты.
Git будет считать что файл не изменялся, значит сами эти нежелательные правки не попадут в коммиты и, следовательно, не улетят в общий репозиторий. Коллеги не узнают что что мы отредактировали файл у себя локально.

Твоя ошибка в неправильной последовательности команд. Команда heroku create создаёт пустой репозиторий на хостинге Heroku и добавляет ссылку на него в локальный репозиторий. Но локального репозитория на тот момент ещё не было! В итоге remote с именем heroku теперь отсутствует и команда push не знает, куда отправлять бота.

Сейчас тебе придётся вручную создать эту ссылку

git remote add heroku https://git.heroku.com/cryptic-cliffs-15444.git

Затем повторить отправку
git push -u heroku main

Поможет примерно такой pre-commit-хук:

#!/bin/sh
#
# An example hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#
# To enable this hook, rename this file to "pre-commit".

if git rev-parse --verify HEAD >/dev/null 2>&1
then
	against=HEAD
else
	# Initial commit: diff against an empty tree object
	against=$(git hash-object -t tree /dev/null)
fi

# Redirect output to stderr.
exec 1>&2

# полные пути от корня репо, разделенные символами новой строки
SECRET_FILES='secret.txt
dir/secret2.txt'

if git diff --cached --name-only $against |
   grep --quiet --line-regexp --fixed-strings "$SECRET_FILES"
then
  echo Попытка закоммитить запрещённые файлы
  exit 1
else
  exit 0
fi

# If there are whitespace errors, print the offending file names and fail.
exec git diff-index --check --cached $against --

Я взял шаблон в папке hooks и чуть подправил под себя (строки с русскими комментариями)

Пример работы:

❯ git add secret.txt
❯ git commit -m 'test hook'
Попытка закоммитить запрещённые файлы

После разрешения конфликта повторно индексируем отредактированные файлы через git addи завершаем слияние стандартной командой git merge --continue
Всё это есть в официальной инструкции.

Держите всё в одном репозитории. Для каждой версии 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 # отмени операцию удаления