Пользовался где-то год назад, отличный проект, спасибо ребята.
Было одно неудобство — отсутствие source maps — ведь код все равно жмется. Сейчас их можно использовать?
Есть несколько вариантов
— если это небольшие изменения, то они сразу влились после код ревью в дев, и если перед релизом в них обнаружена ошибка, то обычно не составляет труда ее исправить
— если это более масштабные изменения, то тестер проверяет отдельно ветку перед сливанием с девом
В целом по такой схеме мы ни разу не пропустили обновление (обновляемся 1 раз в неделю)
Это рабочий процесс, использующий Github. В самом начале написано «Я расскажу о цикле разработки через Github, который я использую.». Это действительно проблема?
Мастер в любой момент должен быть протестирован и готов к выкатыванию на production сервер. Без dev ветки регрессионное тестирование практически невозможно.
Это требует больше времени, шагов, внимания разработчика. И кроме того, как показала практика, в push -f в dev ветку нет ничего страшного. Если даже что-то случилось — всегда есть build сервер с последней версией dev
Всегда приходится идти на компромисы между красотой и удобством. Я пробовал вводить отдельную ветку для пред-релизных исправлений, и только после регрессии вливать ее в master. С одной стороны это правильно, но это занимало больше времени и кроме этого (и самое важное) — регрессионное тестирование тогда ведется не на том билде, который попадает на production
Если есть опасения, что кто-то что-то сломает, то можно делать merge вместо rebase, и пушить без -f. Но у меня за год случился только 1 случай, когда разработчик ошибся. Исправили очень быстро и безболезненно.
Преимущество — чистая история без двойных мержей. Кроме этого rebase можно делать больше одного раза, и история будет выглядеть однозначно понятной и удобной для чтения
Веток может быть очень много. К примеру 6 разработчиков коммитят свои изменения в свои ветки. Собирать каждую на каждый пуш на гитхаб слишком накладно по ресурсам.
Было одно неудобство — отсутствие source maps — ведь код все равно жмется. Сейчас их можно использовать?
— если это небольшие изменения, то они сразу влились после код ревью в дев, и если перед релизом в них обнаружена ошибка, то обычно не составляет труда ее исправить
— если это более масштабные изменения, то тестер проверяет отдельно ветку перед сливанием с девом
В целом по такой схеме мы ни разу не пропустили обновление (обновляемся 1 раз в неделю)
Преимущество — чистая история без двойных мержей. Кроме этого rebase можно делать больше одного раза, и история будет выглядеть однозначно понятной и удобной для чтения