@Mozzart-live

Как правильно работать с GIT?

Добрый день.

Давно знаком с системами управления версиями, но применять на практике решился только сейчас - появился проект на постоянку. В связи с этим возникли типичные, для новичка вопросы (при возможности, ссылайтесь на функционал работы с git в ide netbeans):
1. Есть тестовый сайт test.site.ru и продуктив site.ru, как правильно организовать работу с тестовой версией и продуктивом? По сути, разработчик, должен иметь возможность вносить изменения только в тестовую версию. Как быть если появился еще один разработчик в проекте?
2. Как максимально просто "сливать" изменения в продуктив после проведения merge?

ПС: читал про gitflow, идеология в общих чертах понятна. Далее планирую ее использовать, как набью шишки.
ПСС: работаю под MacOS, репозиторий на bitbucket
  • Вопрос задан
  • 3124 просмотра
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
1) все просто, не используйте git для деплоя (git pull на сервере), для этого есть другие штуки, капистрано, капифони и т.д.

Что до разграничения прав - тут тоже все просто, просто сделайте два репозитория, в один имеют право пушить все а в другой - тот который прод или еще как, только вы (или кто-то главный), и сделать его отдельным оридженом. Тогда права будут разграничены полностью и вы сможете принимать решения что идет на сервак а что нет.

2) можно в bitbucket поставить действия на push хуки, что бы например дергать вашу CI-ку, там прогонять тесты (вы же пишите тесты?) и деплоить. Тогда что бы выкатить версию надо будет всего-лишь сделать git push, а дальше магия. Ну и опять же если мы разделили репозитории на отдельыне ориджены, мы так же можем контролировать кто может деплоить а кто нет.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
mmmaaak
@mmmaaak
Используйте GIT Flow.
Ответ написан
Комментировать
@dmitryKovalskiy
программист средней руки
Если говорить чисто концептуально, то должна быть основная ветка(Release), а от нее делаться бранчи под конкретную задачу. При готовности задачи - слияние с основной веткой. Это один из подходов и далеко не единственный. В вашем случае можно сделать релиз, от нее бранч-тест, и дальше от теста бранчится в задачи. При готовности задачи - вливать в тест, после тестов - релиз. 1 требование - запрет слияний напрямую в релиз мимо тестов.
Ответ написан
@ggrn
git flow для веток, jenkins для деплоя.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
ИТЦ Аусферр Магнитогорск
от 100 000 до 160 000 ₽