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

1. Сделанный push отменяется только повторным push с противоположными изменениями в коммитах.
2. Сам push никак не меняет локальные файлы.

При коммите в Git не используются никакие аккаунты. Сами коммиты подписываются именем и мылом прописанным в конфиге командами

git config --global user.name "Имя Фамилия"
git config --global user.email user@mail.com

Представиться можно как заблагорассудится, тут нет проверок и авторизаций.
Бывает что эти данные прописаны в нескольких местах, тогда можно вывести все параметры командой
git config --list --show-origin
И увидеть в каком файле лишнее.

Аккаунт гитхаба используется только при отправке данных туда. Тут надо уже смотреть как ты авторизовывался и сбрасывать сессию.

В 2022 году рекомендованным методом является использование пакета filter-repo

git filter-repo --mailmap my-mailmap

Где файл my-mailmap должен содержать строки вида
Correct Name <correct@email.com> <old@email.com>

git remote add front <url> # придумать псевдоним внешнего репозитория
git fetch front # скачать «пустой» репозиторий к себе
git rebase front/dev # пересадить готовый проект поверх существующей «пустой» ветки
git push front HEAD:dev # отправить проект

Зачем создавать новый репозиторий? Не надо изобретать сложные решения.

# Если хочешь внести изменения во внешний репозиторий, то просто клонируй его к себе
git clone https://github.com/github-name/test.git
# Войди в рабочий каталог
cd test
# Переключись в нужную ветку
git switch additional
# Измени файл и закоммить его 
git add "index.html"
git commit -m "add new sections"
# Отправь на GitHub
git push

git reset --soft HEAD^1 # откатываем локальную ветку, но не трогаем рабочую копию кода
git push --force origin HEAD # заменяем ветку во внешнем репозитории

Но этот рецепт применим только если это личная ветка и коллеги её ещё не успели использовать.

Правильней будет отменять правки а не «удалять» коммиты

git revert HEAD # отменяем предыдущую правку
git push # отправляем во внешний репо
git revert --no-commit HEAD # отменяем отмену, но не коммитим сразу
# дальше оформляем уже правильный коммит, без ненужных файлов.

Спасибо Lynn «Кофеман» за элегантное решение

git reset --soft master # начнём ветку заново от текущего мастера
# но все уже сделанные правки не пропадут, а останутся в индексе
git commit -m 'Это один коммит' # зафиксируем работу

git reset --hard
Чтобы код в рабочем каталоге актуализировать с тем, что в репозитории.

Ключевое слово 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 это уже другая история. Вопрос не так однозначен.

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

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

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'
Попытка закоммитить запрещённые файлы