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

Ключевое слово hook declined
Сработал хук pre-receive на стороне сервера. Ищите ошибку у себя в коде.
Хуки на то и придуманы, чтобы срабатывать ИНОГДА, при определённых условиях.
Так что не надо говорить что всегда работало, а сейчас не хочет.
Желательно чтобы хук ещё и выводил в консоль причину отказа.

Назначить (assign) можно любого пользователя, у которого есть права на запись в репозиторий, либо того, кто прокомментировал PR. Сначала добавьте соавторов (collaborators) в репозиторий и раздайте им права. Потом сможете прикреплять к ним PR.

Работай в Git-bash, там эта команда сработает. Либо погугли как в PowerShell файлы создают.

Вы явно делаете что-то не так, раз репо занимает столько места. Уточните, что вы там храните?
Стандартные процедуры сборки мусора и перепаковки не сильно помогут. Надо удалить лишнее руками.
Либо тупо обрезать старую историю и использовать текущее состояние проекта как начало новой истории.

git reset $(git commit-tree HEAD^{tree} -m "Новое начало истории")

Затем сделать сборку мусора
git gc --prune=now --aggressive

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

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

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

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

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

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

Скопировать ошибочные коммиты из ветки B в ветку A:

git rebase --onto A origin/B B

Тут три параметра.
A — ветка, куда переносим.
origin/B — ссылка на старое состояние, до ошибочных правок
B — ветка, откуда переносим.

Затем откатить ветку B:

git switch B
git reset origin/B

Предполагается, что вы ещё не успели отправить испорченную ветку B в вышестоящий origin.
В противном случае вместо origin/B придётся подставить корректный SHA последнего «хорошего» коммита.

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

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

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.