Как организовать работу по git c ветками?

Question

[bernex]

Вообще нравится git-flow но думаю не подойдет нам в стиле: сегодня срочно надо сделать релиз с ФИЧЕЙ1

Как представляю работу:
master->jenkins->deploy production
develop->jenkins->deploy dev

Все нравится в git flow - но каждый раз ради фичи - делать версию? Или это хотфиксом делать? Можно это упростить?
Gitlab каждый раз требует еще и merge-request делать. А хотелось бы чтобы сразу попадало в ветку.

Answer 1

[dmitriy]

merge-request делают в основном для коде-ревью, если у вас одна ветка то может вам не нужен git-flow ?

Comments

[bernex]

Две ветки это хорошо и схема хорошая - но! Как убрать эти ревью - чтобы ветки сливались сразу

[dmitriy]

я разрабатываю и поддерживаю некоторые проекты один используя gitflow, и создание релизов так же по началу напрягало, когда нужна сразу доработка на рабочем. Но со временем удобство gitflow победило это неудобство. Вот преимущества которые мне помогли:
1. master и develop помогают демонстрировать функционал на продакшен(рабочий) и пред-продакшен (демка) версиях сайта. Изменения сразу на продакшене сервере как правило происходят при исправлениях критических ошибок (hotfix) и это логично исправил на рабочем сайте продублируй на демку. Как правило если доработка улетает сразу в мастер ветку в большинстве случаев, дорабатываются, по этому приходится делать разные hotfix' ы относительно одного и того же функционала, и есть риск что сайт во время этих фиксов может работать не корректно. Поэтому делайте все в feature ветке, выкладывайте на демку и исправляйте замечания клиента, при 100% готовности делайте релиз и соответсвенно слияние с master.
2. автодеплой на сервера при пушах в master и develop, ну действительно это удобно.
3. релизы и версионность сайта. при релизах приходится делать версию, ну это нормально. если доработка повышайте минорную версию, если глобальный рефакторинг то мажорную, со временем вижу цифру и понимаю что сайт многое пережил.