Где вел проекты?

Я веду проекты на GitLab и GitHub. Оба инструмента незаменимы в современной разработке, и выбор между ними часто зависит от политики компании, требований безопасности и личных предпочтений команды.

Моя практика работы с GitLab и GitHub

В коммерческой разработке чаще использовал GitLab (как облачную версию GitLab.com, так и self-hosted-инсталляции внутри компаний). Это было связано с более гибкими возможностями CI/CD "из коробки" и удобством для внутренних корпоративных проектов. Для open-source и личных проектов чаще выбирал GitHub из-за его огромного сообщества и сетевого эффекта.

Ключевые аспекты ведения проектов:

1. Организация репозиториев: Я строго следую принципам монопоточности репозиториев (one repository — one project или service). Это упрощает управление зависимостями, CI/CD и контроль доступа.

2. Ветвление: Практикую адаптированную под нужды проекта модель GitFlow или более простой подход GitHub Flow. Основное правило — main/master ветка всегда стабильна и готова к деплою.

   # Пример создания feature-ветки по GitFlow
   git checkout develop
   git pull origin develop
   git checkout -b feature/AND-123-add-new-login-screen
   

3. Структура коммитов: Использую Conventional Commits для единообразия и автоматизации (CHANGELOG, семантический релиз). Это особенно важно в командной работе.

   git commit -m "feat(auth): implement biometric login prompt"
   git commit -m "fix(profile): crash when avatar is null"
   git commit -m "docs(readme): update installation guide"
   

4. Code Review: Все изменения, кроме срочных хотфиксов, проходят обязательный код-ревью через Merge Request (GitLab) или Pull Request (GitHub). Я настраиваю правила защищённых веток (main, develop), которые запрещают пушить напрямую и требуют аппрува от коллег, успешного прохождения pipeline и, если нужно, определённого количества approvals.

   # Пример .gitlab-ci.yml правила для запуска тестов на MR
   review:
     stage: test
     script:
       - ./gradlew testDebugUnitTest
     only:
       - merge_requests
   

5. CI/CD (Непрерывная интеграция и доставка): Настраиваю автоматизированные пайплайны для сборки, тестирования и деплоя.

    *   **На GitLab** использую встроенный `.gitlab-ci.yml` для сборки Android APK/AAB, запуска unit- и инструментальных тестов, загрузки артефактов в **Google Play Console** или на внутренний сервер распространения (например, **Firebase App Distribution**).
    *   **На GitHub** настраиваю аналогичные workflows через **GitHub Actions**.

```yaml
# Упрощённый пример GitHub Actions workflow для Android
name: Android CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Build with Gradle
        run: ./gradlew assembleDebug
```

6. Управление зависимостями: Для Android-проектов обязательно использую Version Catalogs (файл libs.versions.toml) или системы типа Dependabot на GitHub для централизованного управления и автоматического обновления библиотек.

```toml
# libs.versions.toml (пример)
[versions]
compose = "1.7.0"
retrofit = "2.11.0"

[libraries]
retrofit = { module = "com.squareup.retrofit2:retrofit", version.ref = "retrofit" }
```

7. Документация: Веду проектную документацию (архитектурные решения, инструкции по запуску) чаще всего в README.md в корне репозитория и в Wiki на GitLab/GitHub. Для более сложной документации использовал mkdocs или Confluence, интегрированный с репозиториями.

Таким образом, "вести проекты" для меня — это не просто хранить код в репозитории, а выстроить вокруг него полноценный жизненный цикл разработки: от создания задачи и ветки до автоматизированного тестирования, ревью, мержа и деплоя. Это требует настройки инструментов, но многократно окупается за счёт повышения качества кода, скорости обнаружения ошибок и стабильности процесса выпуска обновлений.