Дмитрий

Нужно просто переключиться на hash history.

import { createRouter, createWebHashHistory } from 'vue-router'

const router = createRouter({
  history: createWebHashHistory(),  // <---
})

Отвечаю сам:
Вау! Вот это крутотень! Не нужны никакие виртуальные экраны!
Xephyr - наше все!
Xephyr позволяет создать вложенную новую X-сессию внутри текущей. Внутри вложенной X-сессии можно запустить windows manager и делать вообще все что хочешь, а можно просто запустить нужное приложение и получаем именно то что требовалось.
Причем во многих дистрибутивах он уже стоит по-умолчанию.
Делаем так:

$ Xephyr -screen 800x600 :1 &
$ DISPLAY=:1 wps &

Вместо wps (офис) ставьте любое приложение, которое вам нужно. Понятно что без WM хотя запустить несколько приложений и можно, но переключаться между ними не получится. Но для одного приложения работает идеально.

1. Вам нужно установить git на хостинге, чтобы делать push локально и затем pull на сервере для переноса сделанных изменений. Если хостинг не позволяет установить git, то можете воспользоваться плагином git-ftp (переносит измененные файлы по ftp)
2. Делать копию базы можно, но с какого-то момента это становится слишком затратно, да и нужную вам комбинацию данных придется искать. Решается это наполнением базы тестовыми данными (ищите seed в поиске). Развивая проект вы дополняете и сидеры. Это позволяет держать базу в атуальном виде, а также (!) откатываться к предыдущим версиям и там генерировать базу для именно этой версии. Кроме того сидеры позволяют легко экспериментировать, т.к. пересоздание базы занимаетс секунды.
3. Для изменения структуры базы данных применяются миграции (migration). Это описание того, какие поля, таблицы, индексы добавляются/удаляются, а также трансформирование данных. Создав миграцию локально и протестировав на локальных данных вы переносите ее с помощью git на сервер также, как и весь остальной код. Остается только запустить миграцию на сервере и ваша БД будет трансформирована как вы указали.

Конечно, многое зависит от того, каким фреймворком вы пользуетесь. Подавляющее большинство позволяют создавать и сидеры, и миграции.
Чтобы было проще представить, вот ссылка на документацию Laravel по этой теме: https://laravel.com/docs/8.x/migrations

Странно что вам в master еще не прилетела какая-нибудь недоделанная фича... ;)

Давайте ответим на вопрос: Для чего вам нужен dev? На самом деле не для разработки, как вы думаете, а для тестирования фич. Правильно?
В связи с этим ваша проблема решается следующими шагами:
1. Переименовать dev в stage (test и т.п.) и забыть что там ведется разработка.
2. Все фича-ветки должны создаваться от master.
3. После завершения фичи она мержится в stage и проверяется. Можно даже без PR, т.к. теперь никакой хлам принципиально не может попасть в master.
4. Если все в порядке, из фича-ветки делаете PR в master.
5. stage можно иногда просто сносить и пересоздавать с головы master, чтобы история была красивее. ;)

PS: Это какая-то мания у команд - иметь ветку dev... "Мы же разработкой занимаемся - у нас должна быть ветка dev!". Так что ли?
Не всякому проекту нужна ветка dev! Точнее так - если у вас есть ветка dev, то у вас должна быть и ветка release и вы должны обновлять приложение большими релизами с определенной подготовкой к ним.

git reset --hard <последний перед удаляемыми коммит>
git push -f