Git workflow для Kotlin разработчиков: как не сломать проект

Введение: Почему Git — это не просто «git push»

Если вы пишете на Kotlin, то знаете, как приятен этот язык: лаконичный, безопасный, современный. Но даже самый элегантный код превращается в хаос, если в команде нет чёткого Git workflow. Вы когда-нибудь пытались смержить ветку, где один разработчик переименовал половину файлов, другой — рефакторил корутины, а третий случайно залил `build.gradle.kts` с локальными путями?

Git workflow для Kotlin разработчиков — это не просто скучные правила. Это ваш щит от конфликтов, гарант стабильного `main` и способ не тратить понедельник на разбор «кто что сломал». В этой статье мы разберём реальный пайплайн: от настройки `.gitignore` под Kotlin до автоматических проверок через Gradle и pre-commit хуков.

Поехали наводить порядок в репозитории!

1. База: Настройка репозитория под Kotlin

1.1. Правильный .gitignore для Kotlin

Первое, что должен сделать каждый — забыть про копипаст шаблонов с GitHub. В Kotlin-проектах есть специфические папки, которые не должны попасть в репозиторий. Вот минимальный джентльменский набор:

# Kotlin & JVM
*.class
*.jar
*.war
*.ear
build/
!gradle/wrapper/gradle-wrapper.jar

# IDE (IntelliJ IDEA)
.idea/
*.iml
*.iws
out/

# OS
.DS_Store
Thumbs.db

# Gradle
.gradle/
local.properties

Обратите внимание: мы явно исключаем `.idea/` — это спасёт коллег от конфликтов в конфигах IDE. А `local.properties` (путь к SDK) — сугубо локальная вещь.

1.2. Git-хуки: ваш персональный линтер

Git workflow для Kotlin разработчиков немыслим без pre-commit хуков. Они запускаются до того, как коммит будет создан. Самый популярный инструмент — pre-commit с плагинами под Kotlin.

Пример конфига `.pre-commit-config.yaml`:

repos:
  - repo: https://github.com/pre-commit/mirrors-ktlint
    rev: v0.50.0
    hooks:
      - id: ktlint
        args: ["--format"]

  - repo: https://github.com/detekt/detekt
    rev: v1.23.1
    hooks:
      - id: detekt

Теперь перед каждым коммитом `ktlint` отформатирует код, а `detekt` проверит на потенциальные баги. Больше никаких «забыл прогнать линтер»!

2. Стратегия ветвления: выбираем свой workflow

2.1. Git Flow — классика для больших проектов

Для Kotlin-монолитов или проектов с жёсткими релизами подходит классический Git Flow. Основные ветки:

• main — только стабильный код, который в проде.
• develop — интеграционная ветка для разработки.
• feature/* — каждая новая фича.
• release/* — подготовка к релизу (исправление багов, обновление версии).
• hotfix/* — срочные правки в проде.

Пример для Kotlin: вы разрабатываете новую функцию обработки корутин. Создаёте ветку feature/coroutine-flow, работаете, затем сливаете в develop. Когда фич набралось на релиз — создаёте release/2.1.0, там фиксите баги и только потом вливаете в main.

2.2. GitHub Flow — для CI/CD и быстрых релизов

Если вы пишете микросервис на Ktor или Spring Boot и выкатываетесь каждый день, Git Flow будет перебором. Используйте GitHub Flow:

• Ветка main всегда готова к деплою.
• Каждая задача — feature/название.
• После завершения — Pull Request, код-ревью, автотесты, мёрж в main.
• Сразу после мёржа — деплой (в идеале).

Отлично подходит для Kotlin-проектов с хорошим покрытием тестами.

2.3. Trunk-based — для смелых

Работаете в стартапе или делаете pet-проект? Trunk-based (все коммитят в main короткими коммитами) ускоряет разработку, но требует высокой дисциплины и Feature Toggles. Для Kotlin с его строгой типизацией это проще, чем для динамических языков — компилятор сразу отловит половину проблем.

3. Работа с Pull Request: код-ревью для Kotlin

3.1. Шаблон PR для Kotlin-проекта

Чтобы код-ревью не превращалось в гадание, используйте шаблон. Пример для GitHub (.github/PULL_REQUEST_TEMPLATE.md):

## Описание
Что делает этот PR? Ссылка на задачу (Jira/Linear).

## Тип изменений
- [ ] Новая фича
- [ ] Исправление бага
- [ ] Рефакторинг
- [ ] Документация

## Как тестировать?
- Запустите `./gradlew test`
- Проверьте endpoint /api/v2/users

## Чеклист
- [ ] Код отформатирован (ktlint)
- [ ] Написаны unit-тесты
- [ ] Нет утечек памяти (проверено LeakCanary для Android)

3.2. На что обращать внимание в PR

Git workflow для Kotlin разработчиков включает обязательные проверки:

• Null safety: нет ли лишних `!!`? Используйте `?.let {}` или элвис-оператор.
• Корутины: не забыли ли `Dispatchers.IO` в тестах? Нет ли блокирующих вызовов в `Main`?
• Sealed классы: не разросся ли `when` без `else`?
• Сериализация: если используете kotlinx.serialization, проверьте аннотации `@Serializable`.

4. Автоматизация: CI/CD для Kotlin

4.1. GitHub Actions: базовый пайплайн

Автоматизация — сердце современного workflow. Вот пример для Kotlin-проекта на Gradle:

name: Kotlin CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name