У bitbucket есть такая штука как deploy keys - это SSH-ключи, которые дают доступ к репозиторию только на чтение. Кладете открытую часть в битбакет, приватную - на сервер. И сервер получает возможность забирать (клонировать и пуллить) репозиторий из бакета (но не пушить туда)
Я бы сделал так: для каждого проекта свой репозиторий.
В репозитории главного проекта - основной код. Он собирается в библиотеку и публикует её в какое-то хранилище (nexus или аналогичный репозиторий)
В репозитория "дочерних" проектов - эта библиотека подключается как зависимость плюс код, отвечающий за конкретную специфику этого дочернего проекта.
Таким образом достигается максимальная гибкость - дочерние проекты могут опираться на любую версию библиотеки (какая им требуется) плюс могут добавлять свой собственный код (свою логику).
Он не удалился. Прочитайте Git Book, чтобы понимать что делает каждая команда
Вы сдвинули указатель HEAD на конкретный коммит. Теперь сделайте git checkout master (если основная ветка master, что скорее всего) и наблюдайте оба коммита.
А зачем вам гит на vps? Должен быть какой-то один "источник правды".
Мне кажется что история должна быть такой: git server (github/gitlab/etc) -> local repository -> rsync to vps -> volume to docker
Соответственно, когда вы меняете ветку в локальном репозитории - rsync видит изменения файлов и синхронизирует их с vps, который ничего про гит не знает - для него это просто набор файлов.