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

• Git-flow: Использовал для проектов с четко выраженным циклом релизов. Удобен для управления фиксацией функционала, исправлениями ошибок и подготовкой релизов. Создает ветки feature, develop, release, hotfix, master.

• GitHub flow: Применял для проектов, где приоритет отдается частым, небольшим релизам. Простая модель, основанная на одной основной ветке (main или master) и ветках для каждой фичи или исправления, которые сразу мержятся в основную ветку после ревью.

• Trunk-based development: Практиковал для проектов, требующих высокой частоты интеграции и непрерывного развертывания. Разработчики вносят изменения непосредственно в основную ветку (trunk) или короткоживущие ветки, которые быстро мержятся обратно. Ключевой элемент — Feature Toggles.

Помимо этих основных паттернов, использовал:

• Rebase vs Merge: В зависимости от ситуации и договоренностей в команде, использовал git rebase для поддержания чистой истории коммитов в рамках локальных веток перед мержем, и git merge --no-ff для сохранения явной истории слияний в основной ветке.

  # Пример rebase
  git checkout feature/nova-feature
  git pull --rebase origin main 
  # Разрешение конфликтов, если есть
  git push -f origin feature/nova-feature 
  # Или pull request на мерж в main
  

  # Пример merge --no-ff
  git checkout main
  git merge --no-ff feature/nova-feature -m "Merge feature nova-feature into main"
  git push origin main
  

• Squash and Merge: Часто применял при слиянии веток фич в основную ветку через Pull Request. Позволяет объединить несколько коммитов из ветки фичи в один чистый коммит в основной ветке.

  # Пример squash merge через интерфейс Git-платформы (GitHub, GitLab)
  # Обычно выполняется при подтверждении Pull Request.
  

• Cherry-picking: Использовал для переноса конкретных коммитов между ветками, например, для бэкпортирования исправлений из основной ветки в релизную или стейджинг-ветку.

  # Пример cherry-pick
  git checkout release/v1.2
  git cherry-pick <commit_hash>