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

Вы просите какую-то дичь ))
В гите каждая ветка хранит состояние всего проекта, т. е. все файлы. И при 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 для измененного файла нужно было создавать не от актуального мастера, а от того состояния, в котором этот файл был отдан на сторону. Иначе полученный коммит отменит всю работу, которую вы сделали сами. Разве это не очевидно?

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

git reset --hard # отменить все изменения отслеживаемых файлов
git clean -d -f # удалить новые, но не индексированные файлы

Просто добавьте файл в коммит принудительно через
git add -f
Гитигнор не запрещает коммитить, он лишь защищает от автоматического индексирования.

git clone <url-репозитория-шаблона> .
git remote set-url origin <url-нового-репозитория>
git push -u origin --all # отправить все ветки в новое место

Проще принудительно добавить этот файл в отслеживаемые, чтобы не заморачиваться с игнорированием
git add -f “admin/controller/module/test.php”

Иначе придётся создавать сложную цепочку игноров и инверсий

admin/*
!admin/controller
admin/controller/*
!admin/controller/module
admin/controller/module/*
!admin/controller/module/test.php

Для отладки можно использовать команду

git check-ignore **/* # показать все проигнорированные файлы
admin/controller/level2.txt
admin/controller/module/level3.txt
admin/controller/module/test2.php
admin/level1.txt

git check-ignore -v **/*  # показать какие правила сработали
.gitignore:2:!admin/controller	admin/controller
.gitignore:3:admin/controller/*	admin/controller/level2.txt
.gitignore:4:!admin/controller/module	admin/controller/module
.gitignore:5:admin/controller/module/*	admin/controller/module/level3.txt
.gitignore:6:!admin/controller/module/test.php	admin/controller/module/test.php
.gitignore:5:admin/controller/module/*	admin/controller/module/test2.php
.gitignore:1:admin/*	admin/level1.txt

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

И чтобы изменения кода показывал не в двухоконном режиме, а в одной области (красным - удалённые, зелёным - добавленные)

Для этого и клиент не нужен, в консоли так показывает. Разве это удобно?

А вообще SmartGit однозначно лучший и денег не просит.
И не стесняйся использовать возможности твоей IDE. Автономные клиенты не понимают синтаксиса языка более корректного разрешения конфликтов.