Построение логики работы GIT-системы

У нас в команде 2 человека, которые работают над достаточно большой системой.
вот тут я набросал список команд по настройке GIT-системы.

Идея следующая:
1. Каждый из разработчиков настраивает локальную копию сайта у себя.
2. Настраиваем центральный (удалённый) репозиторий (с которым будем синхронизироваться)
3. На продакшене так же поднимаем репозиторий (сюда будет вливаться стабильный код)

Глобальное назначение веток:
1. master — тут содержится только стабильный и оттестированный код, который в любой момент можно выложить на продакшн.
2. Разработка ведется в ветках с названиями dev<номер версии>, например, dev0.8, dev0.11, версии — набор задач, который объединяется в версию. Когда цель достигнута — версия тестируется, сливается с мастером и выкладывается на продашкн.

Я смоделировал всё это на локальном компьютере и всё отлично заработало. Только вот начальник у меня не человек принципиальный, и по непонятным для меня причинам, категорически отказывается поднимать локальную копию сайта.
Если вариант для него сделать отдельную удалённую площадку с копией сайта и поднять там GIT по принципу такому же как и если бы это была локальная копия сайта.

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

P.S. Ещё такой вопрос: удалённый репозиторий, с которым будут синхронизироваться разработчики обязательно должен быть bare или нет?
  • Вопрос задан
  • 3698 просмотров
Пригласить эксперта
Ответы на вопрос 1
klen
@klen
Вы изобретаете Git Flow.

Статья на хабре: habrahabr.ru/post/147260/
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
22 нояб. 2024, в 19:51
15000 руб./за проект
22 нояб. 2024, в 19:15
200000 руб./за проект
22 нояб. 2024, в 18:50
30000 руб./за проект