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

Git заточен на работу в локальной файловой системе.
Вам религия не позволяет нормально клонировать репозиторий к себе?

старый мастер назвать old-master и текущую ветку, переименовать в master

git branch -M master old-master # переимоновать старый мастер
git branch -M master # переименовать текущую ветку в master

Но зачем всё это? old-master будет по-прежнему связан с origin\master.
Если хочется обновить и эти связи, то используется push

git push --set-upstream origin old-master # перенаправить на новую ветку
git push -u --force origin master # пересоздать внешний master

Если origin и VPS это разные места, то VPS не увидит этих ваших переименований.
Там тоже придётся связи перенастраивать.
Например через git pull --rebase на VPS и на компьютерах всех коллег, если вы работаете в команде.

Снова повторю вопрос: зачем вам эти сложности?

git remote rename - но это для переименования удаленных веток (как я понял)

Нет, это для переименования remotes — ссылок на внешние репо.

Вы смешали тёплое с мягким. Внутри папок ветки, а внутри веток снова папки.
Что вообще имелось в виду?

На всякий случай попробуйте клонировать оптом вместе с подмодулями.
git clone --recurse-submodules <GitLab>

Шестой пункт выполняйте первым, а первый и второй вообще не делайте, они не нужны.
Тогда всё заработает.

git remote set-url origin <адрес форка>
Либо ещё лучше так

git remote rename origin upstream
git remote add origin <адрес форка>

Чтобы иметь возможнось подгружать к себе обновления основного репозитория
git fetch upstream

Всё это можно сделать через меню IntelliJ IDEA
Поищите пункт Manage Remotes…

Нет, не на main, а из main.

Команда git push -u origin main делает отправку локальной ветки main во внешний репозиторий origin, но ветки main не существует локально, о чем вам и сообщили в ошибке.

Вам нужно либо переименовать master в main:
git branch -M main

Либо так и написать, что вы хотите master отправить во внешний main
git push -u origin master:main

Но судя по скрину, у вас репозиторий не пустой. Вы уже создали там ветку с первоначальным коммитом. Поэтому вы не сможете просто так туда сделать push, так как ваши ветки не имеют общей истории. Это РАЗНЫЕ деревья. В таких случаях можно просто пересадить локальную ветку на вершину внешней через rebase. Либо создать ПУСТОЙ репо, как вы и сделали.

Откройте настройки и введите в поиск 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

Репозиторий уже содержит ВСЕ версии проекта. Не совсем понятно что именно вам нужно.
Если хочется актуальный 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