У нас на всех проектах используется свой гит флоу. И сейчас я расскажу какой именно:
1. Мастер всегда в рабочем состоянии и является основной веткой разработки;
2. Если фича крупная (потребуется больше одного коммита, чтобы ее закрыть), то под такую фичу заводим отдельную ветку “feature/…”, если фича мелкая - заливаем в мастер, проверив перед этим что ничего не сломали (в разрезе того что потрогали);
3. Если фича мелкая, то задачу переводим на qa. Qa проверяют задачу в мастере (если не указано в какой ветке фича);
4. Если фича крупная, то перед тем как отдать фичу в qa - подливаем мастер к себе в ветку;
5. Релизы делаем в отдельных ветках вида “rc/x.y.z”. Почему бы не тегировать? Дело в том, что мы делаем rc ветку за несколько дней до отправки в сторы. Ветка rc - это фичефриз, то есть никаких новых фич туда не заливается, только фикс существующих. Создали rc - qa пошли смотреть полностью билд. Нашли баги - мы их подправляем прям в rc;
6. После отправки билда в сторы, rc вливается в мастер.
Вроде ничего не забыл;) Благодаря такому гит флоу получается, что максимальное количество фич проверяется вместе друг с другом, а не по отдельности. Я встречал разные подходы в разных компаниях, но в итоге мы пришли к этому варианту.
А какой гит флоу у вас на проекте?
#gitflow #git
Post #226
4.43K
- 🔥 28
- 👍 19
- ❤ 1
- 😱 1