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

Откройте настройки и введите в поиск Editor: Format On Save
Там либо отключите форматирование при сохранении, либо настройте его, чтобы форматировался не весь файл а только изменённые строки.


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

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

Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.

создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)

Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель develop в распакованной (checkout) в рабочий каталог ветке.

Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?

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

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

Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (merge) с основной веткой (develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.

Способов собственно два:

1) Мы забираем новое состояние develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную develop, обновлять её (pull) а затем возвращаться к себе чтобы сделать git merge develop. Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте git merge origin/develop. Указатель origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (fetch). В принципе эти два шага эквивалентны одной команде git pull origin develop — внутри делается всё то же самое.

2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально git fetch, затем собственно пересадим ветку на актуальное состояние git rebase develop. Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через git push --force. Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.

Если вы не коммитите напрямую в master и в develop, то держать их у себя локально (делать checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются origin/master или origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.

Тоже думаю что у вас какой-то странный workflow.

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

Чтобы видеть все изменения не нужно ничего сквошить.
Исправления должен делать сам разработчик, зачем вы делаете это за него?
Черипикать тоже непонятно зачем.

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

Это тоже забота разработчика. Пусть перед отправкой своей работы на рецензию делает git merge develop и устраняет конфликты сам заранее.

неудобно, что ревью приходится проводить в GitLab.

Что мешает поставить плагин и работать там где удобно?

При пуше, Git пытается авторизоваться с помощью Git Credential Manager Core, который как раз написан с использованием .NET Framework. В первых версиях десятки был встроен .NET Framework 4.6, но это было много лет назад. Если не отключены обновления, то .NET у вас должен быть актуальным 4.8.
Скорее всего вы «забыли» установить обновления.

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

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

# Клонируем репо в две папки рядом с каталогом 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

Нельзя удалять всё содержимое этих папок, и также не стоит удалять подкаталоги вручную.
Используйте специально предназначенные для этого инструменты.
Удаление старых профилей пользователей Windows с помощью GPO или PowerShell

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

Устанавливается просто
sudo apt install open-vm-tools
Установка через менеджер пакетов позволит ещё и обновлять автоматически.
А монтировать CD и вручную запускать установщик оттуда нет никакого смысла.

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

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

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

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 например покажет новые коммиты.