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

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

Задача решается легко

# Клонируем репо в две папки рядом с каталогом project
git clone --no-local . "../new_front" # тут будет фронт
git clone --no-local . "../new_back" # тут будет бэкенд
cd ../new_back # перейдем в новый бэкенд 
# Вычистим каталог front из истории бэкенда
git filter-repo --path "front/" --invert-paths 
cd ../new_front # перейдем в новый фронт
# Оставим в проекте фронта только содержимое подкаталога front, 
# сделав его новым корнем проекта
git filter-repo --subdirectory-filter "front/"

Пакет git-filter-repo возможно придётся установить. Он не входит в базовое ядро Git.

как клонировать репозиторий с github

Репозиторий уже содержит ВСЕ версии проекта. Не совсем понятно что именно вам нужно.
Если хочется актуальный main откатить на 5 коммитов назад, то клонируйте форк к себе на компьютер, затем откатите нужную ветку назад через git reset --hard HEAD~5 и отправьте обратно git push --force

Могу их изменять/удалять/редактировать

Вы создаёте коммиты прямо в веб-интерфейсе гитлаба? Лучше конечно забрать репозиторий к себе на рабочий компьютер и работать с файлами локально.

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

git pull заберет изменения с гитлаба и применит их к рабочему каталогу.

Если нужно чтобы гитлаб сам автоматически публиковал изменения на сервер, то изучайте GitLab CI/CD. При этом разработку в любом случае желательно вести на рабочем компьютере, а не править файлы сразу на гитлабе.

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

git fetch # скачать обновления с origin
git checkout -b new_branch origin/master # создать новую ветку от состояния origin/master

Перед тем как отправлять отдавать свою работу на рецензию и вливание в мастер, причёсывайте коммиты через git rebase --interactive

Git заподозрил что вы не совсем в здравом уме. Он не понимает, зачем вы написали эту команду после того как индексировали файл для будущего коммита, но ещё не зафиксировали его. И теперь гит просит уточнить, что именно вы хотите сделать. Либо вы передумали только коммитить его и хотите лишь удалить файл из индекса, либо собираетесь удалить файл совсем.

Вы просите какую-то дичь ))
В гите каждая ветка хранит состояние всего проекта, т. е. все файлы. И при fetch/push передаётся состояние проекта целиком, а не отдельные файлы. Что вы имеете в виду под фразой «только измененные файлы заливались»? Что должно произойти? Чтобы не видеть другие файлы в ветке, их придётся удалить, а это тоже изменение.

Вам это не нужно. Создав Merge Request вы в нем и так увидите только изменения.

Git это линуксовый пакет программ, состоящий из множества утилит работающих в текстовом терминале. Когда портировали Git в Windows, пришлось портировать и часть окружения Linux, в том числе и интерпретатор командной строки bash. Git хоть и может выполняться в стандартной командной строке Windows или в Power Shell, но родным для него является bash и лучше работать в нём. Так как это не полноценный bash из линукса, а лишь его виндовая адаптация для Git, то его и назвали Git bash.

Сам WebStorm терминалом не управляет, он лишь его отображает внутри своего окна.
Отображением ветки занимаются всевозможные плагины к терминалу.
На маке горячо рекомендую поставить Fig.io
brew install fig
Эта штука добавляет в терминал множество удобных фич, в том числе работу с Git через плагин Spaceship Prompt


Терминал желательно переключить на шрифт jetbrains-mono-nerd, чтобы показывало пиктограммы.
brew install font-jetbrains-mono-nerd-font

Если вы редактируете файл, а гит это не видит, значит файла нет в репозитории и он подпадает под правила игнорирования. Скорее всего игнорируется вся папка bitrix/

Если вы хотите начать отслеживать отдельный файл из этой папки, то просто сообщите гиту об этом:
git add --force "bitrix/файл"

Если же нужно вывести из игнорирования какой-то подкаталог, то поправьте .gitignore

bitrix/
!bitrix/подкаталог/

И git status сразу увидит содержимое подкаталога в неотслеживаемых.

Если нужно перестать игнорировать подкаталог с бо́льшим уровнем вложенности, то правила будут посложнее.

Я не силён в битриксе, но мне кажется редактировать файлы ядра там не принято и вы что-то делаете не так.

Игнор корректный, почему вы решили что он не работает?
Покажите git status
И
git check-ignore **/*

В первоначальном репозитории переключитесь на другую ветку, иначе передача выдаст ошибку. Затем смело делайте push.
Но более безопасным способом будет просто забрать изменения напрямую через pull.
Удобнее будет если предварительно расскажете первоначальному репозиторию что у него есть клон, через git remote add и свяжете ветки git branch -u

как узнать в базовом проекте что мне кто то прислал новые комиты?

Как обычно. git log например покажет новые коммиты.

Удалённо изменить внешний репозиторий не получится. Нужно его принять к себе, поработать и отправить обратно

git pull --rebase # скачать изменённую историю
git reset --hard HEAD~2 # откатить на два коммита
git push --force # снова изменить историю

либо

git fetch
git switch master
git reset --hard origin/master~2
git push --force

Коллегам придётся обновиться тоже через —rebase

Самый надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

# клонируем репозиторий в соседний каталог
# иначе придётся использовать ключ --force
git clone --no-local . ../clonerepo/
# переходим в свежий клон
cd ../clonerepo
# чистим
git filter-repo --path "path/to/file" --invert-paths
# проверим что файл исчез
git log --all --oneline --name-status -- "path/to/file"

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

➜ 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 rm, он просто делает сразу два действия

rm file.txt
git add file.txt

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

git rm --cached file.txt
git commit

Какой смысл вы вкладываете в термин «узел Git-репозитория»?

огромный архив картинок улетел в репозиторий github. и хотя мы их удалили

Удалять следовало не картинки, а коммиты добавившие эти картинки.

Почистить историю репозитория от мусора можно командой filter-repo

Конфиг гита размазан по многим текстовым файлам.

• Есть системный файл в папке гита.
  
• Есть настройки хранящиеся в домашнем каталоге каждого пользователя компьютера.
  
• Также каждый репозиторий имеет свои собственные настройки.
  

Вот эта команда покажет где лежат файлы.
git config --list --show-origin

Ветку order для измененного файла нужно было создавать не от актуального мастера, а от того состояния, в котором этот файл был отдан на сторону. Иначе полученный коммит отменит всю работу, которую вы сделали сами. Разве это не очевидно?