Как был организован контроль версий (Version Control) на вашем последнем проекте?

Мы использовали Git с GitLab в качестве платформы. Рабочий процесс был основан на Trunk-Based Development с короткоживущими feature-ветками, что хорошо интегрировалось с нашим CI/CD.

Основной workflow:

1. Основная ветка — main. Все изменения попадают туда только через Merge Request (MR).
2. Для каждой задачи создаётся ветка от main с именем feature/JIRA-123-short-desc.
3. Разработка ведётся в этой ветке с регулярными rebase на main.
4. Push ветки в GitLab и создание MR.

Ключевые правила процесса:

• Обязательный Code Review: Минимум один аппрув от коллеги. MR не может быть принят автором.

• Проверки в CI/CD: Каждый MR запускает пайплайн, который включает:

  # .gitlab-ci.yml фрагмент
  stages:
    - test
    - security
    - build
  
  code_quality:
    stage: test
    script:
      - sonar-scanner
  
  container_scan:
    stage: security
    script:
      - trivy image --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

• Squash Merge: Все коммиты из feature-ветки объединялись в один при мердже в main для чистоты истории.
• Защита веток: Ветка main была защищена от прямого пуша, force push был запрещён.

Интеграция с инфраструктурой: Мы использовали GitOps-подход с ArgoCD. Манифесты Kubernetes для разных сред (staging, production) хранились в отдельном репозитории. Изменение в main ветке приложения автоматически триггерило обновление манифестов (через CI), а ArgoCD синхронизировал состояние кластера с этими манифестами.

Для экстренных исправлений использовали ветки hotfix/ с ускоренным, но не менее строгим ревью.