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

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

предлагает использовать либо одно, либо другое

Кто такое предлагает? Наоборот, в большинстве случаев хочется оставить и то и другое.

Как правильно решить этот конфликт?

Как обычно, у себя на компьютере подгружаете в свою ветку новые коммиты из целевой ветки common, которые там появились после того, как вы свою ветку feature создали. И в этот момент разрешаете конфликт локально, а вовсе не на гитлабе.

Вы неправильно понимаете суть веток. Это не «коробочки» с задачами, а указатели на дерево состояний проекта.

Перед запуском тестов вы должны подгрузить из main все обновленияк к себе: git merge main
Так вы заранее решите конфликты и их не будет когда уже вашу ветку будете вливать в main. И тесты будут прогоняться на актуальной кодовой базе, а не на устаревшей.

Скачиваются всегда все файлы, но вам нужно их ещё вытащить из репозитория в рабочий каталог. Если вы что-то ранее удалили в рабочей копии, то команда pull это не восстановит. Pull не предназначен для этого.
Сделайте git reset --hard чтобы очистить рабочий каталог от ваших незакоммиченных изменений/удалений и увидеть что на самом деле сейчас в ветке.

Чтобы сделать исключение для одного файла или папки, которые игнорируются в .gitignore, необходимо добавить путь к этому файлу или папке на новой строке в файл .gitignore с префиксом «!» (без кавычек). Например:

# .gitignore
/folder_to_ignore/
!/folder_to_ignore/important_file.txt

Если файл лежит внутри вложенного подкаталога, то придётся рисовать исключения для всей цепочки.

# игнорируем весь каталог
/folder_to_ignore/ 
# кроме его подкаталога
!/folder_to_ignore/subfolder 
# всё равно игнорируем содержимое подкаталога
/folder_to_ignore/subfolder/* 
# кроме одного файла
!/folder_to_ignore/subfolder/important_file.txt

Если такой файл лишь один, то можно не заморачиваться с правилами, а просто один раз индексировать файл принудительно. Тогда он начнёт отслеживаться.
git add --force "path/to/file.txt"

В гите ничего нельзя удалить.
Чтобы отменить какое-то действие, можно создать новый коммит, который делает противоположное изменение.
Либо просто передвинуть указатель ветки назад, на состояние до слияния.
Всё это делается на локальной копии репозитория и затем отправляется на GitLab.

Судя по документации, GitFlowPersistenceProvider не привязан к какому-то конкретному хостингу и позволяет отправлять реестр в любой внешний репозиторий.

Скрипт svn2git собирает Git-репозиторий локально, уже затем вы его отправляете в любой внешний репозиторий. Например, в GitLab.

Даже в инструкции просят устанавливать скрипт на ваш локальный компьютер, а не на сервер GitLab.

Install svn2git on a local workstation rather than the GitLab server

А вы зачем-то заходите в консоль гитлаба и там что-то делаете. Это ошибка, используйте свой компьютер.

В файл ORIG_HEAD перед началом операций записывается указатель на вершину текущей ветки. Видимо этот файл у вас испортился.
Удалите его вручную.

Нельзя. В веб-интерфейсе нет инструментов перебазирования или доступа к консоли.
Но вы можете легко откатить изменения к тому состоянию, которое осталось локально.
git push --force

Замените ваши четыре шага одной командой

git clone --depth=1 --branch=main <repo link> <site-dir>

— скачать только состояние на последний коммит ветки main.
Остальная история на хостинге не нужна.

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос поставлен слишком абстрактно. Толком не понятно что требуется сделать и с какой целью. Слишком много ситуаций можно придумать под эту формулировку.

Лучше почитайте базовые руководства, тогда поймёте как гит работает и перестанете задавать такие простые вопросы.
Начните отсюда https://githowto.com/ru
Потом потренируйтесь https://learngitbranching.js.org/?locale=ru_RU

А пошаговые инструкции тут не работают, ввод каких-то непонятных команд в терминале не поможет научиться работать и скорее только угробите проект.

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

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

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

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

Игнор действует только на те файлы, которые ещё не отслеживаются. Помогает СЛУЧАЙНО не добавить файл. Но лаже игнор не запрещает принудительно загнать файл в репозиторий.

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

Ещё есть трюк с временным игнорированием изменений в файле, ранее уже добавленном. Но он будет работать только в локальной копии репозитория и только после ввода команды
git update-index --assume-unchanged файл

Используйте GitHub CLI

# create a repository interactively
gh repo create

# create a new remote repository and clone it locally
gh repo create my-project --public --clone

# create a remote repository from the current directory
gh repo create my-project --private --source=. --remote=upstream

Или GitLab CLI

# create a repository under your account using the current directory name
$ glab repo create

# create a repository under a group using the current directory name
$ glab repo create --group glab-cli

# create a repository with a specific name
$ glab repo create my-project

# create a repository for a group
$ glab repo create glab-cli/my-project

А что мешает один локальный репозиторий синхронизировать с несколькими внешними?

git remote add server1 <URL>
git remote add server2 <URL>
git fetch server1
git merge server1\main
git push server1 <локальная_ветка>:<внешняя_ветка>

Как угодно можно обмениваться коммитами.

Файл .gitignore не поможет игнорировать изменения в уже отслеживаемом файле.
Но временно игнорировать изменения в файле можно командой:
git update-index --assume-unchanged <file>
Это защитит файл от случайной индексации и попадания правок в коммиты.
Git будет считать что файл не изменялся, значит сами эти нежелательные правки не попадут в коммиты и, следовательно, не улетят в общий репозиторий. Коллеги не узнают что что мы отредактировали файл у себя локально.

Вы путаете теплое с мягким. На первом скрине лог событий отправки ВЕТОК на сервер. Там не отображаются коммиты и авторы коммитов. На второй лог КОММИТОВ. Авторство коммитов не меняется во время Push и зависит только от того, кто их создал. Никаких противоречий в скрине нет. Авторство коммитов могло быть изменено любым из инструментов пересборки истории. Например amend или filter-repo.