Gitflow является классическим подходом для работы в команде и периодической поставки билдов. Давайте разберем, какие проблемы он решает и как его адаптировать к своей команде, и нужно ли.
🛠 Часть 1. Базовый подход
Тут все очень просто: на проекте есть одна ветка, и все коммиты идут только в нее. Часто в качестве такой ветки используется main (или master) либо dev (или develop).
✅ Если на проекте работает один программист и нет требований к постоянной поставке билдов, можно остановиться на этом.
Очень много мобильных прототипов на этапе первого маркетингового теста используют именно этот Git workflow, и нет необходимости делать что-то сложнее.
👥 Часть 2. Работа в команде
Давайте представим ситуацию, когда на проект пришел еще один программист, и работать в одной ветке стало неудобно. Тогда нам на помощь приходит подход с созданием фича-веток.
🎯 Первое, что нужно сделать, — это определить, какая ветка будет основной рабочей. Практически во всех случаях стоит использовать dev. Однако, если в команде есть, например, художники, которым сложно работать с Git, можно сделать исключение и использовать main как основную ветку, в которую они будут добавлять свои наработки.
🔀 От основной ветки создается отдельный бранч с названием фичи, например, double-jump. Разработчик, ответственный за эту фичу, работает в данной ветке, а затем выполняет merge в основную. Чтобы было понятно, кто отвечает за ветку, можно добавлять ник разработчика в название, например: Boris-double-jump.
🛡 Как только фича готова, она отправляется на код-ревью и тестирование. После успешного прохождения этих этапов она мержится в основную рабочую ветку. При таком подходе в dev (или main) всегда находятся только проверенные фичи с минимальным количеством багов.
Иногда несколько разработчиков работают над одной фичей, например, из-за сжатых сроков. Такой подход нежелателен, но если избежать его невозможно, стоит использовать Trunk-Based Development. В этом случае все разработчики работают в одной ветке либо создают короткоживущие ветки и часто выполняют merge. Такой подход требует микроменеджмента и частой синхронизации действий, особенно в Unity, где сложны слияния сцен и префабов.
🚢 Часть 3. Периодическая поставка билдов
Если к предыдущему подходу добавить требование о периодической поставке билдов, процесс будет следующим:
1️⃣ Когда проект готов к релизу, dev вливается в main, и создается сборка.
2️⃣ После успешного прохождения тестов на последнем коммите ставится тег (например, 1.0.1), а если сборка не прошла тестирование, баги исправляются прямо в main.
3️⃣ main вливается обратно в dev.
🏷 Тегирование необходимо для возможности быстрого выпуска хотфиксов. Если в продакшене найден критический баг, создается новая ветка от коммита с этим тегом, например, hotfix-1.0.2, где исправляется ошибка и затем создается новая сборка.
🔄 Часть 4. Периодическая поставка разных билдов
Теперь представим, что необходимо вести параллельную разработку нескольких билдов с разными фичами. Для этого добавляются релизные ветки.
1️⃣ После прохождения всех тестов фичи 1 она мержится в dev, затем создается ветка RC-1.0.3-IOS, где RC — release candidate.
2️⃣ Аналогично, после тестирования фичи 2 создается другая ветка RC-1.0.3-WebGL.
3️⃣ Баги фиксируются в соответствующих RC-ветках. Если найден общий баг, его можно перенести в другую RC-ветку с помощью cherry-pick.
4️⃣ После выпуска релизной версии ставится тег, и ветка мержится в main и dev.
Если было полезно то ставьте 🔥, а если возникли вопросы, то их можно задать в комментариях👇
P.S Один из подписчиков дал хороший совет: вместо того, что бы добавлять префикс в виде имени лучше использовать папку. Тоесть вместо "Boris-double-jump" использовать "Boris/double-jump"