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

git pull разве должна что-то откатывать?
Чтобы вернуться к старому состоянию, не нужно ничего скачивать. Git хранит всю историю локально.
Если не нужна работа проделанная после последней отправки, то достаточно переместить указатель ветки на тот момент
git reset --hard example/ветка
Если коммитов после вчера ещё не было, отменить изменения файлов ещё проще. Способов много.

git reset --hard
git checkout '*'
git restore '*'

Это отменит только изменения уже закоммиченных ранее файлов. Новые файлы можно удалить через
git clean -d -f

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

git remote add server1 <URL>
git remote add server2 <URL>
git fetch server1
git merge server1\main
git push server1 <локальная_ветка>:<внешняя_ветка>

Как угодно можно обмениваться коммитами.

Я думаю это можно реализовать с помощью команды sparse-checkout
Все проекты храним в одном большом монорепозитории и распаковываем разные наборы каталогов для разных ситуаций.

Нельзя запушить какие то беспризорные коммиты, пушат ветки. В состоянии оторванной HEAD нет никакой ветки. Тебе нужно заново создать свою ветку, чтобы она указывала на текущее состояние проекта
git branch -f feature_branch
Ключ force нужен, так как ветка уже существует и мы её пересоздаём в новом месте.

Но если я создам новую ветку не запушенный коммит пропадет.

Странное заявление. При создании ветки от текущего коммита, он автоматически окажется в новой ветке тоже. С чего это он должен куда-то пропасть?

git branch feature_branch # создать новую ветку для текущего коммита
git reset origin/master # удалить коммит, он останется только в новой ветке

одной командой сказать, что бы запушил коммит не в мастер а в другую ветку, не переходя на нее

И так тоже можно
git push origin HEAD:feature_branch
Но из локального мастера всё равно не забудь удалить лишнее.

В книге ProGit есть описание одного интересного приёма, который возможно уместен в данной ситуации. Он позволяет спрятать начало истории и оставить только свежие коммиты, не прибегая к rebase.

Например, допустим в вашем проекте огромная история изменений и вы хотите разбить ваш репозиторий на два — один с короткой историей для новых разработчиков, а другой с более длинной историей для людей, интересующихся анализом истории. Вы можете пересадить одну историю на другую, 'заменяя' самый первый коммит в короткой истории последним коммитом в длинной истории. Это удобно, так как вам не придётся по-настоящему изменять каждый коммит в новой истории, как это вам бы потребовалось делать в случае обычного объединения историй (так как родословная коммитов влияет на SHA-1).

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

Всё у тебя переключилось. Ты перешел в нужное состояние (HEAD is now at...), но на него не указывает ни одна ветка (состояние detached HEAD)

Локальную ветку надо дополнительно создать.
Ведь ветка это лишь именованый указатель на состояние проекта.

Либо сейчас создай ветку в текущем состоянии.
git branch feature/acproject-access-control

Либо повтори правильно переключение:
git checkout -b feature/acproject-access-control origin/feature/acproject-access-control
хотя наверное и короткая команда сработает:
git checkout feature/acproject-access-control

Untracked — неотслеживаемый файл, Git им не управляет. Он может быть не только новым, но и очень старым.
Changes not staged — файл под управлением Git и был изменён в рабочем каталоге.

Разница существенная. Например состояние этих групп файлов сбрасываются разными командами. Команда reset или checkout работает только с отслеживаемыми файлами, а например удалить неотслеживаемые можно только через clean

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

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