Организация работы c Git

#git #git_flow

Добрый день.
Имеется следующий вопрос по реализации GIT схемы.

В нашей работе мы используем два сервера.  


Develop (на нем мы хотим тестировать и показывать промежуточные
результаты)  
Production (на него выкладываем только готовые модули)


У нас 8 разработчиков, каждый работает со своей локальной копией проекта. В течение
дня разработчики должны выкладывать промежуточные результаты на develop сервер, после
подтверждения работы модуля (конкретного разработчика) - необходимо сливать изменения
на боевой сервер (production).

Как вы посоветуете реализовать схему работы с GIT? (сколько веток? как осуществлять
deploy на production, и т.д)

Спасибо. 



Спасибо за ваш ответ. Схема нашей работы. 1. Разработчик правит модуль. 2. Разработчик
делает commit на Develop (здесь возникает вопрос - какие ветки создать, учитывая что
у нас 8 разработчиков; в большинстве случаев каждый разработчик работает со своим модулем,
стоит создать каждому свою ветку или делать коммит в мастер?) 3. Пользователь проверяет
/ тестирует работу модуля и если все работает то этот модуль необходимо выложить на
production сервер. Как реализовать эту схему? Раньше мы не использовали git поэтому
мы не совсем понимаем всех аспектов работы с гитом. Мы будем благодарны если Вы опишите
git схему в нашем конкретном случае. (подобные статьи мы читали но возникает больше
вопросов) Спасибо. 

Еще есть сложность в понимании следующего: 
Каждый разработчик комитит в мастер ветку для того чтобы дать возможность пользователям
посмотреть результат (домен develop предположим)
Вася и Петя выложили работу своего модуля в ветку мастер, модуль Васи готов а модуль
Пети необходимо доработать, как в этом случаи производить мерж ветки мастер с production
(ведь модуль Пети еще не готов) 
    

Ответы

Ответ 1

По тому, что вы описываете, похоже, что вы стремитесь релизить как можно чаще и тестировать
все изменения перед отправкой на бой. Это правильные цели.


  В течение дня разработчики должны выкладывать промежуточные результаты на develop
сервер


Обычно изменения не мержат в общую ветку, пока фича не доделана. Каждый лишний мерж
— потеря сил и времени. А если изменения придётся откатывать, будет совсем тяжело.

Ветки, задачи, релизы

Можно попробовать такую схему:


Разработчики делают новую ветку от master для каждой новой фичи. Каждый день они
делают коммиты в эту ветку. Когда фича готова, ветку мержат обратно в master и для
новой фичи начинают новую ветку. 
Мержить очень рекомендую с созданием мерж-коммита (git merge --no-ff). Подробнее
о том, как ветвить и мержить: Правильное именование веток

Перед мержем желательно выполнить такие задачи:


Ревью кода, его делает тимлид.
Тестирование, его проводит тестировщик. Если нет возможности автоматически деплоить
на сервер, то пусть забирает себе нужную ветку git fetch; git checkout 123-branchname
и поднимает сайт локально. Если менялся дизайн, верстка, юзабилити и прочее, их тоже
нужно протестировать.


Тестирование и ревью кода можно делать просто через ветки, а можно добавить пулл-реквесты.
Зачем нужен pull request, если есть push?


Код из ветки master деплоится на сервер staging автоматически, каждый раз, когда
происходит коммит в master. Автоматизация — за счет git hooks или сервера непрерывной
интеграции, в зависимости от ваших возможностей и ресурсов.

На этом сервере:


Тестировщик смотрит на интеграцию изменений от разных разработчиков.
Менеджер или кто там ответственен за продукт смотрит на готовность фичи.

Когда очередной коммит в master признаётся годным для деплоя на бой, ответственный
за релиз человек делает мерж в ветку production. Из этой ветки тем же механизмом автоматически
обновляется сервер production.




Как деплоить

Если можете, разделите сервер git и сервер с сайтом. Деплой через git pull плохо
масштабируется, лучше настроить через rsync, тогда вы легко сможете использовать дополнительные
тестовые сервера. Настройка и развертывание проекта c помощью Git