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

Добавили большой файл, закоммитили, затем удалили этот файл и снова закоммитили

➜ git log  --oneline              
0aa4c37 (HEAD) Delete bigfile
65211de Add bigfile
591a997 Initial commit

Хотим склеить эти два коммита в один.
➜ git rebase -i HEAD~2
Откроется редактор со сценарием

pick 65211de Add bigfile
pick 0aa4c37 Delete bigfile

Меняем его на такой

pick 65211de Add bigfile
squash 0aa4c37 Delete bigfile

Сохраняем, выходим и получим.
Successfully rebased and updated refs/heads/main.
Теперь большого файла нет и он не помешает сделать push

Изменить нельзя, но можно пересоздать коммит, в том числе с новым сообщением.
Последний коммит ветки через git commit --amend
Более ранние через git rebase --interactive

1. Клонировать себе на комп git clone
   
2. Поменять автора коммитов используя git filter-repo
   
3. Отправить в новый пустой репозиторий git push -all <URL_нового_репо>
   

git filter-branch заявлен устаревшим и небезопасным

Если отменить изменения файла и закоммитить, то он исчезнет из PR
git restore <FILE> origin/target_branch

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

Но проще использовать ссылку https, чтобы не возиться с ключами.

git init # инициализировать репозиторий в папке тестового проекта
git remote add origin <URL> # указать адрес вышестоящего репозитория
git fetch # скачать вышестоящий репозиторий
git reset origin/master # установить указатель на ветку master
# существующие локальные файлы в рабочем каталоге измениться не должны
git branch --set-upstream-to=origin/master master 
# связать master с origin/master

Вы делаете почти правильно

git fetch origin
-- ошибок не выводит, но и результата никакого не даёт

Потому что вы ранее уже сделали pull, который включает в себя fetch
Если ничего не выводит, значит ошибок нет и изменений в origin тоже нет.

fatal: 'origin/master' does not appear to be a git repository

Гит говорит, что origin/master не является корректным адресом репозитория.
Правильный синтаксис: git pull origin master

И не называйте пожалуйста GitHub гитом.

Репозиторий нужно создавать ВНУТРИ каталога с проектом, а не в корне профиля пользователя.

вместо нормальной структуры папок в удаленном репозитории: proj/файлы проекта

Это вовсе не нормальная структура. Сама папка proj не должна отображаться в проекте.

Если

неверно ввел логин и пароль

Удалить ошибочную авторизацию можно командой

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

Написано же merged. Значит как все коммиты ветки зафиксированы в репозитории.
Переключись на нужный коммит и создай на нём ветку.

Если удалил ещё не слитую ветку, то восстанови через git reflog

Все операции делаются локально на рабочем компьютере.

Git Credential Manager запоминает авторизацию в профиле текущего пользователя.
На другом компьютере никто не сможет увидеть ваш приватный репозиторий.
Даже другой пользователь вашего компьютера не увидит секретов.

git init
# добавить в .gitirnore /config/db.php
git add . # загнать остальные файлы под отслеживание
git commit
git remote add origin https://github.com/..........
# на рабочем компьютере удалить db.php из репозитория
# и никогда больше добавлять такие вещи в репо
git pull origin master # влить изменения с компа
# на этом этапе скорее всего вылезут конфликты
# сможете их разрешить прямо на сервере?

Нужно не аккаунты переключать, а давать права на репозиторий. Зачем вам несколько аккаунтов? Достаточно одного.

Либо работать через SSH, тогда аккаунты не понадобятся в принципе.

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

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

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

Используйте 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

Грубо говоря на компе [папка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 не используются никакие аккаунты. Сами коммиты подписываются именем и мылом прописанным в конфиге командами

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

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

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

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

# Если хочешь внести изменения во внешний репозиторий, то просто клонируй его к себе
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

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

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

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

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