GitFlow v.2 - webkoth/style-guide-php-laravel GitHub Wiki

  1. Мы НЕ ДЕПЛОЕМ В ПЯТНИЦУ! (кроме хотфиксов)

  2. Ветки с которым работаем:

  • master - в ветку делаются МРы из release или HOTFIX

  • dev - ветка будет жить как сбор разных коммитов для тестов и проверок на тестовой среде. Сюда могут попадать разные МРы, в т.ч. и те которые не способны к релизу. Ветка стабилизируется раз в 1-2 спринта или по необходимости.

  • release - Ветка в которую заливаются МРы, только те которые прошли ревью, CI и готовы к выкатке в мастер на прод. Релиз стабилизируется сразу после выкатки релизных задач в мастер. МРы перед заливку в эту ветку должны перематываться на текущий момент данной ветки через rebase.

  1. Ветка катиться 2 раза в неделю: Понедельник и Четверг

  2. Все выкатки должно проходить обязательно ревью с некоторым исключением по hofix. В свою очередь ревьювер обязан взять задачу на ревью и выполнить его в срок спринта или до установленному времени в задаче.

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

  4. Мы больше не должны мерджить ветки из мастера или релиза. Все новые правки из мастера нужно подтягивать исключительно через rebase и решать конфликты если они возникают. Проблема мерджей отражена в неверном примере коммитов МРа.

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

  6. В МРе должен присутствовать только один коммит, за исключением коммитов, которые не связаны между собой в рамках эпика или логического разделения. Коммиты должны быть сквошнуты в единый коммит - git squash После squash коммитов в свою ветку делается force push в свою ветку, так как в ветки могли быть уже множество коммитов которые лежат удаленно и после сквоша гит не даст сделать обычный пуш из за разногласий коммитов на удаленной ветке.

Последовательность команд:

git rebase

git squash (свои коммиты)

git push —force ( если в удаленной ветки коммиты раздробролены и были запушены как несколько)

  1. Несколько коммитов могут встречаться в случае рефакторинга в рамках задачи. Тут стоит одним коммитов рефакторинг вынести, а другим фичу или багу закомитить.

  2. В списке коммитов МРа, не должно присутствовать коммитов с “Merge branch …"

  3. Не верные коммиты МРа:

  • fix logs

  • fix composer

  • WIP

  • update composer

  1. Верные коммиты МРа:

  • fix logs for request users

  • update version composer packages

или если была затронута только одна логика

  • update version composer packages
  1. Мастер закрыт от пушей и форс пушей для всех, кроме ревьювера и лида.

Название веток - {TASK_ID}-{SHORT_DESCRIPTION}

Пример: DEV-1345-logging-time-queries

Название МРов:

{ [ hotfix | feat | fix | chore | refactor | revert ] } : {TASK_ID} {SHORT_DESCRIPTION}

Пример: feat: DEV-1345 logging time queries

Пример: hotfix: DEV-1345 calculation for products

Пример: fix: DEV-1345 optimize calculation for products

  1. МРы должны иметь описание что сделано и/или что было не так. Кратко и без мелких подробностей. Это требуется чтобы ревьюер мог понять что происходило в МРе не только из название МРа.

  2. Все коммиты должны проходить этап CI на предмет ошибок в форматировании и тестах.

image

  1. Описание префиксов:

fix: коммит, который устраняет баг

hotfix: коммит, который устраняет срочный баг

feat: коммит, который содержит новый функционал

chore: коммит, который не устраняет баг и не вносит новый функционал, а модифицирует или обновляет зависимости

refactor: этот коммит содержит рефакторинг, который включает рефакторинг кода или изменения, в том числе и стиль оформления кода

revert: коммит, который сигнализирует об откате к предыдущему коммиту

  1. HOTFIX

Хот фиксы могут и должны быть только в мастер. В зависимости от степени “горения” выкатки будут подвергаться одному из этапов проверки. Коммиты все сквошнуты!

В описание МР обязательно пишется суть решения или что сделано

Варианты выкатки:

Упал прод - катится без ожидания CI и ревью

Прод работает, но сыпит ошибки - ждем работы CI и катим без ревью, если там ошибки появились.

Прод работает и сыпит ошибки, но есть возможность подождать выкатки 10-15 минут и проверить МР через ревью. Возможность определяется на основании времени ответа ревьювера, если нет ответа в течении 5 минут что ревьювер может проверить, то катится МР без ревью.

После выкатки хотфиксов обязательно нужно вернуться к процессу, по которому работает выкатка багов, а именно проверить CI и отдать код на ревью, чтобы хотфиксы стали “багой” и были в рамках основного процесса.

  1. FEAT and BUG FIX и остальные префиксы

Баги и фичи катятся только через CI и ревью через МР. Пишутся тесты на функционал.

Если баг не может жить в течении 2 дней, то это хот фикс. Об этом дальше.

МР делается в ветку релиз

Пуш в дев - если требуется, но он вроде не работает

Мы должны релизить постоянно и поэтому 2 дня релиза Понедельник и Четверг. Релизы нам дадут возможность упорядоченно катить задачи и держать актуальную ветку мастер и давать возможность готовить задачи к выкатке без конфликтов.

  1. Continuous Integration и тесты

  • При работе пайплайнов в гитлабе будет происходить запуск проверки кода на основании

  • PSR-12 стандартов форматирования кода.

  • Не успешные пайплайны сигнализируют что требуется внести правки и МР будет отправляться обратно исполнителю.

  • Перед пушем коммитов следует запускать проверку и исправление таких ошибок с помощью codesniffer и других анализаторов.

  • Команды запуска таких проверок будут добавлены в этот документ после добавления данных инструментов

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

  2. ПИНГОВАТЬ В ЧАТ ЧТО УЗЖАЕТ В ПРОД ПОСЛЕ ВЫКАТКИ