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

Question

[Gleb]

Добрый день.

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

ПС: читал про gitflow, идеология в общих чертах понятна. Далее планирую ее использовать, как набью шишки.
ПСС: работаю под MacOS, репозиторий на bitbucket

Answer 1

[Сергей Протько]

1) все просто, не используйте git для деплоя (git pull на сервере), для этого есть другие штуки, капистрано, капифони и т.д.

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

2) можно в bitbucket поставить действия на push хуки, что бы например дергать вашу CI-ку, там прогонять тесты (вы же пишите тесты?) и деплоить. Тогда что бы выкатить версию надо будет всего-лишь сделать git push, а дальше магия. Ну и опять же если мы разделили репозитории на отдельыне ориджены, мы так же можем контролировать кто может деплоить а кто нет.

Comments

[cold147]

сделайте два репозитория

Или можно ограничит доступ на определенные ветки.

[Сергей Протько]

Элбек Азимов: в случае с битбакетом - да, в остальных случаях лучше отдельный репозиторий.

[Алексей Васильевич]

Если речь конкретно про bitbucket, то у Atlassian-а есть свой CI - Bamboo. У него замечательная интеграция с битбакетом (впрочем, и с гитхабом тоже неплохая) и шикарные инструменты для деплоя

Answer 2

[Pavel Shvedov]

Используйте GIT Flow.

Answer 3

[Дмитрий Ковальский]

Если говорить чисто концептуально, то должна быть основная ветка(Release), а от нее делаться бранчи под конкретную задачу. При готовности задачи - слияние с основной веткой. Это один из подходов и далеко не единственный. В вашем случае можно сделать релиз, от нее бранч-тест, и дальше от теста бранчится в задачи. При готовности задачи - вливать в тест, после тестов - релиз. 1 требование - запрет слияний напрямую в релиз мимо тестов.

Comments

[Анатолий Медведев]

в более законченном виде ваше предложение выглядит так nvie.com/posts/a-successful-git-branching-model

[Дмитрий Ковальский]

Анатолий Медведев: Спасибо за схему, я пытался формулировать идею в отрыве от конкретных технологий. Почему картинга называется successful-git-branching-model - не знаю. Видимо автор думает что в TFS,SVN и Mercurial почему-то не проканает

Answer 4

[ggrn]

git flow для веток, jenkins для деплоя.