Как была организована работа в Git на последней работе

Организация Git-процесса в моей команде

На последнем проекте мы использовали GitFlow с рядом адаптаций под потребности мобильной разработки на Android. Этот процесс обеспечивал стабильность релизов и параллельную разработку новых функций.

Основные ветки и их назначение

У нас было три основные долгоживущие ветки:

• main — соответствовала текущему продакшен-релизу в Google Play. Каждый коммит сюда автоматически триггерил сборку для публикации в internal testing track. Создание тега vX.Y.Z на коммите в main запускало процесс подписания APK и публикации в production.
• develop — интеграционная ветка для готового к тестированию кода. Это была основа для создания nightly builds, на которых QA проводило регрессионное тестирование.
• release/X.Y.Z — ветки, ответвляемые от develop для финальной подготовки релиза (фикс багов, обновление версий, метаданных). После стабилизации смерживались в main и develop.

Рабочий процесс разработчика

Разработка новой функциональности строго велась через feature-ветки, ответвляемые от develop.

# Начало работы над новой фичей
git checkout develop
git pull origin develop
git checkout -b feature/AND-123_add_payment_screen

Ключевые требования к коммитам:

1. Семантические имена веток: feature/, bugfix/, hotfix/ с ID задачи из Jira (например, AND-123).
2. Конвенция коммитов: Использовали Conventional Commits. Сообщение коммита должно было быть понятным и содержать ID задачи.

   git commit -m "feat(payment): add Google Pay integration [AND-123]"
   # или для правки бага
   git commit -m "fix(crash): handle NPE in PaymentProcessor [AND-456]"
   

3. Code Review (CR): Запрос на слияние (Pull Request, PR) в develop создавался сразу после готовности фичи, даже если она не завершена. Это позволяло рано получить фидбек. Мержить мог только тот, кто не является автором PR. Обязательными были 2 апрува от коллег. CR включал проверку кода, архитектуры, тестов и UI (через приложенные скриншоты или видео).
4. Интеграция: После апрувов и успешного прохождения CI-проверок (сборка, линтинг, unit-тесты) разработчик выполнял слияние через кнопку "Squash and Merge". Все коммиты фича-ветки схлопывались в один аккуратный коммит с полным описанием в develop.

Процесс CI/CD и контроль качества

Наш GitLab CI/CD был тесно интегрирован с процессом:

1. На каждый пуш в любую ветку запускался пайплайн с assembleDebug, ktlintCheck и модульными тестами.
2. При создании PR в develop дополнительно запускались UI-тесты на Firebase Test Lab и сборка Lint Report. Результаты автоматически комментировались в PR.
3. Пуш в main запускал сборку подписанного AAB (Android App Bundle) и публикацию во внутренний трек Google Play.

Адаптации под мобильную разработку

Мы отошли от классического GitFlow в нескольких аспектах:

• Отказ от долгоживущих release/ веток. Для минорных обновлений стали чаще использовать trunk-based development с feature-флагами. Фича разрабатывалась в ветке и сразу мержилась в develop под флагом, который включался только в release/ ветке.
• Упрощенный процесс хотфиксов. Для срочных правок в продакшене создавалась ветка hotfix/ от main. После фикса и тестирования она мержилась сразу и в main (создавая патч-релиз), и в develop.
• Жесткий регламент для main. Прямые пуши в main были технически запрещены для всех, кроме CI-системы. Даже хотфикс проходил через PR с обязательным апрувом тимлида.

Инструменты и коммуникация

Мы использовали GitLab как основную платформу. Для сложных мержей и визуализации истории локально многие использовали Fork или GitKraken. Важнейшим правилом было поддерживать историю в чистоте — rebase от develop перед созданием PR был обязательным шагом, чтобы избежать "спагетти-истории" и конфликтов.

Такой подход, сочетающий структурированность GitFlow и гибкость через флаги, обеспечивал нам предсказуемый цикл релизов (раз в 2 недели), минимальное количество критических багов в продакшене и эффективную параллельную работу 5-7 Android-разработчиков над одним кодом.