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

Большой файл видимо был добавлен в один из новых, ещё не запушенных коммитов. И затем был удалён, но остался в истории. Неважно, что сейчас в рабочем каталоге. Пушится не рабочий каталог, а ветки репозитория. Это разные сущности.

Просто склейте новые коммиты в один, это решит проблему.

git reset --soft github/master
git commit -с
git push github -all

# 1 -> 2
git rebase --onto master tmp1~2 tmp1 # пересадить два коммита ветки tmp1
git rebase --onto master tmp2~3 tmp2 # пересадить три коммита ветки tmp2
git reset HEAD~1 # обрезать ветку tmp2 на один коммит

# 1 -> 3
git rebase --onto master tmp1~3 tmp1# пересадить три коммита ветки tmp1
git switch master # вернуться в мастер
git reset tmp1~2 # и подвинуть его на шаг вперёд
git rebase --onto master tmp2~3 tmp2 # пересадить три коммита ветки tmp2

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

Игнор действует только на те файлы, которые ещё не отслеживаются. Помогает СЛУЧАЙНО не добавить файл. Но лаже игнор не запрещает принудительно загнать файл в репозиторий.

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

Ещё есть трюк с временным игнорированием изменений в файле, ранее уже добавленном. Но он будет работать только в локальной копии репозитория и только после ввода команды
git update-index --assume-unchanged файл

Потому что склеиваются только смежные коммиты.

Это называется mergetool.
Во нормальных GUI-клиентах инструмент слияния встроен и здорово помогает разруливать конфликты. SmartGit рекомедую, он под все операционки есть.

Решение в одну строку

# удостовериться что мы в нужной ветке
git checkout branch2 
# создать коммит с нужным состоянием 
git merge --ff $(git commit-tree -p branch2  -m "Magic commit" branch1^{tree})

Удалить предыдущую авторизацию

echo "url=https://github.com" | git credential reject

И при повторном пуше войти под другим пользователем.

Либо перейти на ssh-протокол. Это немного сложнее, но как вариант сгодится.

Используйте GitHub CLI

# create a repository interactively
gh repo create

# create a new remote repository and clone it locally
gh repo create my-project --public --clone

# create a remote repository from the current directory
gh repo create my-project --private --source=. --remote=upstream

Или GitLab CLI

# create a repository under your account using the current directory name
$ glab repo create

# create a repository under a group using the current directory name
$ glab repo create --group glab-cli

# create a repository with a specific name
$ glab repo create my-project

# create a repository for a group
$ glab repo create glab-cli/my-project

Скачивайте так же, как и любой другой файл по ссылке для скачивания на сайте.
URL вида

https://gitlab.com/"профиль"/"репозиторий"/-/raw/"ветка"/"полное имя файла"

Грубо говоря на компе [папка1], а в репе лежит [папка1, папка2]

Такого не может быть. Если вы не видите в рабочем каталоге папку, а она точно есть в ветке, значит в каталоге распакована другая ветка, либо каталог «не чист», т. е. содержит незакоммиченные правки.

Если репозиторий частный, то проще удалить глючный коммит.

git reset --hard HEAD^
git push --force

и сделать нормально новый

Вопрос «от какой ветки» бессмысленен в Git, потому что ветки создаются только от какого-то коммита.
И тут нет такого маразма, как в Mercurial, что каждый коммит намертво привязан к какой-то ветке.
Вот типичная ситуация:

A - B - C - - - - J     [master]
     \
      D - E - F - G     [branch-A]
           \
            H - - I     [branch-B]

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

Например так

diff -u <(git rev-list --first-parent child_branch) <(git rev-list --first-parent parent_branch) | sed -ne 's/^ //p' | head -1

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 никак не меняет локальные файлы.