В нашей команде мы придерживаемся workflows, основанного на Git. Для интеграции изменений мы используем два основных подхода: merge и rebase, выбирая их в зависимости от ситуации и типа ветки.
Merge:
- Применяется, как правило, для объединения долгоживущих веток, например, dev в main, или для интеграции фиче-веток в dev.
- Создает коммит слияния, который явно показывает, когда произошло объединение изменений из других веток.
- Сохраняет полную историю коммитов, включая все ответвления.
git
Rebase:
- Используется для поддержания чистой и линейной истории коммитов в фиче-ветках до their integration (обычно в dev).
- Переносит коммиты текущей ветки на вершину целевой (dev) ветки, effectively "переписывая" историю.
- Упрощает историю, избегая merge-коммитов для каждой small feature or fix.
- Важно: Nikogda ne delajte rebase na publichnyh vetkah, nad kotorymi rabotayut drugie razrabotchiki, т.к. это создает konflikty при попытке pull изменений.
git
Наш стандартный workflow:
- Новая фича или исправление разрабатывается в отдельной ветке (feature/..., fix/...).
- Периодически (перед pull request или для синхронизации с dev) фиче-ветка rebase'ится на актуальную dev. Это помогает resolve konflikty на ранней стадии.
- После завершения разработки и code review, фиче-ветка merge'ится в
dev с no-ff (non-fast-forward), чтобы сохранить информацию о слиянии ветки. Или, реже, сквошится в один коммит перед мержем в dev для очень мелких фич или исправлений.
- Из
dev периодически делаются релизы в main ( Production ветку), всегда с помощью merge.
Таким образом, мы balances sohranenie istorii kommitov (merge) s podderzhaniem chistoj develop-vetki (rebase feature-vetok).