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

На всякий случай напомню: мы пушим не в аккаунты, а в репозитории. Вы можете отправлять коммиты не только в проекты из своего аккаунта. Главное, чтобы у вас были права на запись — админ репозитория должен добавить вас в проект.

Поэтому само наличие второго аккаунта GitLab не всегда нужно. Хотя на работе могут выдать отдельный логин — и тогда появляются сложности.

Возможные варианты:

1. Работать только с рабочим аккаунтом, а в личных репозиториях просто дать ему доступ на запись.

2. Постоянно перелогиниваться, что неудобно: Git будет путаться в кэше аутентификации.

3. Разделить протоколы:
– личные проекты — через HTTPS,
– рабочие — через SSH.
Так Git не будет пересекать ключи и пароли.

4. Использовать трюк с виртуальными хостами (как написал Виктор).
Git всегда использует один SSH-ключ на один хост, но мы можем создать сколько угодно “виртуальных” хостов и привязать к каждому свой ключ. Git будет думать, что это разные GitLab-сервера.

Можно попробовать подойти к задаче через автоматическую генерацию миграций из базы, чтобы не переносить данные вручную в CSV и SQL.

Вот несколько подходов, которые могут помочь:

1. Liquibase diff
   
   Liquibase умеет сравнивать текущее состояние базы с эталонным snapshot или changelog (команды liquibase diff, generateChangeLog). Это может автоматически сгенерировать changesets. Не всегда идеально, особенно для данных, но может служить хорошей стартовой точкой.
   
   
2. Скрипт дампа и автоформатирования
   
   Написать утилиту, которая:
   
   • выгружает актуальные записи (по дате или через служебную метку),
     
   • форматирует результат построчно (для удобных диффов в Git),
     
   • сохраняет в SQL или CSV с нужным форматированием,
     
   • проверяет ошибки: зависимости, ключи, синтаксис и т. п.
     
   
   
3. Служебное поле change_id
   
   Добавление такого поля в ключевые таблицы упростит группировку и экспорт связанных изменений. Это также упростит отладку и проверку связей.
   
   
4. Проверки перед мержем
   
   Автоматический pre-merge скрипт может:
   
   • проверять, что ветка актуальна относительно master,
     
   • валидировать синтаксис SQL и CSV,
     
   • выявлять ошибки в зависимостях (foreign keys, отсутствие spec при наличии body и т. п.),
     
   • проверять потенциальные конфликты по ключам в changesets.
     
   
   
5. Dolt и Bytebase
   
   Как уже писали выше, эти проекты позволяют рассматривать базу как репозиторий Git. Подход интересный, но требует серьёзной перестройки процессов. Внедрение возможно, если проект активно развивается и готов к архитектурным изменениям.
   

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

Гуглить фразу failed to push (не удалось отправить) бесполезно. Это слишком абстрактное описание проблемы. Причины могут быть самые разные.

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

На данном этапе вам проще удалить репозиторий
rm -rf ".git"
И начать заново. Но не пихать в коммит что попало, git add . а индексировать только нужные файлы.

Если вы хотите аутентификацию по ключу, то вам нужен remote с URL для SSH-протокола, а у вас тут HTTPS-протокол, на который ваши SSH-ключи никак не влияют — там аутентификация своя — по паролю, либо токену.

Скорее всего вам надо поменять ссылку на правильную.

git remote set-url origin git@gitlab.com:malashko/bla-bla-bla.git

Merge Request — это запрос на слияние веток. Нет такого понятия, как «слияние коммитов». Сливаться будет вся цепочка коммитов, которая ответвилась от базовой ветки, а не только тот коммит, который существовал в ветке на момент создания запроса на слияние.

Чтобы создать три запроса, вам нужно раскидать эти коммиты по трем разным веткам.

Для каждого запроса на слияние создается отдельная ветка, потому что нельзя одну и ту же ветку слить дважды разными запросами. Хотите новый запрос — создавайте новую ветку. Ветка создается не откуда попало, а от главной ветки, в которую вы хотите вливаться.

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

git checkout master
git pull origin
git checkout branch-b
git merge master

Это всё можно заменить одной командой
git pull origin master

В этот момент процесс останавливается на моменте создания коммита слияния и вам нужно используя свой текстовый редактор разрешить все конфликты. Но гораздо эффективнее использовать инструменты разрешения конфликтов встроенные в графические Git-клиенты (рекомендую SmartGit либо IDE от JetBrains)

Далее завершаем слияние

git add .
git push origin

Тут вы забыли про git commit и указывать origin это лишнее, так как у вас ветка уже связана с вышестоящей. Но на самом деле достаточно всего одной команды для завершения

git merge --continue
git push # ну и отправить результат

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

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

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

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

Как обычно, у себя на компьютере подгружаете в свою ветку новые коммиты из целевой ветки 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

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