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

Посмотреть в каких коммитах был добавлен или удалён конкретный файл.
git log --oneline --name-status -- '*ignored.txt'

Невозможно "пушить коммиты"! Пушится только целиком вся локальная ветка в какую-то конкретную внешнюю ветку.

Вашу проблему видно тут

Оказывается, последние коммиты вылетели из ветки master, т.е. вот что пишут логи Version Control:
для первого коммита - In 3 branches: HEAD, master, origin/master
для большинства коммитов проекта - In 2 branches: HEAD, master
для последних - In 1 branch: HEAD.

Вы видимо ВЫШЛИ из текущей ветки и сделали checkout на произвольном коммите. Это называется состояние detached HEAD, т. е. когда на коммит указывает только HEAD. Если в таком состоянии начать создавать коммиты, то получится НОВАЯ цепочка коммитов, которая не принадлежит никакой именованной ветке. Так вы и сделали, судя по тому, что ваша IDE говорит что эти коммиты видны только в HEAD.

Как это исправить? Ответ зависит от того, что вы хотели добиться, переключившись на старое состояние проекта. Если нужно было просто отбросить более свежие правки, то надо было изначально делать reset, а не checkout. А сейчас просто сделайте так, чтобы ваша ветка указывала на текущий коммит.
Пересоздайте её локально и во внешнем репозитории.

git branch -f master
git push -f

либо в терминале git reset HEAD
Файлы не изменятся, но отменится их индексация, т. е. сделается unstage

Либо просто нажать кнопочку отмены — Rollback

Не пытайтесь как-то удалить или переименовать Git от Apple. Он защищён системой.
Правильный путь это проверить переменную PATH, чтобы папка с нашим гитом была раньше чем системная. Сами системные пути хранятся в файле /etc/paths
Легче поправить первоисточник, чем копаться в профиле bash, который может и не используется даже. В macOS давно zsh в качестве оболочки.

Итак, запустите любимый редактор от имени root и откройте файл.
Например так sudo nano /etc/path
В Monterey он выглядит так

/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

Homebrew добавляет ссылку на Git в папку /usr/local/bin поэтому сразу работает нормальный Git. В Catalina приходилось редактировать порядок каталогов.

Если вы хотите вернуть файлы в то состояние, в котором они были в момент последней индексации, то выполните вот такую команду
git restore :/

Фраза You are on a branch yet to be born означает буквально то, что репозиторий совершенно пустой. Вы не сделали ещё ни одного коммита и нет ни одной ветки, поэтому команда checkout бессмысленна. Надо было после индексации git add . сразу всё и закоммитить первым делом.

git rebase --onto main $(git merge-base develop ficha) ficha

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

Правильней будет перед перемещением папки .git воспользоваться командой filter-repo, чтобы пересобрать заново все предыдущие коммиты так, как будто репозиторий изначально лежал в на два уровня выше.

Исходная структура папок

mysite
└── application
    ├── backend
    └── frontend
        └── .git

Подготовим старый репозиторий к перемещению

git filter-repo --to-subdirectory-filter application/frontend

Получим такую структуру

mysite
└── application
    ├── backend
    └── frontend
        ├── .git
        └── application
            └── frontend

Затем перенесём всё содержимое папки frontend в корень сайта.
И никаких дополнительных коммитов не понадобилось. Разве что останется только добавить в репозиторий остальной сайт.

Способов много

git checkout .
git restore .
git reset --hard

даже git stash даст желаемое как побочный эффект

Но все эти команды откатят только измененные файлы. Новые файлы не тронут.
Для чистки от добавленных файлов используют git clean -d -f

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

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

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

Отменить pull можно так
git reset --merge ORIG_HEAD
Это делается сразу после pull

а можно ли сделать так, чтобы при git clone папка /vendor на локалку сливалась, после чего убедить git перестать ее отслеживать?

Можно. Разрешаю ))
после клонирования удали папку из репозитория

git rm -r --cached -- 'vendor/*'
git commit

Если папка упомянута в gitignore, то перестанет отслеживаться в рабочем каталоге.
Но удалится в origin/

Посмотреть все коммиты, где удалялись файлы

git log --name-status --graph --oneline --diff-filter=D --branches

Затем восстановить нужные файлы командами вида
git restore <SHA>^ -- <полное имя файла>

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

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

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-протокол. Это немного сложнее, но как вариант сгодится.