👍 Вопрос — ответ. Разбираем боли подписчиков

Как устроена работа с гит в твоём проекте? Что бы добавил или убрал? Какой оптимальный флоу?

На всех работах у меня был плюс-минус одинаковый гит флоу. Есть мастер ветка, от неё для задачи делается новая ветка с номером задачи, например TASK-123.

Коммиты мы пишем по системе conventional-commits, например TASK-123 (fix) поправил тултип с ценой в сафари.

Для удобства я использую cz-git, чтобы не писать коммит руками, а просто собирать его из консольки. Запушить коммит с сообщением в другом формате не получится, потому что там стоит проверка на pre-commit от lefthook.

Как только задача сделана, разработчик скидывает ссылку на мердж реквест в чатик. Там бот автоматически выбирает людей, которые будут смотреть эту задачу, чтобы каждый учавствовал в код ревью, а не пришлось одному человеку проверять всех.

Для написания комментов в мердж реквесте я использую систему conventional-comments. Написал себе расширение для хрома, чтобы можно было быстро накликивать шаблон для сообщений.

На мердж реквест обычно требуется два аппрува от разных людей. Как только апрувы получены, задача вливается в ветку release/TASK-123, где проект билдится и релизится на тестовом стенде.

После релиза, задача передаётся тестировщикам, где они могут потыкать интерфейс. Если во время тестирования выявили баг, то разработчик делает новую ветку TASK-123_fix_safari и опять проходит цикл с ревью. Некоторые, конечно, пренебрегают таким и фиксят правки тестировщиков прямо в релизной ветке.

После аппрува от тестировщиков и менеджеров, можно задачу задеплоить. У нас любой разработчик может деплоить, нет выделенных людей, которые отвечают за релизы. Деплой достаточно прост: нужно встать в очередь, чтобы несколько человек не релизились одновременно, получить апрувы от дежурного, а потом просто тыкать по галочкам в пайплайне. На финальном шаге ветка release/TASK-123 просто вливается в master и закрывается в таск трекере. Создаётся тег с номером задачи, чтобы если что можно было откатить задачу в один клик.

Был в командах, где задача деплоилась не сразу после выполнения, а собиралась в релизную ветку. В конце спринта эта ветка релизилась.

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

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

К счастью, такое бывает только под конец года. Когда кодфриз снимается, все молятся чтобы эта огромная ветка ничего не разломала.

Свои вопросики задавайте сюда →****@webistomin_ask_bot ➿➿➿ 🧑 • бусти • ютуб • задать вопрос