Какие паттерны работы с Git вы использовали?

В разных проектах и командах я применял несколько моделей Git workflow. Выбор зависит от размера команды, частоты релизов и процессов код-ревью.

1. Trunk-Based Development (основной опыт): Этот подход я использовал в командах, практикующих CI/CD с несколькими деплоями в день.

• Основная ветка: main (ранее master). Все фичи мержатся прямо в нее.
• Короткоживущие feature-ветки: Ветки создаются на одну задачу и живут не более 1-2 дней.

  git checkout -b feat/add-login-button
  # ... работа
  git commit -m "feat: add login button component"
  git push origin feat/add-login-button

• Мерж через Pull Request (PR) с squash или rebase: После ревью изменения вливаются в main, история поддерживается линейной и чистой.
• Преимущества: Минимизация merge конфликтов, быстрая обратная связь, непрерывная интеграция.

2. GitHub Flow / GitLab Flow (для проектов с четкими окружениями): Использовал в проектах, где есть staging и production окружения.

• Ветка по умолчанию: main — всегда готова к деплою в production.
• Feature-ветки: Создаются от main.
• Ветки окружений: staging (может быть защищенной веткой или тегом). Деплой в staging происходит после мержа feature-ветки в main. Деплой в production — из main (или через теги).
• Процесс:

  git checkout -b fix/header-alignment main
  # ... исправление
  git commit -m "fix: align header elements on mobile"
  git push origin fix/header-alignment
  # Создаю PR/MR из fix/header-alignment в main

3. Соглашения по коммитам (Conventional Commits): Во всех проектах я стремлюсь использовать структурированные сообщения коммитов. Это автоматизирует генерацию changelog и определяет семантический versioning.

git commit -m "feat(auth): implement OAuth2 login flow"
git commit -m "fix(api): handle null pointer in user endpoint"
git commit -m "docs(readme): update deployment instructions"
git commit -m "chore(deps): bump axios to version 1.6.0"

4. Стратегии интеграции: Rebase vs Merge:

• git rebase: Использую для обновления своей feature-ветки с последними изменениями из main перед созданием PR. Это дает чистую, линейную историю.

  git checkout feat/my-feature
  git fetch origin
  git rebase origin/main
  # Возможно, нужно разрешить конфликты
  git push --force-with-lease origin feat/my-feature

• git merge: Использую для фиксации факта интеграции, обычно через кнопку "Merge" в интерфейсе GitHub/GitLab после аппрува PR.

5. Вспомогательные практики:

• .gitignore: Начинаю проект с комплексного .gitignore (например, из шаблона GitHub для языка).
• Git Hooks: Иногда настраиваю pre-commit хуки (через Husky для JS или pre-commit для Python) для запуска линтеров и форматирования.
• Работа с тегами: Для релизов создаю аннотированные теги.

  git tag -a v1.2.3 -m "Release version 1.2.3"
  git push origin v1.2.3

Главный критерий для меня — чтобы workflow был понятен всей команде и способствовал, а не мешал, быстрой и безопасной разработке.